Binære logfiler (binlogs) indeholder registreringer af alle ændringer i databaserne. De er nødvendige for replikering og kan også bruges til at gendanne data efter en sikkerhedskopi. En binlog-server er grundlæggende et binært log-lager. Du kan tænke på det som en server med et dedikeret formål at hente binære logfiler fra en master, mens slaveservere kan oprette forbindelse til den, ligesom de ville oprette forbindelse til en masterserver.
Nogle fordele ved at have en binlog-server frem for mellemliggende master til at fordele replikeringsarbejdsbyrden er:
- Du kan skifte til en ny masterserver, uden at slaverne bemærker, at den faktiske masterserver har ændret sig. Dette giver mulighed for en mere tilgængelig replikeringsopsætning, hvor replikering har høj prioritet.
- Reducer belastningen på masteren ved kun at betjene Maxscales binlog-server i stedet for alle slaverne.
- Dataene i den binære log for den mellemliggende master er ikke en direkte kopi af de data, der blev modtaget fra den binære log for den rigtige master. Som sådan, hvis gruppe-commit bruges, kan dette forårsage en reduktion i paralleliteten af commits og en efterfølgende reduktion i ydeevnen af slave-serverne.
- Mellemslave skal genudføre hver SQL-sætning, som potentielt tilføjer latens og halter ind i replikeringskæden.
I dette blogindlæg skal vi se på, hvordan man erstatter en mellemliggende master (et slaveværtsrelæ til andre slaver i en replikeringskæde) med en binlog-server, der kører på MaxScale for bedre skalerbarhed og ydeevne .
Arkitektur
Vi har grundlæggende en 4-node MariaDB v10.4 replikeringsopsætning med en MaxScale v2.3, der sidder oven på replikationen for at distribuere indgående forespørgsler. Kun én slave er forbundet til en master (mellem master), og de andre slaver replikerer fra den mellemliggende master for at betjene læse arbejdsbelastninger, som illustreret i følgende diagram.
Vi vil omdanne ovenstående topologi til dette:
Grundlæggende vil vi fjerne den mellemliggende masterrolle og erstatte den med en binlog-server, der kører på MaxScale. Den mellemliggende master vil blive konverteret til en standard slave, ligesom andre slave værter. Binlog-tjenesten vil lytte på port 5306 på MaxScale-værten. Dette er den port, som alle slaver vil oprette forbindelse til til replikering senere.
Konfiguration af MaxScale som en Binlog-server
I dette eksempel har vi allerede en MaxScale på toppen af vores replikeringsklynge, der fungerer som en belastningsbalancer for vores applikationer. Hvis du ikke har en MaxScale, kan du bruge ClusterControl til at implementere, bare gå til Cluster Actions -> Add Load Balancer -> MaxScale og udfyld de nødvendige oplysninger som følgende:
Før vi går i gang, lad os eksportere den aktuelle MaxScale-konfiguration til en tekstfil til backup. MaxScale har et flag kaldet --export-config til dette formål, men det skal udføres som maxscale-bruger. Kommandoen til eksport er således:
$ su -s /bin/bash -c '/bin/maxscale --export-config=/tmp/maxscale.cnf' maxscale På MariaDB-masteren skal du oprette en replikeringsslavebruger kaldet 'maxscale_slave', der skal bruges af MaxScale, og tildele den følgende privilegier:
$ mysql -uroot -p -h192.168.0.91 -P3306MariaDB> OPRET BRUGER 'maxscale_slave'@'%' IDENTIFICERET AF 'BtF2d2Kc8H';MariaDB> TILDEL SELECT PÅ mysql.user'@'maxscale_slave' %';MariaDB> TILDEL VALG PÅ mysql.db TIL 'maxscale_slave'@'%';MariaDB> TILDEL VALG PÅ mysql.tables_priv TIL 'maxscale_slave'@'%';MariaDB> TILDEL VALG PÅ mysql.roles_mapping TIL 'maxscale_slave'@ '%';MariaDB> TILDEL VIS DATABASER PÅ *.* TO 'maxscale_slave'@'%';MariaDB> TILDEL REPLIKATIONSLAVE PÅ *.* TIL 'maxscale_slave'@'%'; For ClusterControl-brugere, gå til Administrer -> Skemaer og brugere for at oprette de nødvendige privilegier.
Før vi går videre med konfigurationen, er det vigtigt at gennemgå den aktuelle tilstand og topologi for vores backend-servere:
$ maxctrl liste servere┌────────┬───────────────────────────── ─ Hver Server │ Adresse │ Port │ Forbindelser │ Tilstand │ GTID ─├────────┼───────└└───────────────── ─ Hver ┤│ DB_757 │ 192.168.0.90 │ 3306 │ 0 │ Master, kørende │ 0-38001-8 │├────ept. Out ─ Hver ─ ovearat ─ Hver ─ ovearat ─ Hver ─ ovearat -38001-8 ─└────────┴───────────────└────────────── ┴─────────────────────────────── ───────────┘ Som vi kan se, er den nuværende master DB_757 (192.168.0.90). Bemærk disse oplysninger, da vi skal konfigurere binlog-serveren til at replikere fra denne master.
Åbn MaxScale-konfigurationsfilen på /etc/maxscale.cnf og tilføj følgende linjer:
[replikation-service]type=servicerouter=binlogrouteruser=maxscale_slavepassword=BtF2d2Kc8Hversion_string=10.4.12-MariaDB-logserver_id=9999master_id=9999mariadb10_master_gtid=truefilestem=/semlogbincmaxsyniscale=/semlogbinc/ er aktiveret på master[binlog-server-listener]type=listenerservice=replication-serviceprotocol=MariaDBClientport=5306address=0.0.0.0 Lidt forklaring - Vi skaber to komponenter - service og lytter. Service er der, hvor vi definerer binlog-serverkarakteristikken, og hvordan den skal køre. Detaljer om hver mulighed kan findes her. I dette eksempel kører vores replikeringsservere med semi-sync-replikering, så vi skal bruge semisync=true, så den vil oprette forbindelse til masteren via semi-sync-replikeringsmetoden. Lytteren er der, hvor vi kortlægger lytteporten med binlogrouter-tjenesten inde i MaxScale.
Genstart MaxScale for at indlæse ændringerne:
$ systemctl genstart maxscale Bekræft, at binlog-tjenesten er startet via maxctrl (se kolonnen Status):
$ maxctrl show service replikeringsservice Bekræft, at MaxScale nu lytter til en ny port til binlog-tjenesten:
$ netstat -tulpn | grep maxscaletcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN 4850/maxscaletcp 0 0 0.0.0.0:3307 0.0.0.0:* LISTEN 4850/maxscaletcp 0 0 0:0.0IS0 0:0.0IS0 0:0.0IS 0 0:0.0IS 0 0 127.0.0.1:8989 0.0.0.0:* LISTEN 4850/maxscale Vi er nu klar til at etablere et replikeringslink mellem MaxScale og masteren.
Aktivering af Binlog-serveren
Log ind på MariaDB-masterserveren og hent den aktuelle binlog-fil og position:
MariaDB> VIS MASTER STATUS;+---------+------------- ----+------------------+| Fil | Stilling | Binlog_Do_DB | Binlog_Ignore_DB |+---------------------------+----- --------------+| binlog.000005 | 4204 | | |+---------------------------------------- ------------+ Brug funktionen BINLOG_GTID_POS til at få GTID-værdien:
MariaDB> VÆLG BINLOG_GTID_POS("binlog.000005", 4204);+----------------------------- -----------+| BINLOG_GTID_POS("binlog.000005", 4204) |+------------------------------------------------ --+| 0-38001-31 |+------------------------------------------------+ Tilbage til MaxScale-serveren, installer MariaDB-klientpakken:
$ yum install -y mysql-client
Opret forbindelse til binlog-serverlytteren på port 5306 som maxscale_slave-bruger og opret et replikeringslink til den udpegede master. Brug GTID-værdien hentet fra masteren:
(maxscale)$ mysql -u maxscale_slave -p'BtF2d2Kc8H' -h127.0.0.1 -P5306MariaDB> SET @@global.gtid_slave_pos ='0-38001-31';MariaDB>_HANDLE MÆSTER =MÆSTER '192.168.0.90', MASTER_USER ='maxscale_slave', MASTER_PASSWORD ='BtF2d2Kc8H', MASTER_PORT=3306, MASTER_USE_GTID =slave_pos;MariaDB> START SLAVE;MariaDB [(ingen)****]> VIS SLAVE ******************** 1. række ****************************** 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/slave_Master_01. /kode>
Bemærk:Ovenstående output er blevet afkortet til kun at vise vigtige linjer.
Peger slaver til Binlog-serveren
Nu på mariadb2 og mariadb3 (slutslaverne), skal du ændre masteren, der peger på MaxScale binlog-serveren. Da vi kører med semi-synkroniseringsreplikering aktiveret, skal vi først slå dem fra:
(mariadb2 &mariadb3)$ mysql -uroot -pMariaDB> STOP SLAVE;MariaDB> SET global rpl_semi_sync_master_enabled =0; -- hvis semisync er aktiveretMariaDB> SET global rpl_semi_sync_slave_enabled =0; -- hvis semisync er aktiveretMariaDB> SKIFT MASTER TIL MASTER_HOST ='192.168.0.95', MASTER_USER ='maxscale_slave', MASTER_PASSWORD ='BtF2d2Kc8H', MASTER_PORT=5306, MASTER_USE_GTID =slave>_pos; **************************** 1. række ******************** ******* Slave_IO_State:Venter på, at master sender hændelse Master_Host:192.168.0.95 Master_User:maxscale_slave Master_Port:5306 Slave_IO_Running:Ja Slave_SQL_Running:Yes Master_Server_Id:9999 Using_PoGtid3 Slave_00s:9999 Slave_01 alle relæ log; venter på, at slave I/O-tråden opdaterer den
Bemærk:Ovenstående output er blevet afkortet til kun at vise vigtige linjer.
Inde i my.cnf er vi nødt til at kommentere følgende linjer for at deaktivere semi-synkronisering i fremtiden:
#loose_rpl_semi_sync_slave_enabled=ON#loose_rpl_semi_sync_master_enabled=ON
På dette tidspunkt replikerer den mellemliggende master (mariadb1) stadig fra masteren (mariadb0), mens andre slaver har replikeret fra binlog-serveren. Vores nuværende topologi kan illustreres som diagrammet nedenfor:
Den sidste del er at ændre master-pegningen af den mellemliggende master (mariadb1) ) efter alle slaver, der plejede at knytte sig til det, er der ikke længere. Trinene er grundlæggende de samme med de andre slaver:
(mariadb1)$ mysql -uroot -pMariaDB> STOP SLAVE;MariaDB> SET global rpl_semi_sync_master_enabled =0; -- hvis semisync er aktiveretMariaDB> SET global rpl_semi_sync_slave_enabled =0; -- hvis semisync er aktiveretMariaDB> SKIFT MASTER TIL MASTER_HOST ='192.168.0.95', MASTER_USER ='maxscale_slave', MASTER_PASSWORD ='BtF2d2Kc8H', MASTER_PORT=5306, MASTER_USE_GTID =slave>_pos; **************************** 1. række ******************** ******* Slave_IO_State:Venter på, at master sender hændelse 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_PoGtid_0s:9999 Slave_Po_0s:
Bemærk:Ovenstående output er blevet afkortet for kun at vise vigtige linjer.
Glem ikke også at deaktivere semi-sync replikering i my.cnf:
#loose_rpl_semi_sync_slave_enabled=ON#loose_rpl_semi_sync_master_enabled=ON
Vi kan bekræfte, at binlog-routertjenesten har flere forbindelser nu via maxctrl CLI:
$ maxctrl liste tjenester┌─────────────────────┬────┬───────────── ─ Hver │ ─ Hver ─ Hver │ 1 │ db_757, db_758, db_759, db_760 │├───eptarat ┼──── den eptemeomtseskabelse ─ ovearat ─ Hver ─ Hver │ Replikationstjeneste │ binlogrouter │ 4 │ 51 │ binlog_router_master_host, db_757 │└───eptept. ─ Hver ─ ───────────────────────┘
Også almindelige replikeringsadministrationskommandoer kan bruges inde i MaxScale binlog-serveren, for eksempel kan vi verificere de tilsluttede slaveværter ved at bruge denne kommando:
(maxscale)$ mysql -u maxscale_slave -p'BtF2d2Kc8H' -h127.0.0.1 -P5306MariaDB> VIS SLAVEVÆRTER;+------------+----- ----+------+------------+------------+| Server_id | Vært | Havn | 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 | |+-----------+----------------+-------- ----------+
På dette tidspunkt ser vores topologi ud som det, vi forventede:
Vores migrering fra mellemliggende masteropsætning til binlog-serveropsætning er nu fuldført.