W konfiguracji replikacji hostingu MySQL, parametr Seconds_Behind_Master (SBM), wyświetlany przez polecenie SHOW SLAVE STATUS, jest powszechnie używany jako wskazanie bieżącego opóźnienia replikacji urządzenia podrzędnego . W tym poście na blogu sprawdzamy, jak rozumieć i interpretować tę wartość w różnych sytuacjach.
Możliwe wartości sekund za mistrzem
Wartość SBM, jak wyjaśniono w dokumentacji MySQL, zależy ogólnie od stanu urządzenia podrzędnego MySQL, a w szczególności od stanów podrzędnych MySQL SQL_THREAD i IO_THREAD. Podczas gdy IO_THREAD łączy się z urządzeniem głównym i odczytuje aktualizacje, SQL_THREAD stosuje te aktualizacje na urządzeniu podrzędnym. Przyjrzyjmy się możliwym wartościom SBM w różnych stanach MySQL Slave.
Kiedy wartość SBM wynosi zero
- SBM jest zawsze NULL, jeśli twój slave jest zatrzymany lub twój wątek SQL jest zatrzymany (lub nie działa).
- SBM również będzie miał wartość NULL, jeśli wątek IO zostanie zatrzymany, pod warunkiem, że wątek SQL przetworzył już wszystkie zdarzenia z dziennika przekazywania. Przykładowe dane wyjściowe SHOW SLAVE STATUS (przycięte, aby pokazać tylko interesujące wartości) pokazują to:
Slave_IO_State:
Master_Host:172.19.0.13
Slave_IO_Running:Nie
Slave_SQL_Running:Tak
Seconds_Behind_Master:NULL
Master_UUID:23b326b1-a452-11e8-91ca-000d3a065e8e
Slave_SQL_Running_State:Slave odczytał cały dziennik przekaźników; czekam na więcej aktualizacji
Retrieved_Gtid_Set:23b326b1-a452-11e8-91ca-000d3a065e8e:818-389213
Executed_Gtid_Set:23b326b1-a452-11e8-91ca-000d3a065e8e:1-389213
Kiedy wartość SBM jest zerowa lub dodatnia
- SBM będzie odzwierciedlać prawidłową wartość (>=0) gdy wątek SQL aktywnie przetwarza zdarzenia. Dzieje się tak niezależnie od stanu wątku we/wy. Na przykład:
Slave_IO_State:
Master_Host:172.19.0.13
Slave_IO_Running:Nie
Slave_SQL_Running:Tak
Seconds_Behind_Master:3399
Master_UUID:23b326b1-a452-11e8-91ca-000d3a065e8e
Slave_SQL_Running_State:Oczekiwanie na przetwarzanie kolejek przez pracowników niewolników
Retrieved_Gtid_Set:23b326b1-a452-11e8-91ca-000d3a065e8e:818-389213
Executed_Gtid_Set:23b326b1-a452-11e8-91ca-000d3a065e8e:1-118774
W powyższym przykładzie możemy zobaczyć, że slave jest za masterem, porównując Retrieved_GTID_Set i Executed_GTID_Set. W takich przypadkach Seconds_Behind_Master będzie reprezentować różnicę między sygnaturą czasową ostatniej transakcji przetworzonej przez wątek SQL a sygnaturą czasową tej samej transakcji, która została przetworzona na wzorcu. Ten znacznik czasu transakcji urządzenia nadrzędnego jest zachowywany przez replikację, dzięki czemu urządzenie podrzędne będzie w stanie obliczyć SBM lokalnie.
Ponadto, gdy urządzenie podrzędne w pełni nadrobi wszystkie dzienniki przekaźnika (tj. wykonany numer GTID zmieni się na 23b326b1-a452-11e8-91ca-000d3a065e8e:1-389213/), Seconds_Behind_Master zmień na '0', jeśli wątek IO jest uruchomiony, lub na 'NULL', jeśli wątek IO nie jest uruchomiony.
Samouczek #MySQL – Zrozumienie sekund kryjących się za główną wartościąKliknij, aby tweetować
Zrozumienie szybkości wykonywania MySQL Slave
Zakładając, że wątek SQL i wątek IO na urządzeniu podrzędnym są w stanie działania, możliwe jest zrozumienie względnych szybkości wykonania urządzenia nadrzędnego i podrzędnego poprzez monitorowanie wartości SBM. Stała wartość „0” lub stała wartość wskazuje, że slave pracuje z taką samą prędkością jak master. Z drugiej strony nachylenie w górę dla Seconds_Behind_Master wskazuje, że slave działa wolniej niż master.
Konsola monitorowania ScaleGrid dla MySQL na platformie Azure wykreśla wartości SBM w czasie dla węzłów podrzędnych.
Zerowa lub stała wartość SBM
W powyższym przykładzie slave został uruchomiony około 40 godzin po tym, jak master miał aktywne zapisy. Po uruchomieniu urządzenie podrzędne zaczęło replikować te dane i widzimy, że SBM był dość płaski, co wskazuje, że urządzenie podrzędne jest wykonywane z taką samą prędkością, jak urządzenie główne. Zwróć też uwagę, że spadek SBM do „0” jest stromy, co tak naprawdę oznacza, że chociaż ostatnia transakcja, którą uruchomił moduł slave, została wykonana około 40 godzin wcześniej na urządzeniu głównym, po nadrobieniu zaległości występuje opóźnienie „0”.
Wzrost wartości SBM
Na poniższym wykresie widzimy, że SBM stale rośnie, co oznacza, że szybkość wykonania slave'a jest mniejsza w porównaniu z masterem. W rzeczywistości jest to przypadek, w którym uruchamiamy 20 wątków wykonujących ciągłe zapisy na urządzeniu głównym, a jednowątkowy slave nie jest w stanie nadążyć za nim.
Na koniec należy zauważyć, że w naszych dotychczasowych dyskusjach nie zakładaliśmy żadnych wąskich gardeł w sieci. W przypadku wolnych sieci, sam podrzędny wątek IO będzie pozostawał w tyle za masterem, a jeśli wątek SQL jest wystarczająco szybki, SBM będzie oscylował między „0” a liczbą dodatnią. W takich przypadkach SBM nie będzie użytecznym parametrem do zrozumienia rzeczywistego opóźnienia w stosunku do mastera.
Jeśli podobał Ci się ten wpis na blogu, zapoznaj się z naszymi innymi popularnymi samouczkami dotyczącymi zarządzania bazą danych MySQL, aby dowiedzieć się więcej o optymalizacji wdrożeń:
- Obliczanie rozmiaru puli buforów InnoDB dla twojego serwera MySQL
- Samouczek MySQL – Konfiguracja i zarządzanie SSL na serwerze MySQL
- Wyjaśnienie struktury MySQL High Availability Framework – część I:Wprowadzenie
