I log binari (binlog) contengono i record di tutte le modifiche ai database. Sono necessari per la replica e possono essere utilizzati anche per ripristinare i dati dopo un backup. Un server binlog è fondamentalmente un repository di log binari. Puoi pensarlo come un server con uno scopo dedicato per recuperare i log binari da un master, mentre i server slave possono connettersi ad esso come se si connettessero a un server master.
Alcuni vantaggi di avere un server binlog su un master intermedio per distribuire il carico di lavoro di replica sono:
- Puoi passare a un nuovo server master senza che gli slave si accorgano che il server master effettivo è cambiato. Ciò consente una configurazione di replica più altamente disponibile in cui la replica ha la priorità elevata.
- Riduci il carico sul master servendo solo il server binlog di Maxscale invece di tutti gli slave.
- I dati nel log binario del master intermedio non sono una copia diretta dei dati ricevuti dal log binario del master reale. Pertanto, se viene utilizzato il commit di gruppo, ciò può causare una riduzione del parallelismo dei commit e una conseguente riduzione delle prestazioni dei server slave.
- Lo slave intermedio deve rieseguire ogni istruzione SQL che potenzialmente aggiunge latenza e ritarda la catena di replica.
In questo post del blog, esamineremo come sostituire un master intermedio (un host slave inoltrato ad altri slave in una catena di replica) con un server binlog in esecuzione su MaxScale per una migliore scalabilità e prestazioni .
Architettura
Sostanzialmente abbiamo una configurazione di replica MariaDB v10.4 a 4 nodi con un MaxScale v2.3 posizionato sopra la replica per distribuire le query in arrivo. Solo uno slave è collegato a un master (master intermedio) e gli altri slave si replicano dal master intermedio per servire carichi di lavoro di lettura, come illustrato nel diagramma seguente.
Trasformeremo la topologia sopra in questa:
Fondamentalmente, rimuoveremo il ruolo di master intermedio e lo sostituiremo con un server binlog in esecuzione su MaxScale. Il master intermedio verrà convertito in uno slave standard, proprio come gli altri host slave. Il servizio binlog sarà in ascolto sulla porta 5306 sull'host MaxScale. Questa è la porta a cui tutti gli slave si connetteranno per la replica in seguito.
Configurazione di MaxScale come server Binlog
In questo esempio, abbiamo già un MaxScale sopra il nostro cluster di replica che funge da bilanciamento del carico per le nostre applicazioni. Se non disponi di un MaxScale, puoi utilizzare ClusterControl per eseguire il deployment, vai semplicemente su Cluster Actions -> Add Load Balancer -> MaxScale e inserisci le informazioni necessarie come segue:
Prima di iniziare, esportiamo la configurazione corrente di MaxScale in un file di testo per il backup. MaxScale ha un flag chiamato --export-config per questo scopo ma deve essere eseguito come utente maxscale. Pertanto, il comando da esportare è:
$ su -s /bin/bash -c '/bin/maxscale --export-config=/tmp/maxscale.cnf' maxscaleSul master MariaDB, crea un utente slave di replica chiamato 'maxscale_slave' da utilizzare da MaxScale e assegnalo con i seguenti privilegi:
$ 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'@'%';Per gli utenti ClusterControl, vai su Gestisci -> Schemi e utenti per creare i privilegi necessari.
Prima di procedere ulteriormente con la configurazione, è importante rivedere lo stato corrente e la topologia dei nostri server back-end:
$ 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 │
└────────┴──────────────┴──────┴─────────────┴──────────────────────────────┴───────────┘Come possiamo vedere, l'attuale master è DB_757 (192.168.0.90). Prendi nota di queste informazioni mentre configureremo il server binlog per la replica da questo master.
Apri il file di configurazione di MaxScale in /etc/maxscale.cnf e aggiungi le seguenti righe:
[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.0Un po' di spiegazione - Stiamo creando due componenti:servizio e listener. Il servizio è dove definiamo le caratteristiche del server binlog e come dovrebbe essere eseguito. I dettagli su ogni opzione possono essere trovati qui. In questo esempio, i nostri server di replica sono in esecuzione con la replica semi-sincronizzazione, quindi dobbiamo usare semisync=true in modo che si connetta al master tramite il metodo di replica semi-sincronizzazione. Il listener è il punto in cui mappiamo la porta di ascolto con il servizio binlogrouter all'interno di MaxScale.
Riavvia MaxScale per caricare le modifiche:
$ systemctl restart maxscaleVerifica che il servizio binlog sia avviato tramite maxctrl (guarda la colonna Stato):
$ maxctrl show service replication-serviceVerifica che MaxScale stia ora ascoltando una nuova porta per il servizio binlog:
$ 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/maxscaleSiamo ora pronti per stabilire un collegamento di replica tra MaxScale e il master.
Attivazione del server Binlog
Accedi al server principale MariaDB e recupera il file binlog e la posizione correnti:
MariaDB> SHOW MASTER STATUS;
+---------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+---------------+----------+--------------+------------------+
| binlog.000005 | 4204 | | |
+---------------+----------+--------------+------------------+Usa la funzione BINLOG_GTID_POS per ottenere il valore GTID:
MariaDB> SELECT BINLOG_GTID_POS("binlog.000005", 4204);
+----------------------------------------+
| BINLOG_GTID_POS("binlog.000005", 4204) |
+----------------------------------------+
| 0-38001-31 |
+----------------------------------------+Torna al server MaxScale, installa il pacchetto client MariaDB:
$ yum install -y mysql-client
Connettiti al listener del server binlog sulla porta 5306 come utente maxscale_slave e stabilisci un collegamento di replica al master designato. Utilizza il valore GTID recuperato dal 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-31Nota:l'output sopra è stato troncato per mostrare solo le righe importanti.
Indicare gli slave al server Binlog
Ora su mariadb2 e mariadb3 (gli slave finali), cambia il master che punta al server binlog MaxScale. Poiché stiamo eseguendo con la replica semi-sincronizzazione abilitata, dobbiamo prima disattivarli:
(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 itNota:l'output sopra è stato troncato per mostrare solo le righe importanti.
All'interno di my.cnf, dobbiamo commentare le seguenti righe per disabilitare la semi-sincronizzazione in futuro:
#loose_rpl_semi_sync_slave_enabled=ON
#loose_rpl_semi_sync_master_enabled=ONA questo punto, il master intermedio (mariadb1) sta ancora replicando dal master (mariadb0) mentre gli altri slave stanno replicando dal server binlog. La nostra attuale topologia può essere illustrata come il diagramma seguente:
La parte finale consiste nel modificare il puntamento master del master intermedio (mariadb1 ) dopo che tutti gli schiavi che si attaccavano ad esso non ci sono più. I passaggi sono sostanzialmente gli stessi con gli altri slave:
(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-32Nota:l'output sopra è stato troncato per mostrare solo le righe importanti.
Non dimenticare di disabilitare anche la replica semi-sincronizzazione in my.cnf:
#loose_rpl_semi_sync_slave_enabled=ON
#loose_rpl_semi_sync_master_enabled=ONPossiamo verificare che il servizio del router binlog abbia più connessioni ora tramite 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 │
└─────────────────────┴────────────────┴─────────────┴───────────────────┴───────────────────────────────────┘Inoltre, i comuni comandi di amministrazione della replica possono essere utilizzati all'interno del server binlog MaxScale, ad esempio, possiamo verificare gli host slave collegati utilizzando questo comando:
(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 | |
+-----------+--------------+------+-----------+------------+A questo punto, la nostra topologia appare come ci aspettavamo:
La nostra migrazione dalla configurazione master intermedia alla configurazione del server binlog è ora completa.
