sql >> Databasteknik >  >> RDS >> MariaDB

Hur man ersätter en Intermediate MySQL eller MariaDB Master med en Binlog Server med MaxScale

Binära loggar (binloggar) innehåller register över alla ändringar i databaserna. De är nödvändiga för replikering och kan även användas för att återställa data efter en säkerhetskopia. En binlog-server är i grunden ett binärt loggförråd. Du kan tänka på det som en server med ett dedikerat syfte att hämta binära loggar från en master, medan slavservrar kan ansluta till den som de skulle ansluta till en masterserver.

Några fördelar med att ha en binlog-server framför en mellanliggande master för att fördela replikeringsarbetsbelastningen är:

  • Du kan byta till en ny masterserver utan att slavarna märker att den faktiska masterservern har ändrats. Detta möjliggör en mer tillgänglig replikeringsinställning där replikering har hög prioritet.
  • Minska belastningen på mastern genom att endast betjäna Maxscales binlog-server istället för alla slavar.
  • Data i den binära loggen för den mellanliggande mastern är inte en direkt kopia av data som togs emot från den binära loggen för den verkliga mastern. Som sådan, om group commit används, kan detta orsaka en minskning av parallelliteten mellan commits och en efterföljande minskning av prestanda för slavservrarna.
  • Mellanslaven måste köra om varje SQL-sats som potentiellt lägger till latens och släpar in i replikeringskedjan.

I det här blogginlägget kommer vi att undersöka hur man ersätter en mellanliggande master (ett slavvärdrelä till andra slavar i en replikeringskedja) med en binlog-server som körs på MaxScale för bättre skalbarhet och prestanda .

Arkitektur

Vi har i princip en 4-nods MariaDB v10.4 replikeringsinställning med en MaxScale v2.3 som sitter ovanpå replikeringen för att distribuera inkommande frågor. Endast en slav är ansluten till en master (mellanmästare) och de andra slavarna replikerar från den mellanliggande mastern för att betjäna läsarbetsbelastningar, som illustreras i följande diagram.

Vi ska förvandla ovanstående topologi till detta:

I grund och botten kommer vi att ta bort den mellanliggande huvudrollen och ersätta den med en binlog-server som körs på MaxScale. Den mellanliggande mastern kommer att konverteras till en standardslav, precis som andra slavvärdar. Binlog-tjänsten kommer att lyssna på port 5306 på MaxScale-värden. Detta är porten som alla slavar kommer att ansluta till för replikering senare.

Konfigurera MaxScale som en Binlog-server

I det här exemplet har vi redan en MaxScale ovanpå vårt replikeringskluster som fungerar som en lastbalanserare för våra applikationer. Om du inte har en MaxScale kan du använda ClusterControl för att distribuera helt enkelt gå till Cluster Actions -> Add Load Balancer -> MaxScale och fyll i nödvändig information enligt följande:

Innan vi börjar, låt oss exportera den aktuella MaxScale-konfigurationen till en textfil för backup. MaxScale har en flagga som heter --export-config för detta ändamål men den måste köras som maxscale-användare. Kommandot att exportera är alltså:

$ su -s /bin/bash -c '/bin/maxscale --export-config=/tmp/maxscale.cnf' maxscale

På MariaDB-mastern, skapa en replikeringsslavanvändare som heter 'maxscale_slave' som ska användas av MaxScale och tilldela den med följande privilegier:

$ 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'@'%';

För ClusterControl-användare, gå till Hantera -> Schema och användare för att skapa nödvändiga privilegier.

Innan vi går vidare med konfigurationen är det viktigt att granska det aktuella tillståndet och topologin för våra backend-servrar:

$ 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 │
└────────┴──────────────┴──────┴─────────────┴──────────────────────────────┴───────────┘

Som vi kan se är den nuvarande mastern DB_757 (192.168.0.90). Notera denna information eftersom vi ska ställa in binlog-servern för att replikera från denna master.

Öppna MaxScale-konfigurationsfilen på /etc/maxscale.cnf och lägg till följande rader:

