V tomto článku se podíváme na migraci z tradiční replikace na GTID,
probereme, jak to udělat kompletně online. Nejprve si proberme některé možnosti konfigurace související s GTID. Režim GTID určuje, zda server používá GTID nebo ne, to má vliv nejen na binární přihlášení replikace, protože binární protokoly budou obsahovat GTID. Možnost vynutit konzistenci GTID zajišťuje, že server povolí pouze příkazy, které lze bezpečně provést v režimu GTID. Příkazy, jejichž provedení není bezpečné, jsou jako create table as select, existuje několik dalších, většinou kolem, pro hodnotné gtid_owned mohou monitorovat GTID na transakcích za letu. To je velmi užitečné, když vypínají GTID online.
Pojďme si některé probrat a abychom byli přesní, je to jen jedna stavová proměnná související s GTID. ONGOING_ANONYMOUS_TRANSACTION_COUNT je protějškem vlastněného GTID, ale v případě migrace, jako je ONGOING_ANONYMOUS_TRANSACTION_COUNT, se nazývá anonymní transakce, protože nemá identifikátor, kterým je GTID.
Všechny operace je třeba provést na jednom z uzlů v topologii replikace a případně na všech uzlech. Osvědčeným postupem je provést nejprve slave a master, ale v případě mnoha operací nezáleží na pořadí, pokud jsou prováděny v každé instanci replikační topologie.
V tomto prostředí mám tři virtuální stroje, dva z nich jsou databáze a jeden z nich je sysbench stroj pro generování provozu, takže začněme.
Master:192.168.66.5
Slave: 192.168.66.7
V uzlu sysbench spusťte připravený příkaz k vytvoření databáze sysbench, stačí jej zkopírovat a vložit zdola.
sysbench \ --db-driver=mysql \ --mysql-user=sbtest_user \ --mysql_password= password \ --mysql-db=sbtest \ --mysql-host=192.168.66.5 \ --mysql-port=3306 \ --tables=16 \ --table-size=10000 \ /usr/share/sysbench/oltp_read_write.lua prepare
Na uzlu sysbench běží určité zatížení proti hlavnímu serveru, který jsme spouštěli po dobu trvání úlohy.
sysbench \ --db-driver=mysql \ --mysql-user=sbtest_user \ --mysql_password=password \ --mysql-db=sbtest \ --mysql-host=192.168.66.5 \ --mysql-port=3306 \ --tables=16 \ --table-size=10000 \ --threads=4 \ --time=0 \ --events=0 \ --rate=10 \ --report-interval=1 \ /usr/share/sysbench/oltp_read_write.lua run
Spusťte klienta MySQL na všech uzlech, na všech databázových uzlech. Podívejme se na seznam procesů show na hlavním serveru, abyste viděli, že to zde běží.
mysql> show processlist; +----+-----------------+--------------------+--------+-------------+------+---------------------------------------------------------------+------------------+ | Id | User | Host | db | Command | Time | State | Info | +----+-----------------+--------------------+--------+-------------+------+---------------------------------------------------------------+------------------+ | 5 | event_scheduler | localhost | NULL | Daemon | 2350 | Waiting on empty queue | NULL | | 8 | root | localhost | sbtest | Query | 0 | starting | show processlist | | 15 | syncstndby | 192.168.66.7:47894 | NULL | Binlog Dump | 156 | Master has sent all binlog to slave; waiting for more updates | NULL | | 17 | sbtest_user | 192.168.66.6:38130 | sbtest | Sleep | 0 | | NULL | | 18 | sbtest_user | 192.168.66.6:38132 | sbtest | Sleep | 1 | | NULL | | 19 | sbtest_user | 192.168.66.6:38134 | sbtest | Sleep | 0 | | NULL | | 20 | sbtest_user | 192.168.66.6:38136 | sbtest | Sleep | 0 | | NULL | +----+-----------------+--------------------+--------+-------------+------+---------------------------------------------------------------+------------------+ 7 rows in set (0.00 sec)
Dobře, od nynějška budeme pracovat nejprve s balzámem a pánem.
Nejprve tedy nastavíme force_gtid_consistency =‚varovat‘ na slave, na slave master.
Slave 192.168.66.7
set global enforce_gtid_consistency = 'warn';
Master 192.168.66.5
set global enforce_gtid_consistency = 'warn';
tady jsme hotovi a zkontrolujeme chybu MySQL viz protokol chyb, mělo by to být v pořádku; v protokolu chyb neuvidíte žádnou chybu. Dalším krokem je všude spustit set global force_gtid_consistency=’on’ a poté znovu zkontrolovat šipku.
Slave 192.168.66.7
set global enforce_gtid_consistency='on';
Master 192.168.66.5
set global enforce_gtid_consistency='on';
Takže dalším krokem je nastavení globálního gtid_mode='off_permissive'; tak znovu spustím klienta MySQL a nastavím ho. A pak zkontrolujeme protokol chyb
Slave 192.168.66.7
set global gtid_mode='off_permissive';
Master 192.168.66.5
set global gtid_mode='off_permissive';
Na každém serveru nastavíme gtid_mode='on_permissive'; takže v tomto bodě generujeme transakce GTID.
Slave 192.168.66.7
set global gtid_mode='on_permissive';
Master 192.168.66.5
set global gtid_mode='on_permissive';
Takže je to nastaveno všude. Pojďme zkontrolovat protokoly chyb
Dobře, takže nyní zkontrolujeme, zda některý z uzlů neprobíhá anonymní transakce, protože pokud ano, pak, když nastavíme gtid_mode=’on’, server již anonymní transakce nepřijímá a budeme dostávat chyby.
Slave 192.168.66.7
mysql> show status like 'ongoing_anonymous_transaction_count'; +-------------------------------------+-------+ | Variable_name | Value | +-------------------------------------+-------+ | Ongoing_anonymous_transaction_count | 0 | +-------------------------------------+-------+ 1 row in set (0.22 sec)
Master 192.168.66.5
mysql> show status like 'ongoing_anonymous_transaction_count'; +-------------------------------------+-------+ | Variable_name | Value | +-------------------------------------+-------+ | Ongoing_anonymous_transaction_count | 0 | +-------------------------------------+-------+ 1 row in set (0.04 sec)
Oba servery tedy nemají, což znamená, že jsme připraveni zapnout GTID. Povolím gtid_mode =on.
Master 192.168.66.5
mysql> set global gtid_mode='on'; Query OK, 0 rows affected (0.03 sec)
Slave 192.168.66.7
mysql> set global gtid_mode='on'; Query OK, 0 rows affected (0.03 sec)
Nyní na podřízených zařízeních musíme replikaci znovu inicializovat, abychom použili master-auto-position=1
Slave 192.168.66.7
stop slave; change master to master_auto_position=1; start slave;
Takže, co to dělá, tento „změna master“ zde, pokud již bylo salve vlákno nakonfigurováno, pak pokud některý parametr není ovlivněn příkazem change master, bude ponechán na aktuální hodnotě.
Pojďme zkontrolovat zobrazení stavu slave na slave a ukázat stav master na masteru. všechno by mělo běžet v pořádku.
mysql> show salve status\G; mysql> show master status;
Nyní je migrace hotová:
Protože víme, že žádná aktualizace není úspěšná, pokud nemáte plán vrácení, pro vrácení zpět klikněte na níže uvedený odkaz a přečtěte si další článek.
Vrátit se k tradiční replikaci z GTID