MySQL nie ogranicza liczby urządzeń podrzędnych, które można połączyć z serwerem głównym w topologii replikacji. Jednak wraz ze wzrostem liczby urządzeń podrzędnych będą one miały wpływ na zasoby główne, ponieważ logi binarne będą musiały być udostępniane różnym urządzeniom podrzędnym pracującym z różnymi prędkościami. Jeśli rotacja danych w urządzeniu głównym jest wysoka, sama obsługa dzienników binarnych może nasycić interfejs sieciowy urządzenia głównego.
Klasycznym rozwiązaniem tego problemu jest wdrożenie serwera binlog – pośredniego serwera proxy, który znajduje się pomiędzy masterem a jego slave’ami. Serwer binlog jest skonfigurowany jako slave do mastera, który z kolei działa jako master do oryginalnego zestawu slave'ów. Odbiera zdarzenia z dziennika binarnego od urządzenia nadrzędnego, nie stosuje tych zdarzeń, ale udostępnia je wszystkim innym urządzeniom podrzędnym. W ten sposób obciążenie mastera jest ogromnie zmniejszone, a jednocześnie serwer binlogów wydajniej obsługuje binlogi do urządzeń podrzędnych, ponieważ nie musi wykonywać żadnego innego przetwarzania na serwerze bazy danych.
Ripple to serwer binlogów typu open source opracowany przez Pawła Iwanowa. Wpis na blogu firmy Percona, zatytułowany MySQL Ripple:The First Impression of a MySQL Binlog Server, stanowi bardzo dobre wprowadzenie do wdrażania i używania Ripple. Miałem okazję poznać Ripple bardziej szczegółowo i chciałem podzielić się swoimi spostrzeżeniami w tym poście.
1. Obsługa replikacji opartej na GTID
Ripple obsługuje tylko tryb GTID, a nie replikację opartą na plikach i pozycji. Jeśli twój master działa w trybie innym niż GTID, otrzymasz ten błąd od Ripple:
Nie udało się odczytać pakietu:Otrzymano błąd odczytu pakietu z serwera:Wątek nadawcy replikacji nie może uruchomić się w trybie AUTO_POSITION:ten serwer ma GTID_MODE =OFF zamiast ON.
Możesz określić Server_id i UUID dla serwera ripple za pomocą opcji wiersza polecenia: -ripple_server_id i -ripple_server_uuid
Oba są parametrami opcjonalnymi i jeśli nie zostaną określone, Ripple użyje domyślnego server_id=112211, a uuid zostanie wygenerowany automatycznie.
2. Łączenie się z urządzeniem głównym za pomocą użytkownika i hasła replikacji
Podczas łączenia się z masterem możesz określić użytkownika i hasło replikacji za pomocą opcji wiersza poleceń:
-ripple_master_user i -ripple_master_password
3. Punkt końcowy połączenia dla serwera Ripple
Możesz użyć opcji wiersza poleceń -ripple_server_ports i -ripple_server_address, aby określić punkty końcowe połączenia dla serwera Ripple. Upewnij się, że określiłeś dostępną w sieci nazwę hosta lub adres IP serwera Ripple jako -rippple_server_address. W przeciwnym razie Ripple domyślnie połączy się z hostem lokalnym, przez co nie będzie można połączyć się z nim zdalnie.
4. Konfigurowanie urządzeń podrzędnych na serwerze Ripple
Możesz użyć polecenia CHANGE MASTER TO, aby połączyć swoje urządzenia podrzędne w celu replikacji z serwera Ripple.
Aby upewnić się, że Ripple może uwierzytelnić hasło używane do łączenia się z nim, musisz uruchomić Ripple, określając opcję -ripple_server_password_hash
Na przykład, jeśli uruchomisz serwer ripple poleceniem:
rippled -ripple_datadir=./binlog_server -ripple_master_address=
możesz użyć następującego polecenia CHANGE MASTER TO, aby połączyć się z urządzenia podrzędnego:
ZMIEŃ MASTER NA master_host='172.31.23.201', master_port=15000, master_password='XpKWeZRNH5#satCI', master_user='rep'
Zauważ, że hash hasła określony dla serwera Ripple odpowiada hasłu tekstowemu użytemu w poleceniu CHANGE MASTER TO. Obecnie Ripple nie uwierzytelnia się na podstawie nazw użytkowników i akceptuje każdą niepustą nazwę użytkownika, o ile hasło jest zgodne.
Eksploracja serwera MySQL Binlog — RippleClick To Tweet5. Zarządzanie serwerem Ripple
Możliwe jest monitorowanie i zarządzanie serwerem Ripple przy użyciu protokołu MySQL z dowolnego standardowego klienta MySQL. Istnieje ograniczony zestaw obsługiwanych poleceń, które można zobaczyć bezpośrednio w kodzie źródłowym na stronie mysql-ripple GitHub.
Niektóre z przydatnych poleceń to:
SELECT @@global.gtid_executed;– Aby zobaczyć zestaw GTID serwera Ripple na podstawie pobranych dzienników binarnych.STOP SLAVE;– Aby odłączyć serwer Ripple od mastera.START SLAVE;– Aby połączyć serwer Ripple z masterem.
Znane problemy i sugestie usprawnień
1. Nie widziałem opcji ustawienia kanału replikacji SSL z serwera Ripple do mastera
W wyniku tego serwer Ripple nie będzie mógł połączyć się z masterem, który nakazuje szyfrowane połączenia. Próba połączenia spowoduje błąd:
0322 09:01:36.555124 14942 mysql_master_session.cc:164] Nie udało się połączyć z hostem:
2. Nie udało mi się uruchomić serwera Ripple z opcją półsynchronizacji
Uruchomiłem serwer Ripple za pomocą opcji -ripple_semi_sync_slave_enabled=true
Podłączając go, master był w stanie wykryć serwer Ripple jako slave obsługujący półsynchronizację.
mysql> pokaż status jak 'rpl%';
--------------------------------- ---------------------
| Nazwa_zmiennej | Wartość |
----------------------------------------------- ----------
| Rpl_semi_sync_master_clients | 1 |
| Rpl_semi_sync_master_status | WŁĄCZONE |
| Rpl_semi_sync_slave_status | WYŁĄCZONE |
------------------------------------------------ ----------
Jednak próba wykonania transakcji w trybie półsynchronizacji oczekiwała na rpl_semi_sync_master_timeout, który wynosił 180000
mysql> utwórz bazę danych d12;
Zapytanie OK, wpływ na 1 wiersz (3 min 0,01 s)
Widziałem, że półsynchronizacja została wyłączona w urządzeniu głównym:
mysql> pokaż status jak 'rpl%';
+-------------------------------- ------------+-------+
| Nazwa_zmiennej | Wartość |
+----------------------------------------------- -+-------+
| Rpl_semi_sync_master_clients | 1 |
| Rpl_semi_sync_master_status | WYŁĄCZONE |
| Rpl_semi_sync_slave_status | WYŁĄCZONE |
+------------------------------------------------ -+-------+
Odpowiadający fragment z dzienników błędów mysql:
2020-03-21T10:05:56.000612Z 52 [Uwaga] Uruchom binlog_dump do master_thread_id(52) slave_server(112211), poz(, 4)
2020-03-21T10:05:56.000627Z 52 [ Uwaga] Uruchom półsynchronizację binlog_dump do slave (server_id:112211), pos(, 4)
20020-03-21T10:08:55.873990Z 2 [Ostrzeżenie] Limit czasu oczekiwania na odpowiedź binlog (plik:mysql-bin .000010, poz:350), półsynchronizacja do pliku , pozycja 4.
2020-03-21T10:08:55.874044Z 2 [Uwaga] Wyłączona replikacja półsync.
Wystąpił problem zgłoszony w podobny sposób tutaj na stronie MySQL Ripple Github.
3. Problem podczas korzystania z replikacji równoległej dla urządzeń podrzędnych serwera Ripple
Widziałem, że wątek SQL na urządzeniu podrzędnym często zatrzymywał się z błędem:
Last_SQL_Error:Nie można wykonać bieżącej grupy zdarzeń w trybie równoległym. Napotkane zdarzenie Gtid, nazwa relay-log /mysql_data/relaylogs/relay-log.000005, pozycja 27023962, która uniemożliwia wykonanie tej grupy zdarzeń w trybie równoległym. Przyczyna:zdarzenie główne ma logicznie niepoprawny znacznik czasu.
Analiza powyższego dziennika przekaźnika i pozycji ujawniła, że „numer sekwencyjny” transakcji w tym momencie został zresetowany do 1. Wyśledziłem przyczynę rotacji binlogów na oryginalny mistrz. Zazwyczaj w przypadku bezpośrednich urządzeń podrzędnych występuje zdarzenie obracania, w wyniku którego dzienniki przekaźnika również będą się obracać w oparciu o rotację głównego dziennika binarnego. Moja ocena jest taka, że takie warunki mogą zostać wykryte, a resetowanie numeru sekwencji może być obsługiwane przez równoległe wątki. Ale gdy numer sekwencyjny zmienia się bez rotacji dzienników przekaźnika, widzimy, że równoległe wątki zawodzą.
Ta obserwacja jest zgłaszana jako problem:awaria równoległego wątku podrzędnego podczas synchronizacji z serwerem binlog #26
4. Narzędzie mysqlbinlog nie działa na dziennikach binarnych generowanych przez serwer Ripple
Próba uruchomienia narzędzia mysqlbinlog w dzienniku binarnym zakończyła się błędem:
BŁĄD:Błąd w Log_event::read_log_event():„Znaleziono nieprawidłowe zdarzenie w dzienniku binarnym”, data_len:43, event_type:-106
Ten problem został podniesiony tutaj:nie można otworzyć plików dziennika binarnego za pomocą narzędzia mysqlbinlog. #25
Autor uznał to za znany problem. Uważam, że przydałoby się wspierać to narzędzie do celów debugowania.
To na razie raport z moich szybkich testów. Planuję aktualizować ten wpis na blogu, gdy natrafię na więcej ustaleń dotyczących Ripple. Ogólnie uważam, że jest prosty w użyciu i może stać się standardem dla serwerów binlog w środowiskach MySQL.
|
