MySQL begrænser ikke antallet af slaver, som du kan forbinde til masterserveren i en replikeringstopologi. Men efterhånden som antallet af slaver stiger, vil de have en vejafgift på masterressourcerne, fordi de binære logfiler skal serveres til forskellige slaver, der arbejder ved forskellige hastigheder. Hvis dataafgangen på masteren er høj, kan serveringen af binære logfiler alene mætte masterens netværksgrænseflade.
En klassisk løsning på dette problem er at installere en binlog-server – en mellemliggende proxyserver, der sidder mellem masteren og dens slaver. Binlog-serveren er sat op som en slave til masteren og fungerer på sin side som en master for det originale sæt af slaver. Den modtager binære loghændelser fra masteren, anvender ikke disse hændelser, men serverer dem til alle de andre slaver. På denne måde reduceres belastningen på masteren enormt, og samtidig serverer binlog-serveren binlogs mere effektivt til slaver, da den ikke skal udføre nogen anden databaseserverbehandling.
Ripple er en open source binlog-server udviklet af Pavel Ivanov. Et blogindlæg fra Percona, med titlen MySQL Ripple:The First Impression of a MySQL Binlog Server, giver en meget god introduktion til implementering og brug af Ripple. Jeg havde mulighed for at udforske Ripple mere detaljeret og ville gerne dele mine observationer gennem dette indlæg.
1. Understøttelse af GTID-baseret replikering
Ripple understøtter kun GTID-tilstand og ikke fil- og positionsbaseret replikering. Hvis din master kører i ikke-GTID-tilstand, får du denne fejl fra Ripple:
Kunne ikke læse pakke:Fik fejl ved læsning af pakke fra server:Replikeringsafsendertråden kan ikke starte i AUTO_POSITION-tilstand:denne server har GTID_MODE =OFF i stedet for ON.
Du kan angive Server_id og UUID for ripple-serveren ved at bruge cmd-linjeindstillingerne: -ripple_server_id og -ripple_server_uuid
Begge er valgfrie parametre, og hvis de ikke er angivet, vil Ripple bruge standardserver_id=112211, og uuid vil blive genereret automatisk.
2. Opretter forbindelse til masteren ved hjælp af replikeringsbruger og adgangskode
Mens du opretter forbindelse til masteren, kan du angive replikeringsbrugeren og adgangskoden ved hjælp af kommandolinjeindstillingerne:
-ripple_master_user og -ripple_master_password
3. Forbindelsesslutpunkt for Ripple-serveren
Du kan bruge kommandolinjeindstillingerne -ripple_server_ports og -ripple_server_address til at angive forbindelsesslutpunkterne for Ripple-serveren. Sørg for at angive det netværkstilgængelige værtsnavn eller IP-adresse på din Ripple-server som -rippple_server_address. Ellers vil Ripple som standard binde til localhost, og du vil derfor ikke være i stand til at oprette forbindelse til den eksternt.
4. Opsætning af slaver til Ripple-serveren
Du kan bruge kommandoen CHANGE MASTER TO til at forbinde dine slaver for at replikere fra Ripple-serveren.
For at sikre, at Ripple kan godkende den adgangskode, du bruger til at oprette forbindelse til den, skal du starte Ripple ved at angive indstillingen -ripple_server_password_hash
Hvis du f.eks. starter ripple-serveren med kommandoen:
rippled -ripple_datadir=./binlog_server -ripple_master_address=
du kan bruge følgende CHANGE MASTER TO-kommando til at oprette forbindelse fra slaven:
SKIFT MASTER TIL master_host='172.31.23.201', master_port=15000, master_password=’XpKWeZRNH5#satCI’, master_user=’rep’
Bemærk, at den kodeords-hash, der er angivet for Ripple-serveren, svarer til den tekstadgangskode, der bruges i CHANGE MASTER TO-kommandoen. I øjeblikket godkender Ripple ikke baseret på brugernavnene og accepterer ethvert ikke-tomt brugernavn, så længe adgangskoden matcher.
Udforskning af MySQL Binlog Server - RippleClick To Tweet5. Ripple server management
Det er muligt at overvåge og administrere Ripple-serveren ved hjælp af MySQL-protokollen fra enhver standard MySQL-klient. Der er et begrænset sæt kommandoer, der understøttes, som du kan se direkte i kildekoden på mysql-ripple GitHub-siden.
Nogle af de nyttige kommandoer er:
SELECT @@global.gtid_executed;– For at se GTID-sættet for Ripple-serveren baseret på dens downloadede binære logfiler.STOP SLAVE;– For at frakoble Ripple-serveren fra masteren.START SLAVE;– For at forbinde Ripple-serveren til masteren.
Kendte problemer og forslag til forbedring
1. Jeg så ikke en mulighed for at konfigurere en SSL-replikeringskanal fra en Ripple-server til masteren
Som et resultat af dette vil Ripple-serveren ikke være i stand til at oprette forbindelse til en master, der kræver krypterede forbindelser. Forsøg på at oprette forbindelse vil resultere i fejlen:
0322 09:01:36.555124 14942 mysql_master_session.cc:164] Kunne ikke oprette forbindelse til vært:
2. Jeg var ikke i stand til at få Ripple-serveren til at arbejde med semi-synkroniseringsindstillingen
Jeg startede Ripple-serveren ved at bruge indstillingen -ripple_semi_sync_slave_enabled=true
Ved tilslutning til den var masteren i stand til at registrere Ripple-serveren som en semi-synkroniseringsaktiveret slave.
mysql> vis status som 'rpl%';
---------------------------------------- ----------------------
| Variable_name | Værdi |
--------------------------------------------- ----------
| Rpl_semi_sync_master_clients | 1 |
| Rpl_semi_sync_master_status | TIL |
| Rpl_semi_sync_slave_status | FRA |
------------------------------------------------ ----------
Forsøg på at udføre en transaktion i semi-synkroniseringstilstand ventede dog på rpl_semi_sync_master_timeout, som var 180.000
mysql> opret database d12;
Forespørgsel OK, 1 række påvirket (3 min. 0,01 sek.)
Jeg kunne se, at semi-synkronisering blev slået fra på masteren:
mysql> vis status som 'rpl%';
+-------------------------------- ------------+-------+
| Variable_name | Værdi |
+------------------------------------------------ -+-------+
| Rpl_semi_sync_master_clients | 1 |
| Rpl_semi_sync_master_status | FRA |
| Rpl_semi_sync_slave_status | FRA |
+------------------------------------------------ -+-------+
Tilsvarende uddrag fra mysql-fejllogfilerne:
2020-03-21T10:05:56.000612Z 52 [Bemærk] Start binlog_dump til master_thread_id(52) slave_server(112211), pos(, 4)
2020-03-21T10:05:527Z 526.000 Bemærk] Start semi-sync binlog_dump til slave (server_id:112211), pos(, 4)
20020-03-21T10:08:55.873990Z 2 [Advarsel] Timeout venter på svar fra binlog (fil:mysql-bin) .000010, pos:350), semi-synkronisering op til fil , position 4.
2020-03-21T10:08:55.874044Z 2 [Bemærk] Semi-sync replikering slået FRA.
Der er et problem rapporteret i lignende retning her på MySQL Ripple Github-siden.
3. Problem ved brug af parallel replikering til Ripple-serverens slaver
Jeg så, at SQL-tråden på slaven ofte stoppede med fejlen:
Last_SQL_Error:Kan ikke udføre den aktuelle hændelsesgruppe i paralleltilstand. Opstod hændelse Gtid, relay-log navn /mysql_data/relaylogs/relay-log.000005, position 27023962, som forhindrer udførelse af denne hændelsesgruppe i parallel tilstand. Årsag:Masterhændelsen er logisk tidsstemplet forkert.
Analyse af relæloggen og positionen ovenfor viste, at 'sekvensnummeret' for transaktionen på dette tidspunkt blev nulstillet til 1. Jeg sporede årsagen til, at en binlog-rotation fandt sted på original mester. For direkte slaver er der typisk en rotationshændelse, på grund af hvilken relælogfiler også vil rotere baseret på master binær logrotation. Min vurdering er, at sådanne forhold kan detekteres og nulstilling af sekvensnummer kan håndteres af parallelle tråde. Men når sekvensnummeret ændres uden rotation af relælogfilerne, ser vi de parallelle tråde svigte.
Denne observation er rapporteret som problemet:slave parallel trådfejl under synkronisering fra binlog-server #26
4. mysqlbinlog-værktøjet virker ikke på de binære logfiler produceret af Ripple-serveren
Forsøg på at køre mysqlbinlog-værktøjet på den binære log resulterede i fejlen:
FEJL:Fejl i Log_event::read_log_event():'Fundet ugyldig hændelse i binær log', data_len:43, hændelsestype:-106
Dette problem er rejst her:Kan ikke åbne de binære logfiler ved hjælp af mysqlbinlog-værktøjet. #25
Det er anerkendt af forfatteren som et kendt problem. Jeg føler, at det ville være nyttigt at understøtte dette værktøj til fejlfindingsformål.
Det er rapporten for nu fra min hurtige test. Jeg planlægger at opdatere dette blogindlæg, efterhånden som jeg støder på flere resultater om Ripple. Samlet set fandt jeg, at den var enkel og ligetil at bruge og har potentialet til at blive en standard for binlog-servere i MySQL-miljøer.
|