Binární protokoly (binlogy) obsahují záznamy o všech změnách v databázích. Jsou nezbytné pro replikaci a lze je také použít k obnovení dat po zálohování. Binlog server je v podstatě úložiště binárních protokolů. Můžete si to představit jako server s vyhrazeným účelem získávat binární protokoly z hlavního serveru, zatímco podřízené servery se k němu mohou připojit, jako by se připojovaly k hlavnímu serveru.
Některé výhody binlogového serveru oproti střednímu hlavnímu serveru pro distribuci replikační zátěže jsou:
- Můžete přepnout na nový hlavní server, aniž by podřízené jednotky zaznamenaly, že se skutečný hlavní server změnil. To umožňuje více dostupné nastavení replikace, kde má replikace vysokou prioritu.
- Snižte zatížení hlavního serveru tím, že budete místo všech podřízených serverů sloužit pouze serveru binlog společnosti Maxscale.
- Data v binárním protokolu zprostředkujícího hlavního serveru nejsou přímou kopií dat přijatých z binárního protokolu skutečného hlavního serveru. Pokud se jako takové použije skupinové odevzdání, může to způsobit snížení paralelismu odevzdání a následné snížení výkonu podřízených serverů.
- Zprostředkující slave musí znovu provést každý příkaz SQL, který potenciálně zvyšuje latenci a zpožďuje replikační řetězec.
V tomto příspěvku na blogu se podíváme na to, jak nahradit prostředního hlavního serveru (přenos hostitele slave na ostatní slave v řetězci replikace) serverem binlog běžícím na MaxScale pro lepší škálovatelnost a výkon .
Architektura
V podstatě máme 4uzlové nastavení replikace MariaDB v10.4 s jednou MaxScale v2.3 umístěnou na replikaci, která distribuuje příchozí dotazy. Pouze jeden slave je připojen k masteru (prostřednímu masteru) a ostatní slave se replikují z prostředního masteru, aby obsluhovaly čtené úlohy, jak je znázorněno na následujícím diagramu.
Převedeme výše uvedenou topologii do tohoto:
V zásadě odebereme prostřední hlavní roli a nahradíme ji binlog server běžící na MaxScale. Střední master bude převeden na standardní slave, stejně jako ostatní slave hostitelé. Služba binlog bude naslouchat na portu 5306 na hostiteli MaxScale. Toto je port, ke kterému se budou všichni podřízení připojovat pro pozdější replikaci.
Konfigurace MaxScale jako serveru Binlog
V tomto příkladu již máme MaxScale umístěný nad naším replikačním clusterem, který funguje jako nástroj pro vyrovnávání zatížení pro naše aplikace. Pokud nemáte MaxScale, můžete použít ClusterControl k nasazení jednoduše přejděte na Cluster Actions -> Add Load Balancer -> MaxScale a vyplňte potřebné informace následovně:
Než začneme, vyexportujme aktuální konfiguraci MaxScale do textového souboru pro zálohování. MaxScale má pro tento účel příznak nazvaný --export-config, ale musí být spuštěn jako uživatel maxscale. Příkaz k exportu je tedy:
$ su -s /bin/bash -c '/bin/maxscale --export-config=/tmp/maxscale.cnf' maxscaleNa hlavním serveru MariaDB vytvořte podřízeného uživatele replikace s názvem 'maxscale_slave', kterého bude používat MaxScale, a přidělte mu následující oprávnění:
$ 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'@'%';Pro uživatele ClusterControl přejděte na Spravovat -> Schémata a uživatelé a vytvořte potřebná oprávnění.
Než se pustíme dále s konfigurací, je důležité zkontrolovat aktuální stav a topologii našich backendových serverů:
$ 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 │
└────────┴──────────────┴──────┴─────────────┴──────────────────────────────┴───────────┘Jak vidíme, aktuální hlavní server je DB_757 (192.168.0.90). Vezměte na vědomí tuto informaci, když se chystáme nastavit server binlog pro replikaci z tohoto hlavního serveru.
Otevřete konfigurační soubor MaxScale na /etc/maxscale.cnf a přidejte následující řádky:
[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.0Trochu vysvětlení - Vytváříme dvě složky - službu a posluchač. Služba je místo, kde definujeme charakteristiku serveru binlog a jak má běžet. Podrobnosti o každé možnosti naleznete zde. V tomto příkladu naše replikační servery běží se semisynchronní replikací, takže musíme použít semisync=true, aby se připojil k hlavnímu serveru pomocí semi-synchronizační replikační metody. Posluchač je místo, kde mapujeme naslouchací port se službou binlogrouter uvnitř MaxScale.
Restartujte MaxScale pro načtení změn:
$ systemctl restart maxscaleOvěřte, zda je služba binlog spuštěna pomocí maxctrl (podívejte se na sloupec Stav):
$ maxctrl show service replication-serviceOvěřte, že MaxScale nyní naslouchá novému portu pro službu 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/maxscaleNyní jsme připraveni vytvořit replikační spojení mezi MaxScale a hlavním serverem.
Aktivace serveru Binlog
Přihlaste se do hlavního serveru MariaDB a načtěte aktuální soubor binlog a pozici:
MariaDB> SHOW MASTER STATUS;
+---------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+---------------+----------+--------------+------------------+
| binlog.000005 | 4204 | | |
+---------------+----------+--------------+------------------+K získání hodnoty GTID použijte funkci BINLOG_GTID_POS:
MariaDB> SELECT BINLOG_GTID_POS("binlog.000005", 4204);
+----------------------------------------+
| BINLOG_GTID_POS("binlog.000005", 4204) |
+----------------------------------------+
| 0-38001-31 |
+----------------------------------------+Zpět na server MaxScale nainstalujte klientský balíček MariaDB:
$ yum install -y mysql-client
Připojte se k naslouchacímu procesu binlog serveru na portu 5306 jako uživatel maxscale_slave a vytvořte replikační odkaz na určeného hlavního serveru. Použijte hodnotu GTID získanou z hlavního serveru:
(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-31Poznámka:Výše uvedený výstup byl zkrácen, aby zobrazoval pouze důležité řádky.
Ukazování podřízených jednotek na server Binlog
Nyní na mariadb2 a mariadb3 (koncové slave) změňte master ukazující na server binlog MaxScale. Protože běžíme s povolenou replikací semi-sync, musíme je nejprve vypnout:
(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 itPoznámka:Výše uvedený výstup byl zkrácen, aby zobrazoval pouze důležité řádky.
V rámci my.cnf musíme okomentovat následující řádky, abychom v budoucnu zakázali semi-synchronizaci:
#loose_rpl_semi_sync_slave_enabled=ON
#loose_rpl_semi_sync_master_enabled=ONV tomto okamžiku se prostřední master (mariadb1) stále replikuje z hlavního serveru (mariadb0), zatímco ostatní slave se replikují ze serveru binlog. Naši současnou topologii lze ilustrovat jako níže uvedený diagram:
Poslední částí je změnit hlavní směrování středního masteru (mariadb1 ), protože všichni otroci, kteří se k němu připojovali, už tam nejsou. Kroky jsou v podstatě stejné jako u ostatních otroků:
(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-32Poznámka:Výše uvedený výstup byl zkrácen, aby zobrazoval pouze důležité řádky.
Nezapomeňte zakázat semi-synchronizační replikaci také v my.cnf:
#loose_rpl_semi_sync_slave_enabled=ON
#loose_rpl_semi_sync_master_enabled=ONMůžeme ověřit, že služba směrovače binlog má nyní více připojení přes 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 │
└─────────────────────┴────────────────┴─────────────┴───────────────────┴───────────────────────────────────┘V rámci serveru binlog serveru MaxScale lze také použít běžné příkazy pro správu replikace, například pomocí tohoto příkazu můžeme ověřit připojené podřízené hostitele:
(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 | |
+-----------+--------------+------+-----------+------------+V tuto chvíli naše topologie vypadá jako to, co jsme očekávali:
Naše migrace z přechodného hlavního nastavení na nastavení serveru binlog je nyní dokončena.