MySQL beperkt niet het aantal slaves dat u kunt verbinden met de masterserver in een replicatietopologie. Naarmate het aantal slaves toeneemt, zullen ze echter een negatieve invloed hebben op de masterbronnen, omdat de binaire logs moeten worden aangeboden aan verschillende slaves die met verschillende snelheden werken. Als het dataverloop op de master hoog is, kan het aanbieden van binaire logs alleen de netwerkinterface van de master verzadigen.
Een klassieke oplossing voor dit probleem is het implementeren van een binlog-server - een tussenliggende proxyserver die tussen de master en zijn slaven zit. De binlog-server is ingesteld als een slave voor de master en fungeert op zijn beurt als een master voor de oorspronkelijke set slaves. Het ontvangt binaire loggebeurtenissen van de master, past deze gebeurtenissen niet toe, maar geeft ze door aan alle andere slaven. Op deze manier wordt de belasting van de master enorm verminderd en tegelijkertijd bedient de binlog-server de binlogs efficiënter aan slaves, omdat hij geen andere databaseserververwerking hoeft uit te voeren.
Ripple is een open source binlog-server ontwikkeld door Pavel Ivanov. Een blogpost van Percona, getiteld MySQL Ripple:The First Impression of a MySQL Binlog Server, geeft een zeer goede introductie tot het implementeren en gebruiken van Ripple. Ik had de kans om Ripple wat meer in detail te verkennen en wilde mijn observaties via dit bericht delen.
1. Ondersteuning voor op GTID gebaseerde replicatie
Ripple ondersteunt alleen de GTID-modus en niet op bestanden en posities gebaseerde replicatie. Als je master in niet-GTID-modus draait, krijg je deze foutmelding van Ripple:
Kan pakket niet lezen:kreeg een fout bij het lezen van pakket van server:de thread van de replicatieafzender kan niet starten in de AUTO_POSITION-modus:deze server heeft GTID_MODE =UIT in plaats van AAN.
U kunt Server_id en UUID voor de ripple-server specificeren met behulp van de cmd-regelopties: -ripple_server_id en -ripple_server_uuid
Beide zijn optionele parameters, en indien niet gespecificeerd, gebruikt Ripple de standaard server_id=112211 en wordt uuid automatisch gegenereerd.
2. Verbinding maken met de master met behulp van replicatiegebruiker en wachtwoord
Terwijl u verbinding maakt met de master, kunt u de replicatiegebruiker en het wachtwoord specificeren met behulp van de opdrachtregelopties:
-ripple_master_user en -ripple_master_password
3. Verbindingseindpunt voor de Ripple-server
U kunt de opdrachtregelopties -ripple_server_ports en -ripple_server_address gebruiken om de verbindingseindpunten voor de Ripple-server te specificeren. Zorg ervoor dat u de netwerktoegankelijke hostnaam of het IP-adres van uw Ripple-server specificeert als het -rippple_server_address. Anders zal Ripple standaard binden aan localhost en daarom kunt u er op afstand geen verbinding mee maken.
4. Slaves instellen op de Ripple-server
Je kunt het CHANGE MASTER TO commando gebruiken om je slaves te verbinden om te repliceren vanaf de Ripple-server.
Om ervoor te zorgen dat Ripple het wachtwoord dat u gebruikt om er verbinding mee te maken kan authenticeren, moet u Ripple starten door de optie -ripple_server_password_hash op te geven
Als je bijvoorbeeld de ripple-server start met het commando:
rippled -ripple_datadir=./binlog_server -ripple_master_address=
je kunt het volgende CHANGE MASTER TO commando gebruiken om verbinding te maken vanaf de slave:
WIJZIG MASTER IN master_host='172.31.23.201', master_port=15000, master_password='XpKWeZRNH5#satCI', master_user='rep'
Merk op dat de wachtwoordhash die is opgegeven voor de Ripple-server overeenkomt met het tekstwachtwoord dat wordt gebruikt in de opdracht CHANGE MASTER TO. Momenteel authenticeert Ripple niet op basis van de gebruikersnamen en accepteert het elke niet-lege gebruikersnaam zolang het wachtwoord overeenkomt.
MySQL Binlog-server verkennen - RippleClick To Tweet5. Ripple-serverbeheer
Het is mogelijk om de Ripple-server te bewaken en te beheren met behulp van het MySQL-protocol vanaf elke standaard MySQL-client. Er is een beperkt aantal ondersteunde commando's die je direct in de broncode kunt zien op de mysql-ripple GitHub-pagina.
Enkele van de handige commando's zijn:
SELECT @@global.gtid_executed;– Om de GTID SET van de Ripple-server te zien op basis van de gedownloade binaire logs.STOP SLAVE;– Om de Ripple-server los te koppelen van de master.START SLAVE;– Om de Ripple-server met de master te verbinden.
Bekende problemen en suggesties voor verbetering
1. Ik zag geen optie om een SSL-replicatiekanaal van een Ripple-server naar de master in te stellen
Als gevolg hiervan kan de Ripple-server geen verbinding maken met een master die versleutelde verbindingen verplicht stelt. Als u probeert verbinding te maken, krijgt u de volgende foutmelding:
0322 09:01:36.555124 14942 mysql_master_session.cc:164] Kan geen verbinding maken met host:
2. Ik kon de Ripple-server niet laten werken met de semi-sync-optie
Ik startte de Ripple-server met de optie -ripple_semi_sync_slave_enabled=true
Bij het verbinden kon de master de Ripple-server detecteren als een semi-sync ingeschakelde slave.
mysql> toon status zoals 'rpl%';
--------------------------------- ---------------------
| Variabele_naam | Waarde |
-------------------------------------------- ----------
| Rpl_semi_sync_master_clients | 1 |
| Rpl_semi_sync_master_status | AAN |
| Rpl_semi_sync_slave_status | UIT |
-------------------------------------------- ----------
Bij een poging om een transactie in semi-sync-modus uit te voeren, werd echter gewacht op rpl_semi_sync_master_timeout, wat 180000 was
mysql> database d12 maken;
Query OK, 1 rij aangetast (3 min 0,01 sec)
Ik kon zien dat semi-sync was uitgeschakeld bij de master:
mysql> toon status zoals 'rpl%';
+-------------------------------- ------------+-------+
| Variabele_naam | Waarde |
+------------------------------------------- ++-------+
| Rpl_semi_sync_master_clients | 1 |
| Rpl_semi_sync_master_status | UIT |
| Rpl_semi_sync_slave_status | UIT |
+------------------------------------------- ++-------+
Overeenkomstig fragment uit de mysql-foutlogboeken:
2020-03-21T10:05:56.000612Z 52 [Opmerking] Start binlog_dump naar master_thread_id(52) slave_server(112211), pos(, 4)
2020-03-21T10:05:56.000627Z 52 [ Opmerking] Start semi-sync binlog_dump naar slave (server_id:112211), pos(, 4)
20020-03-21T10:08:55.873990Z 2 [Waarschuwing] Time-out bij wachten op antwoord van binlog (bestand:mysql-bin .000010, pos:350), semi-sync tot bestand , positie 4.
2020-03-21T10:08:55.874044Z 2 [Opmerking] Semi-sync replicatie uitgeschakeld.
Er is een probleem in soortgelijke zin gemeld hier op de MySQL Ripple Github-pagina.
3. Probleem bij gebruik van parallelle replicatie voor de slaves van Ripple-server
Ik zag dat SQL-thread op de slave vaak stopte met de fout:
Last_SQL_Error:Kan de huidige gebeurtenisgroep niet uitvoeren in de parallelle modus. Ondervonden gebeurtenis Gtid, relay-lognaam /mysql_data/relaylogs/relay-log.000005, positie 27023962 die uitvoering van deze gebeurtenisgroep in parallelle modus verhindert. Reden:De hoofdgebeurtenis heeft logischerwijs een onjuiste tijdstempel.
Analyse van het relaislogboek en de positie hierboven onthulde dat het 'volgnummer' van de transactie op dit punt was teruggezet naar 1. Ik heb de oorzaak opgespoord van een binlog-rotatie die plaatsvond op de originele meester. Gewoonlijk is er voor directe slaves een rotatiegebeurtenis waardoor relaislogboeken ook zouden roteren op basis van master-binaire logrotatie. Mijn beoordeling is dat dergelijke omstandigheden kunnen worden gedetecteerd en dat het resetten van het volgnummer kan worden afgehandeld door parallelle threads. Maar wanneer het volgnummer verandert zonder de rotatie van de relaislogboeken, zien we dat de parallelle threads falen.
Deze observatie wordt gerapporteerd als het probleem:slave parallelle thread-fout tijdens synchronisatie vanaf binlog-server #26
4. mysqlbinlog-hulpprogramma werkt niet op de binaire logbestanden die door de Ripple-server worden geproduceerd
Proberen om het hulpprogramma mysqlbinlog op het binaire logboek uit te voeren, resulteerde in de fout:
ERROR:Fout in Log_event::read_log_event():'Ongeldige gebeurtenis gevonden in binair logboek', data_len:43, event_type:-106
Dit probleem wordt hier aan de orde gesteld:kan de binaire logbestanden niet openen met het hulpprogramma mysqlbinlog. #25
Het is door de auteur erkend als een bekend probleem. Ik denk dat het nuttig zou zijn om dit hulpprogramma te ondersteunen voor foutopsporingsdoeleinden.
Dat is het rapport voor nu van mijn snelle tests. Ik ben van plan deze blogpost bij te werken als en wanneer ik meer bevindingen over Ripple tegenkom. Over het algemeen vond ik het eenvoudig en duidelijk te gebruiken en heeft het de potentie om een standaard te worden voor binlog-servers in MySQL-omgevingen.
|