V nastavení replikace hostitele MySQL se parametr Seconds_Behind_Master (SBM), jak je zobrazen příkazem SHOW SLAVE STATUS, běžně používá jako indikace aktuálního zpoždění replikace podřízeného zařízení. . V tomto blogovém příspěvku zkoumáme, jak tuto hodnotu chápat a interpretovat v různých situacích.
Možné hodnoty v sekundách za mistrem
Hodnota SBM, jak je vysvětleno v dokumentaci k MySQL, závisí na stavu slave MySQL obecně a na stavech slave MySQL SQL_THREAD a IO_THREAD konkrétně. Zatímco IO_THREAD se připojuje k masteru a čte aktualizace, SQL_THREAD aplikuje tyto aktualizace na slave. Podívejme se na možné hodnoty SBM během různých stavů MySQL Slave.
Když je hodnota SBM nulová
- SBM je vždy NULL, pokud je váš slave zastaven nebo vaše vlákno SQL zastaveno (nebo neběží).
- SBM bude mít také hodnotu NULL, pokud je vlákno IO zastaveno, za předpokladu, že vlákno SQL již zpracovalo všechny události z protokolu přenosu. Ukázkový výstup SHOW SLAVE STATUS (oříznutý tak, aby zobrazoval pouze hodnoty, které vás zajímají) to ukazuje:
Slave_IO_State:
Hlavní_hostitel:172.19.0.13
Slave_IO_Running:Ne
Slave_SQL_Running:Ano
Seconds_Behind_Master:NULL
Master_UUID:23b326b1-a452-11e8-91ca-000d3a065e8e
Slave_SQL_Running_State:Slave přečetl celý protokol přenosu; čeká na další aktualizace
Retrieved_Gtid_Set:23b326b1-a452-11e8-91ca-000d3a065e8e:818-389213
Executed_Gtid_Set:23b326b1-a452-11e8-91ca-000d3a065e8e:1-389213
Když je hodnota SBM nulová nebo kladná
- SBM bude odrážet platnou hodnotu (>=0), když vlákno SQL aktivně zpracovává události. To platí bez ohledu na stav IO vlákna. Například:
Slave_IO_State:
Hlavní_hostitel:172.19.0.13
Slave_IO_Running:Ne
Slave_SQL_Running:Ano
Seconds_Behind_Master:3399
Master_UUID:23b326b1-a452-11e8-91ca-000d3a065e8e
Slave_SQL_Running_State:Čekání, až podřízení pracovníci zpracují své fronty
Retrieved_Gtid_Set:23b326b1-a452-11e8-91ca-000d3a065e8e:818-389213
Executed_Gtid_Set:23b326b1-a452-11e8-91ca-000d3a065e8e:1-118774
Ve výše uvedeném příkladu můžeme porovnáním Retrieved_GTID_Set a Executed_GTID_Set vidět, že slave je za masterem. V takových případech bude Seconds_Behind_Master představovat rozdíl mezi časovým razítkem poslední transakce zpracované podprocesem SQL a časovým razítkem stejné transakce, když byla zpracována na hlavním serveru. Toto časové razítko transakce hlavního serveru je zachováno prostřednictvím replikace, a proto bude podřízený počítač schopen vypočítat SBM lokálně.
Také, jakmile slave plně dožene všechny protokoly přenosu (tj. provedené GTID se změní na 23b326b1-a452-11e8-91ca-000d3a065e8e:1-389213/), Seconds_Behind_Master přepněte na '0', pokud je IO vlákno spuštěno, nebo na 'NULL', pokud IO vlákno neběží.
#Výukový program MySQL – Porozumění vteřinám za mistrem ValueClick to Tweet
Pochopení rychlosti spouštění MySQL Slave
Za předpokladu, že vlákno SQL a vlákno IO na podřízeném zařízení jsou ve spuštěném stavu, je možné porozumět relativní rychlosti provádění hlavního a podřízeného monitoru sledováním hodnoty SBM. Konzistentní hodnota „0“ nebo konstantní hodnota značí, že slave pracuje stejnou rychlostí jako master. Na druhou stranu vzestupný sklon pro Seconds_Behind_Master znamená, že podřízený pracuje pomaleji než hlavní.
Monitorovací konzola ScaleGrid pro MySQL v Azure vykresluje hodnoty SBM v průběhu času pro podřízené uzly.
Nulová nebo konstantní hodnota SBM
Ve výše uvedeném příkladu byl slave spuštěn asi 40 hodin poté, co měl master aktivní zápis. Po spuštění začal slave replikovat tato data a vidíme, že SBM byl docela plochý, což naznačuje, že slave byl spuštěn stejnou rychlostí jako master. Všimněte si také, že pokles SBM na '0' je strmý, což ve skutečnosti znamená, že ačkoli poslední transakce, kterou slave provedl, byla provedena asi 40 hodin předtím na masteru, jakmile to doženeme, je tu zpoždění '0'.
Zvyšování hodnot SBM
V níže uvedeném grafu můžeme vidět, že SBM se neustále zvyšuje, což znamená, že rychlost provádění podřízeného zařízení je nižší než u hlavního. Toto je ve skutečnosti případ, kdy provozujeme 20 vláken, která nepřetržitě zapisuje na master a jednovláknový slave s tím není schopen držet krok.
Nakonec je důležité poznamenat, že v našich diskuzích jsme zatím nepředpokládali žádná úzká hrdla sítě. V případě pomalých sítí bude samotné podřízené IO vlákno zaostávat za hlavním, a pokud je SQL vlákno dostatečně rychlé, SBM bude oscilovat mezi ‚0‘ a kladným číslem. V takových případech nebude SBM užitečným parametrem pro pochopení skutečného zpoždění s masterem.
Pokud se vám tento blogový příspěvek líbil, podívejte se na naše další oblíbené výukové programy pro správu databází MySQL, kde se dozvíte více o optimalizaci vašich nasazení:
- Výpočet velikosti fondu vyrovnávací paměti InnoDB pro váš server MySQL
- Výukový program MySQL – Konfigurace a správa SSL na vašem serveru MySQL
- Vysvětlení rámce MySQL High Availability Framework – Část I:Úvod