[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.0

En liten förklaring - Vi skapar två komponenter - service och lyssnare. Service är där vi definierar binlog-serverns egenskaper och hur den ska köras. Detaljer om varje alternativ finns här. I det här exemplet körs våra replikeringsservrar med semisync replikering, så vi måste använda semisync=true så att den kommer att ansluta till mastern via semisync replikeringsmetod. Lyssnaren är där vi kartlägger lyssningsporten med binlogrouter-tjänsten inuti MaxScale.

Starta om MaxScale för att ladda ändringarna:

$ systemctl restart maxscale

Verifiera att binlog-tjänsten startas via maxctrl (titta på kolumnen Status):

$ maxctrl show service replication-service

Verifiera att MaxScale nu lyssnar på en ny port för binlog-tjänsten:

$ 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/maxscale

Vi är nu redo att upprätta en replikeringslänk mellan MaxScale och mastern.

Aktivera Binlog-servern

Logga in på MariaDB-masterservern och hämta den aktuella binlogfilen och positionen:

MariaDB> SHOW MASTER STATUS;
+---------------+----------+--------------+------------------+
| File          | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+---------------+----------+--------------+------------------+
| binlog.000005 |     4204 |              |                  |
+---------------+----------+--------------+------------------+

Använd funktionen BINLOG_GTID_POS för att få GTID-värdet:

MariaDB> SELECT BINLOG_GTID_POS("binlog.000005", 4204);
+----------------------------------------+
| BINLOG_GTID_POS("binlog.000005", 4204) |
+----------------------------------------+
| 0-38001-31                             |
+----------------------------------------+

Tillbaka till MaxScale-servern, installera MariaDB-klientpaketet:

$ yum install -y mysql-client

Anslut till binlog-serveravlyssnaren på port 5306 som maxscale_slave-användare och upprätta en replikeringslänk till den angivna mastern. Använd GTID-värdet som hämtats från mastern:

(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-31

Obs! Ovanstående utdata har trunkerats för att endast visa viktiga rader.

Pekar slavar till Binlog-servern

Nu på mariadb2 och mariadb3 (slutslavarna), ändra mastern som pekar mot MaxScale binlog-servern. Eftersom vi kör med semi-synk replikering aktiverad, måste vi stänga av dem först:

(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 it

Obs! Ovanstående utdata har trunkerats för att endast visa viktiga rader.

Inuti my.cnf måste vi kommentera följande rader för att inaktivera semi-sync i framtiden:

#loose_rpl_semi_sync_slave_enabled=ON
#loose_rpl_semi_sync_master_enabled=ON

Vid denna tidpunkt replikerar den mellanliggande mastern (mariadb1) fortfarande från mastern (mariadb0) medan andra slavar har replikerat från binlog-servern. Vår nuvarande topologi kan illustreras som diagrammet nedan:

Den sista delen är att ändra masterpekningen för den mellanliggande mastern (mariadb1) ) efter alla slavar som brukade fästa vid den är inte längre där. Stegen är i princip desamma med de andra slavarna:

(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-32

Obs:Ovanstående utdata har trunkerats för att endast visa viktiga rader.

Glöm inte att inaktivera semi-sync replikering i my.cnf också:

#loose_rpl_semi_sync_slave_enabled=ON
#loose_rpl_semi_sync_master_enabled=ON

Vi kan verifiera att binlog-routertjänsten har fler anslutningar nu 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 │
└─────────────────────┴────────────────┴─────────────┴───────────────────┴───────────────────────────────────┘

Även vanliga replikeringsadministrationskommandon kan användas inuti MaxScale binlog-servern, till exempel kan vi verifiera de anslutna slavvärdarna genom att använda detta kommando:

(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      |            |
+-----------+--------------+------+-----------+------------+

Vid det här laget ser vår topologi ut som vad vi förväntade oss:

Vår migrering från mellanliggande huvudinstallation till binlog-serverinstallation är nu klar.


  1. PostgreSQL materialiserad vy

  2. "VARNING:Felmatchning hittades mellan sl_table och pg_class." i Slony-I

  3. Uppnå hierarki, förälder/barnrelation på ett effektivt och enkelt sätt

  4. Förstå resultatet av Execute Explain Plan i Oracle SQL Developer