Binaire logs (binlogs) bevatten records van alle wijzigingen in de databases. Ze zijn nodig voor replicatie en kunnen ook worden gebruikt om gegevens te herstellen na een back-up. Een binlog-server is in feite een binaire log-repository. Je kunt het zien als een server met een specifiek doel om binaire logboeken van een master op te halen, terwijl slave-servers er verbinding mee kunnen maken alsof ze verbinding zouden maken met een masterserver.
Enkele voordelen van het hebben van een binlog-server boven een tussenliggende master om de replicatiewerklast te verdelen zijn:
- Je kunt overschakelen naar een nieuwe masterserver zonder dat de slaves merken dat de eigenlijke masterserver is gewijzigd. Dit zorgt voor een hogere beschikbaarheid van replicatie-instellingen waarbij replicatie een hoge prioriteit heeft.
- Verminder de belasting van de master door alleen de binlog-server van Maxscale te bedienen in plaats van alle slaves.
- De gegevens in het binaire logboek van de tussenliggende master zijn geen directe kopie van de gegevens die zijn ontvangen uit het binaire logboek van de echte master. Als een groeps-commit wordt gebruikt, kan dit een vermindering van het parallellisme van de commits en een daaropvolgende vermindering van de prestaties van de slave-servers veroorzaken.
- Intermediate slave moet elke SQL-instructie opnieuw uitvoeren die mogelijk latentie en vertragingen in de replicatieketen veroorzaakt.
In deze blogpost gaan we onderzoeken hoe we een tussenliggende master (een slave-hostrelais naar andere slaves in een replicatieketen) kunnen vervangen door een binlog-server die draait op MaxScale voor betere schaalbaarheid en prestaties .
Architectuur
We hebben in feite een MariaDB v10.4-replicatie-setup met 4 nodes en één MaxScale v2.3 bovenop de replicatie om inkomende query's te distribueren. Slechts één slave is verbonden met een master (tussenmaster) en de andere slaves repliceren van de tussenliggende master om leeswerkbelastingen te dienen, zoals geïllustreerd in het volgende diagram.
We gaan de bovenstaande topologie in dit omzetten:
In principe gaan we de rol van de tussenliggende master verwijderen en vervangen door een binlog-server die draait op MaxScale. De tussenmaster wordt, net als andere slave-hosts, omgezet naar een standaardslave. De binlog-service luistert op poort 5306 op de MaxScale-host. Dit is de poort waarmee alle slaves later verbinding zullen maken voor replicatie.
MaxScale configureren als een Binlog-server
In dit voorbeeld hebben we al een MaxScale bovenop ons replicatiecluster die fungeert als load balancer voor onze applicaties. Als u geen MaxScale hebt, kunt u ClusterControl gebruiken om te implementeren, ga gewoon naar Clusteracties -> Load Balancer toevoegen -> MaxScale en vul de benodigde informatie als volgt in:
Laten we, voordat we beginnen, de huidige MaxScale-configuratie naar een tekstbestand exporteren voor back-up. MaxScale heeft voor dit doel een vlag genaamd --export-config, maar deze moet worden uitgevoerd als maxscale-gebruiker. Het commando om te exporteren is dus:
$ su -s /bin/bash -c '/bin/maxscale --export-config=/tmp/maxscale.cnf' maxscaleMaak op de MariaDB-master een replicatieslave-gebruiker met de naam 'maxscale_slave' die door de MaxScale moet worden gebruikt en wijs deze toe met de volgende rechten:
$ 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'@'%';Voor ClusterControl-gebruikers, ga naar Beheren -> Schema's en gebruikers om de benodigde rechten te creëren.
Voordat we verder gaan met de configuratie, is het belangrijk om de huidige staat en topologie van onze backend-servers te bekijken:
$ 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 │
└────────┴──────────────┴──────┴─────────────┴──────────────────────────────┴───────────┘Zoals we kunnen zien, is de huidige master DB_757 (192.168.0.90). Noteer deze informatie terwijl we de binlog-server gaan instellen om vanaf deze master te repliceren.
Open het MaxScale-configuratiebestand op /etc/maxscale.cnf en voeg de volgende regels toe:
[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.0Een beetje uitleg - We maken twee componenten:service en luisteraar. Service is waar we het kenmerk van de binlog-server definiëren en hoe het moet werken. Details over elke optie zijn hier te vinden. In dit voorbeeld werken onze replicatieservers met semi-sync replicatie, dus we moeten semisync=true gebruiken, zodat het verbinding maakt met de master via de semi-sync replicatiemethode. De luisteraar is waar we de luisterpoort in kaart brengen met de binlogrouter-service in MaxScale.
Start MaxScale opnieuw om de wijzigingen te laden:
$ systemctl restart maxscaleControleer of de binlog-service is gestart via maxctrl (kijk naar de kolom Status):
$ maxctrl show service replication-serviceControleer of MaxScale nu naar een nieuwe poort voor de binlog-service luistert:
$ 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/maxscaleWe zijn nu klaar om een replicatiekoppeling tot stand te brengen tussen MaxScale en de master.
De Binlog-server activeren
Log in op de MariaDB-masterserver en haal het huidige binlog-bestand en de positie op:
MariaDB> SHOW MASTER STATUS;
+---------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+---------------+----------+--------------+------------------+
| binlog.000005 | 4204 | | |
+---------------+----------+--------------+------------------+Gebruik de BINLOG_GTID_POS-functie om de GTID-waarde te krijgen:
MariaDB> SELECT BINLOG_GTID_POS("binlog.000005", 4204);
+----------------------------------------+
| BINLOG_GTID_POS("binlog.000005", 4204) |
+----------------------------------------+
| 0-38001-31 |
+----------------------------------------+Terug naar de MaxScale-server, installeer MariaDB-clientpakket:
$ yum install -y mysql-client
Maak verbinding met de binlog-serverlistener op poort 5306 als maxscale_slave-gebruiker en breng een replicatielink tot stand met de aangewezen master. Gebruik de GTID-waarde die is opgehaald uit de master:
(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-31Opmerking:de bovenstaande uitvoer is afgekapt om alleen belangrijke regels weer te geven.
Slaven naar de Binlog-server wijzen
Nu op mariadb2 en mariadb3 (de eindslaves), verander de master die verwijst naar de MaxScale binlog-server. Aangezien we werken met semi-sync replicatie ingeschakeld, moeten we ze eerst uitschakelen:
(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 itOpmerking:de bovenstaande uitvoer is afgekapt om alleen belangrijke regels weer te geven.
Binnen my.cnf moeten we de volgende regels becommentariëren om semi-synchronisatie in de toekomst uit te schakelen:
#loose_rpl_semi_sync_slave_enabled=ON
#loose_rpl_semi_sync_master_enabled=ONOp dit moment repliceert de tussenliggende master (mariadb1) nog steeds vanaf de master (mariadb0), terwijl andere slaves repliceren vanaf de binlog-server. Onze huidige topologie kan worden geïllustreerd zoals het onderstaande diagram:
Het laatste deel is het wijzigen van de master-aanwijzing van de tussenliggende master (mariadb1 ) tenslotte zijn de slaven die er vroeger aan vastzaten er niet meer. De stappen zijn in principe hetzelfde bij de andere slaves:
(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-32Opmerking:de bovenstaande uitvoer is afgekapt om alleen belangrijke regels weer te geven.
Vergeet niet om semi-sync replicatie ook in my.cnf uit te schakelen:
#loose_rpl_semi_sync_slave_enabled=ON
#loose_rpl_semi_sync_master_enabled=ONWe kunnen controleren of de binlog-routerservice nu meer verbindingen heeft via 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 │
└─────────────────────┴────────────────┴─────────────┴───────────────────┴───────────────────────────────────┘Ook kunnen algemene opdrachten voor replicatiebeheer worden gebruikt binnen de MaxScale binlog-server, we kunnen bijvoorbeeld de aangesloten slave-hosts verifiëren door deze opdracht te gebruiken:
(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 | |
+-----------+--------------+------+-----------+------------+Op dit moment ziet onze topologie eruit zoals we hadden verwacht:
Onze migratie van tussenliggende hoofdconfiguratie naar binlog-serverconfiguratie is nu voltooid.