Dzienniki binarne (binlogs) zawierają zapisy wszystkich zmian w bazach danych. Są one niezbędne do replikacji i mogą być również używane do przywracania danych po utworzeniu kopii zapasowej. Serwer binlog to w zasadzie repozytorium logów binarnych. Możesz myśleć o tym jak o serwerze z dedykowanym celem pobierania logów binarnych z serwera głównego, podczas gdy serwery podrzędne mogą łączyć się z nim tak, jak łączyłyby się z serwerem głównym.
Niektóre zalety posiadania serwera binlog nad pośrednim systemem głównym do dystrybucji obciążenia replikacji to:
- Możesz przełączyć się na nowy serwer główny bez zauważania przez serwery podrzędne, że rzeczywisty serwer główny się zmienił. Pozwala to na bardziej dostępną konfigurację replikacji, w której replikacja ma wysoki priorytet.
- Zmniejsz obciążenie mastera, obsługując tylko serwer binlog Maxscale zamiast wszystkich slave'ów.
- Dane w dzienniku binarnym głównego urządzenia pośredniczącego nie są bezpośrednią kopią danych otrzymanych z dziennika binarnego rzeczywistego urządzenia głównego. W związku z tym, jeśli używane jest zatwierdzanie grupowe, może to spowodować zmniejszenie równoległości zatwierdzeń, a następnie zmniejszenie wydajności serwerów podrzędnych.
- Pośrednie urządzenie podrzędne musi ponownie wykonać każdą instrukcję SQL, która potencjalnie zwiększa opóźnienia i opóźnienia w łańcuchu replikacji.
W tym poście na blogu przyjrzymy się, jak zastąpić serwer pośredniczący (przekaźnik hosta podrzędnego na inne urządzenia podrzędne w łańcuchu replikacji) serwerem binlog działającym na MaxScale w celu uzyskania lepszej skalowalności i wydajności .
Architektura
W zasadzie mamy konfigurację replikacji 4-węzłowej MariaDB v10.4 z jedną MaxScale v2.3, która znajduje się na szczycie replikacji, aby dystrybuować przychodzące zapytania. Tylko jedno urządzenie podrzędne jest podłączone do urządzenia nadrzędnego (głównego pośredniego), a pozostałe urządzenia podrzędne replikują się z urządzenia nadrzędnego pośredniego, aby obsługiwać obciążenia odczytu, jak pokazano na poniższym diagramie.
Zmienimy powyższą topologię w następującą:
Zasadniczo usuniemy pośrednią rolę mistrza i zastąpimy ją serwer binlog działający na MaxScale. Pośredni master zostanie przekonwertowany na standardowy slave, tak jak inne hosty slave. Usługa binlog będzie nasłuchiwać na porcie 5306 na hoście MaxScale. Jest to port, z którym będą się łączyć wszystkie urządzenia podrzędne w celu późniejszej replikacji.
Konfigurowanie MaxScale jako serwera Binlog
W tym przykładzie mamy już MaxScale, który znajduje się na szczycie naszego klastra replikacji, działając jako system równoważenia obciążenia dla naszych aplikacji. Jeśli nie masz MaxScale, możesz użyć ClusterControl do wdrożenia, po prostu przejdź do Cluster Actions -> Add Load Balancer -> MaxScale i wypełnij niezbędne informacje w następujący sposób:
Zanim zaczniemy, wyeksportujmy bieżącą konfigurację MaxScale do pliku tekstowego do tworzenia kopii zapasowych. MaxScale ma w tym celu flagę o nazwie --export-config, ale musi być wykonana jako użytkownik maxscale. Zatem polecenie do eksportu to:
$ su -s /bin/bash -c '/bin/maxscale --export-config=/tmp/maxscale.cnf' maxscaleNa urządzeniu głównym MariaDB utwórz użytkownika podrzędnego replikacji o nazwie „maxscale_slave”, który ma być używany przez MaxScale i przypisz mu następujące uprawnienia:
$ mysql -uroot -p -h192.168.0.91 -P3306
MariaDB> CREATE USER 'maxscale_slave'@'%' IDENTIFIED BY 'BtF2d2Kc8H';
MariaDB> GRANT SELECT ON mysql.user TO 'maxscale_slave'@'%';
MariaDB> GRANT SELECT ON mysql.db TO 'maxscale_slave'@'%';
MariaDB> GRANT SELECT ON mysql.tables_priv TO 'maxscale_slave'@'%';
MariaDB> GRANT SELECT ON mysql.roles_mapping TO 'maxscale_slave'@'%';
MariaDB> GRANT SHOW DATABASES ON *.* TO 'maxscale_slave'@'%';
MariaDB> GRANT REPLICATION SLAVE ON *.* TO 'maxscale_slave'@'%';W przypadku użytkowników ClusterControl przejdź do Zarządzaj -> Schematy i użytkownicy, aby utworzyć niezbędne uprawnienia.
Zanim przejdziemy dalej z konfiguracją, ważne jest, aby sprawdzić aktualny stan i topologię naszych serwerów zaplecza:
$ maxctrl list servers
┌────────┬──────────────┬──────┬─────────────┬──────────────────────────────┬───────────┐
│ Server │ Address │ Port │ Connections │ State │ GTID │
├────────┼──────────────┼──────┼─────────────┼──────────────────────────────┼───────────┤
│ DB_757 │ 192.168.0.90 │ 3306 │ 0 │ Master, Running │ 0-38001-8 │
├────────┼──────────────┼──────┼─────────────┼──────────────────────────────┼───────────┤
│ DB_758 │ 192.168.0.91 │ 3306 │ 0 │ Relay Master, Slave, Running │ 0-38001-8 │
├────────┼──────────────┼──────┼─────────────┼──────────────────────────────┼───────────┤
│ DB_759 │ 192.168.0.92 │ 3306 │ 0 │ Slave, Running │ 0-38001-8 │
├────────┼──────────────┼──────┼─────────────┼──────────────────────────────┼───────────┤
│ DB_760 │ 192.168.0.93 │ 3306 │ 0 │ Slave, Running │ 0-38001-8 │
└────────┴──────────────┴──────┴─────────────┴──────────────────────────────┴───────────┘Jak widać, aktualnym wzorcem jest DB_757 (192.168.0.90). Zanotuj te informacje, ponieważ zamierzamy skonfigurować serwer binlog do replikacji z tego wzorca.
Otwórz plik konfiguracyjny MaxScale w /etc/maxscale.cnf i dodaj następujące wiersze:
[replication-service]
type=service
router=binlogrouter
user=maxscale_slave
password=BtF2d2Kc8H
version_string=10.4.12-MariaDB-log
server_id=9999
master_id=9999
mariadb10_master_gtid=true
filestem=binlog
binlogdir=/var/lib/maxscale/binlogs
semisync=true # if semisync is enabled on the master
[binlog-server-listener]
type=listener
service=replication-service
protocol=MariaDBClient
port=5306
address=0.0.0.0Trochę wyjaśnienia - Tworzymy dwa komponenty - serwis i słuchacz. Serwis to miejsce, w którym definiujemy charakterystykę serwera binlog i sposób jego działania. Szczegóły dotyczące każdej opcji można znaleźć tutaj. W tym przykładzie nasze serwery replikacji działają z replikacją semi-sync, dlatego musimy użyć semisync=true, aby połączyć się z serwerem głównym za pomocą metody replikacji semi-sync. Listener to miejsce, w którym mapujemy port nasłuchiwania z usługą binlogrouter w MaxScale.
Uruchom ponownie MaxScale, aby załadować zmiany:
$ systemctl restart maxscaleSprawdź, czy usługa binlog jest uruchomiona przez maxctrl (spójrz na kolumnę Stan):
$ maxctrl show service replication-serviceSprawdź, czy MaxScale nasłuchuje teraz nowego portu dla usługi binlog:
$ netstat -tulpn | grep maxscale
tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN 4850/maxscale
tcp 0 0 0.0.0.0:3307 0.0.0.0:* LISTEN 4850/maxscale
tcp 0 0 0.0.0.0:5306 0.0.0.0:* LISTEN 4850/maxscale
tcp 0 0 127.0.0.1:8989 0.0.0.0:* LISTEN 4850/maxscaleJesteśmy teraz gotowi do ustanowienia łącza replikacji między MaxScale a masterem.
Aktywacja serwera Binlog
Zaloguj się do serwera głównego MariaDB i pobierz bieżący plik i pozycję binlogu:
MariaDB> SHOW MASTER STATUS;
+---------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+---------------+----------+--------------+------------------+
| binlog.000005 | 4204 | | |
+---------------+----------+--------------+------------------+Użyj funkcji BINLOG_GTID_POS, aby uzyskać wartość GTID:
MariaDB> SELECT BINLOG_GTID_POS("binlog.000005", 4204);
+----------------------------------------+
| BINLOG_GTID_POS("binlog.000005", 4204) |
+----------------------------------------+
| 0-38001-31 |
+----------------------------------------+Wróć do serwera MaxScale, zainstaluj pakiet klienta MariaDB:
$ yum install -y mysql-client
Połącz się z odbiornikiem serwera binlog na porcie 5306 jako użytkownik maxscale_slave i utwórz łącze replikacji do wyznaczonego mastera. Użyj wartości GTID pobranej z wzorca:
(maxscale)$ mysql -u maxscale_slave -p'BtF2d2Kc8H' -h127.0.0.1 -P5306
MariaDB> SET @@global.gtid_slave_pos = '0-38001-31';
MariaDB> CHANGE MASTER TO MASTER_HOST = '192.168.0.90', MASTER_USER = 'maxscale_slave', MASTER_PASSWORD = 'BtF2d2Kc8H', MASTER_PORT=3306, MASTER_USE_GTID = slave_pos;
MariaDB> START SLAVE;
MariaDB [(none)]> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Slave_IO_State: Binlog Dump
Master_Host: 192.168.0.90
Master_User: maxscale_slave
Master_Port: 3306
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Master_Server_Id: 38001
Master_Info_File: /var/lib/maxscale/binlogs/master.ini
Slave_SQL_Running_State: Slave running
Gtid_IO_Pos: 0-38001-31Uwaga:powyższe dane wyjściowe zostały obcięte, aby pokazać tylko ważne wiersze.
Wskazywanie niewolników na serwer Binlog
Teraz na mariadb2 i mariadb3 (końcowe urządzenia podrzędne) zmień mastera wskazujący na serwer MaxScale binlog. Ponieważ działamy z włączoną replikacją półsynchronizowaną, musimy je najpierw wyłączyć:
(mariadb2 & mariadb3)$ mysql -uroot -p
MariaDB> STOP SLAVE;
MariaDB> SET global rpl_semi_sync_master_enabled = 0; -- if semisync is enabled
MariaDB> SET global rpl_semi_sync_slave_enabled = 0; -- if semisync is enabled
MariaDB> CHANGE MASTER TO MASTER_HOST = '192.168.0.95', MASTER_USER = 'maxscale_slave', MASTER_PASSWORD = 'BtF2d2Kc8H', MASTER_PORT=5306, MASTER_USE_GTID = slave_pos;
MariaDB> START SLAVE;
MariaDB> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.0.95
Master_User: maxscale_slave
Master_Port: 5306
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Master_Server_Id: 9999
Using_Gtid: Slave_Pos
Gtid_IO_Pos: 0-38001-32
Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update itUwaga:powyższe dane wyjściowe zostały obcięte, aby pokazać tylko ważne wiersze.
Wewnątrz my.cnf musimy skomentować następujące wiersze, aby wyłączyć półsynchronizację w przyszłości:
#loose_rpl_semi_sync_slave_enabled=ON
#loose_rpl_semi_sync_master_enabled=ONW tym momencie pośredniczący master (mariadb1) nadal replikuje się z mastera (mariadb0), podczas gdy inne slave'y replikują się z serwera binlog. Naszą obecną topologię można zilustrować jak na poniższym diagramie:
Ostatnią częścią jest zmiana wskazania wzorca wzorca pośredniego (mariadb1 ) po tym, jak nie ma już wszystkich niewolników, którzy się do niego przyłączali. Kroki są w zasadzie takie same w przypadku innych urządzeń podrzędnych:
(mariadb1)$ mysql -uroot -p
MariaDB> STOP SLAVE;
MariaDB> SET global rpl_semi_sync_master_enabled = 0; -- if semisync is enabled
MariaDB> SET global rpl_semi_sync_slave_enabled = 0; -- if semisync is enabled
MariaDB> CHANGE MASTER TO MASTER_HOST = '192.168.0.95', MASTER_USER = 'maxscale_slave', MASTER_PASSWORD = 'BtF2d2Kc8H', MASTER_PORT=5306, MASTER_USE_GTID = slave_pos;
MariaDB> START SLAVE;
MariaDB> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.0.95
Master_User: maxscale_slave
Master_Port: 5306
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Master_Server_Id: 9999
Using_Gtid: Slave_Pos
Gtid_IO_Pos: 0-38001-32Uwaga:powyższe dane wyjściowe zostały obcięte, aby pokazać tylko ważne wiersze.
Nie zapomnij wyłączyć replikacji półsynchronizowanej również w my.cnf:
#loose_rpl_semi_sync_slave_enabled=ON
#loose_rpl_semi_sync_master_enabled=ONMożemy sprawdzić, czy usługa routera binlog ma teraz więcej połączeń za pomocą maxctrl CLI:
$ maxctrl list services
┌─────────────────────┬────────────────┬─────────────┬───────────────────┬───────────────────────────────────┐
│ Service │ Router │ Connections │ Total Connections │ Servers │
├─────────────────────┼────────────────┼─────────────┼───────────────────┼───────────────────────────────────┤
│ rw-service │ readwritesplit │ 1 │ 1 │ DB_757, DB_758, DB_759, DB_760 │
├─────────────────────┼────────────────┼─────────────┼───────────────────┼───────────────────────────────────┤
│ rr-service │ readconnroute │ 1 │ 1 │ DB_757, DB_758, DB_759, DB_760 │
├─────────────────────┼────────────────┼─────────────┼───────────────────┼───────────────────────────────────┤
│ replication-service │ binlogrouter │ 4 │ 51 │ binlog_router_master_host, DB_757 │
└─────────────────────┴────────────────┴─────────────┴───────────────────┴───────────────────────────────────┘Również typowe polecenia administracyjne replikacji mogą być używane wewnątrz serwera binlog MaxScale, na przykład możemy zweryfikować podłączone hosty slave za pomocą tego polecenia:
(maxscale)$ mysql -u maxscale_slave -p'BtF2d2Kc8H' -h127.0.0.1 -P5306
MariaDB> SHOW SLAVE HOSTS;
+-----------+--------------+------+-----------+------------+
| Server_id | Host | Port | Master_id | Slave_UUID |
+-----------+--------------+------+-----------+------------+
| 38003 | 192.168.0.92 | 3306 | 9999 | |
| 38002 | 192.168.0.91 | 3306 | 9999 | |
| 38004 | 192.168.0.93 | 3306 | 9999 | |
+-----------+--------------+------+-----------+------------+W tym momencie nasza topologia wygląda tak, jak oczekiwaliśmy:
Nasza migracja z pośredniej konfiguracji głównej do konfiguracji serwera binlog została zakończona.
