MySQL begränsar inte antalet slavar som du kan ansluta till masterservern i en replikeringstopologi. Men när antalet slavar ökar kommer de att ha en vägtull på masterresurserna eftersom de binära loggarna kommer att behöva serveras till olika slavar som arbetar med olika hastigheter. Om datamängden på mastern är hög kan endast serveringen av binära loggar mätta masterns nätverksgränssnitt.
En klassisk lösning på detta problem är att distribuera en binlog-server – en mellanliggande proxyserver som sitter mellan mastern och dess slavar. Binlog-servern är inställd som en slav till mastern och fungerar i sin tur som en master till den ursprungliga uppsättningen av slavar. Den tar emot binära logghändelser från mastern, tillämpar inte dessa händelser, utan serverar dem till alla andra slavar. På så sätt reduceras belastningen på mastern enormt, och samtidigt servar binlog-servern binloggarna mer effektivt till slavar eftersom den inte behöver göra någon annan databasserverbearbetning.
Ripple är en binlogserver med öppen källkod utvecklad av Pavel Ivanov. Ett blogginlägg från Percona, med titeln MySQL Ripple:The First Impression of a MySQL Binlog Server, ger en mycket bra introduktion till att distribuera och använda Ripple. Jag hade en möjlighet att utforska Ripple mer i detalj och ville dela med mig av mina observationer genom det här inlägget.
1. Stöd för GTID-baserad replikering
Ripple stöder endast GTID-läge och inte fil- och positionsbaserad replikering. Om din master körs i icke-GTID-läge får du detta felmeddelande från Ripple:
Det gick inte att läsa paketet:Fick fel att läsa paketet från servern:Replikeringsavsändartråden kan inte starta i AUTO_POSITION-läge:denna server har GTID_MODE =OFF istället för ON.
Du kan ange Server_id och UUID för rippelservern med hjälp av cmd-radalternativen: -ripple_server_id och -ripple_server_uuid
Båda är valfria parametrar, och om de inte anges kommer Ripple att använda standardserver_id=112211 och uuid kommer att genereras automatiskt.
2. Ansluter till mastern med hjälp av replikeringsanvändare och lösenord
När du ansluter till mastern kan du ange replikeringsanvändare och lösenord med kommandoradsalternativen:
-ripple_master_user och -ripple_master_password
3. Anslutningsändpunkt för Ripple-servern
Du kan använda kommandoradsalternativen -ripple_server_ports och -ripple_server_address för att ange anslutningsslutpunkterna för Ripple-servern. Se till att ange det nätverkstillgängliga värdnamnet eller IP-adressen för din Ripple-server som -rippple_server_address. Annars kommer Ripple som standard att binda till localhost och du kommer därför inte att kunna ansluta till den på distans.
4. Konfigurera slavar till Ripple-servern
Du kan använda kommandot CHANGE MASTER TO för att ansluta dina slavar för att replikera från Ripple-servern.
För att säkerställa att Ripple kan autentisera lösenordet som du använder för att ansluta till det, måste du starta Ripple genom att ange alternativet -ripple_server_password_hash
Om du till exempel startar rippelservern med kommandot:
rippled -ripple_datadir=./binlog_server -ripple_master_address=
du kan använda följande CHANGE MASTER TO-kommando för att ansluta från slaven:
ÄNDRA MASTER TILL master_host='172.31.23.201', master_port=15000, master_password=’XpKWeZRNH5#satCI’, master_user=’rep’
Observera att lösenords-hash som anges för Ripple-servern motsvarar textlösenordet som används i kommandot CHANGE MASTER TO. För närvarande autentiserar Ripple inte baserat på användarnamnen och accepterar alla icke-tomma användarnamn så länge lösenordet matchar.
Utforska MySQL Binlog Server - RippleClick To Tweet5. Ripple-serverhantering
Det är möjligt att övervaka och hantera Ripple-servern med MySQL-protokollet från vilken standard MySQL-klient som helst. Det finns en begränsad uppsättning kommandon som stöds som du kan se direkt i källkoden på mysql-ripple GitHub-sidan.
Några av de användbara kommandona är:
SELECT @@global.gtid_executed;– För att se GTID-SET för Ripple-servern baserat på dess nedladdade binära loggar.STOPPA SLAV;– För att koppla bort Ripple-servern från mastern.STARTA SLAV;– För att ansluta Ripple-servern till mastern.
Kända problem och förbättringsförslag
1. Jag såg inte ett alternativ för att ställa in en SSL-replikeringskanal från en Ripple-server till mastern
Som ett resultat av detta kommer Ripple-servern inte att kunna ansluta till en master som kräver krypterade anslutningar. Ett försök att ansluta kommer att resultera i felet:
0322 09:01:36.555124 14942 mysql_master_session.cc:164] Det gick inte att ansluta till värden:
2. Jag kunde inte få Ripple-servern att fungera med semi-synkroniseringsalternativet
Jag startade Ripple-servern med alternativet -ripple_semi_sync_slave_enabled=true
När den ansluts kunde mastern upptäcka Ripple-servern som en semi-synk-aktiverad slav.
mysql> visa status som 'rpl%';
---------------------------------------- ----------------------
| Variabelnamn | Värde |
------------------------------------------------ ----------
| Rpl_semi_sync_master_clients | 1 |
| Rpl_semi_sync_master_status | PÅ |
| Rpl_semi_sync_slave_status | AV |
--------------------------------------------- ----------
Men att försöka utföra en transaktion i halvsynkroniserat läge väntade på rpl_semi_sync_master_timeout som var 180 000
mysql> skapa databas d12;
Fråga OK, 1 rad påverkad (3 min 0,01 sek)
Jag kunde se att halvsynkronisering stängdes av på mastern:
mysql> visa status som 'rpl%';
+-------------------------------- ------------+-------+
| Variabelnamn | Värde |
+------------------------------------------------ -+-------+
| Rpl_semi_sync_master_clients | 1 |
| Rpl_semi_sync_master_status | AV |
| Rpl_semi_sync_slave_status | AV |
+------------------------------------------------ -+-------+
Motsvarande utdrag från mysql-felloggarna:
2020-03-21T10:05:56.000612Z 52 [Notera] Starta binlog_dump till master_thread_id(52) slave_server(112211), pos(, 4)
2020-03-21T10:05:527Z 5 [526.000] Notera] Starta semi-sync binlog_dump to slave (server_id:112211), pos(, 4)
20020-03-21T10:08:55.873990Z 2 [Varning] Timeout väntar på svar från binlog (fil:mysql-bin .000010, pos:350), halvsynkroniserad upp till fil , position 4.
2020-03-21T10:08:55.874044Z 2 [Notera] Halvsynk replikering avstängd.
Det finns ett problem som rapporterats på liknande sätt här på MySQL Ripple Github-sidan.
3. Problem vid användning av parallell replikering för Ripple-serverns slavar
Jag såg att SQL-tråden på slaven ofta slutade med felet:
Last_SQL_Error:Kan inte köra den aktuella händelsegruppen i parallellt läge. Påträffad händelse Gtid, reläloggnamn /mysql_data/relaylogs/relay-log.000005, position 27023962 som förhindrar exekvering av denna händelsegrupp i parallellt läge. Orsak:Huvudhändelsen är logiskt felaktigt tidsstämplad.
Analys av reläloggen och positionen ovan avslöjade att "sekvensnumret" för transaktionen vid denna tidpunkt återställdes till 1. Jag spårade orsaken till att en binlog-rotation inträffade på original mästare. Vanligtvis, för direkta slavar, finns det en rotationshändelse på grund av vilken reläloggar också skulle rotera baserat på master binär loggrotation. Min bedömning är att sådana tillstånd kan upptäckas och sekvensnummeråterställning kan hanteras av parallella trådar. Men när sekvensnumret ändras utan att reläloggarna roterar, ser vi att de parallella trådarna misslyckas.
Denna observation rapporteras som problemet:slavparallell trådfel vid synkronisering från binlogserver #26
4. mysqlbinlog-verktyget fungerar inte på de binära loggarna som produceras av Ripple-servern
Att försöka köra mysqlbinlog-verktyget på den binära loggen resulterade i felet:
FEL:Fel i Log_event::read_log_event():'Ogiltig händelse i binär logg hittades', data_len:43, händelsetyp:-106
Det här problemet tas upp här:Kan inte öppna de binära loggfilerna med hjälp av mysqlbinlog-verktyget. #25
Det erkänns av författaren som ett känt problem. Jag känner att det skulle vara användbart att stödja detta verktyg för felsökningsändamål.
Det är rapporten för tillfället från mina snabba tester. Jag planerar att uppdatera det här blogginlägget när och när jag stöter på fler fynd om Ripple. Sammantaget tyckte jag att det var enkelt och okomplicerat att använda och har potential att bli en standard för binlog-servrar i MySQL-miljöer.
|