In diesem Artikel werfen wir einen Blick auf die Migration von traditioneller Replikation zu GTID,
wir werden besprechen, wie man das komplett online macht. Lassen Sie uns zunächst einige GTID-bezogene Konfigurationsoptionen besprechen. Der GTID-Modus bestimmt, ob der Server GTIDs verwendet oder nicht. Dies wirkt sich nicht nur auf die binäre Anmeldung bei der Replikation aus, da die Binärprotokolle GTIDs enthalten. Die Option „GTID-Konsistenz erzwingen“ stellt sicher, dass der Server nur Anweisungen zulässt, deren Ausführung im GTID-Modus sicher ist. Anweisungen, die nicht sicher ausgeführt werden können, sind wie create table as select, es gibt ein paar mehr, die meistens in der Nähe sind, bis hin zu gtid_owned, die wertvoll sind, um die GTIDs von In-Flight-Transaktionen zu überwachen. Dies ist sehr nützlich, wenn sie GTIDs online deaktivieren.
Lassen Sie uns einige besprechen und um genau zu sein, ist es nur eine GTID-bezogene Statusvariable. ONGOING_ANONYMOUS_TRANSACTION_COUNT ist das Gegenstück zur GTID, aber im Falle einer Migration wie bei ONGOING_ANONYMOUS_TRANSACTION_COUNT wird sie als anonyme Transaktion bezeichnet, da sie keine Kennung hat, die die GTID ist.
Alle Vorgänge müssen auf einem der Knoten in der Replikationstopologie und schließlich auf allen Knoten ausgeführt werden. Die beste Vorgehensweise besteht darin, zuerst den Slave und dann den Master auszuführen, aber bei vielen Operationen spielt die Reihenfolge keine Rolle, solange sie auf jeder Instanz der Replikationstopologie ausgeführt werden.
In dieser Umgebung habe ich drei virtuelle Maschinen, zwei davon sind Datenbanken und eine davon ist eine Sysbench-Maschine, um Datenverkehr zu generieren, also fangen wir an.
Master:192.168.66.5
Slave: 192.168.66.7
Lassen Sie uns auf dem Sysbench-Knoten den vorbereiteten Befehl ausführen, um eine Sysbench-Datenbank zu erstellen, Sie können ihn einfach von unten kopieren und einfügen.
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
Auf dem Sysbench-Knoten läuft einige Arbeitslast gegen den Master, den wir für die Dauer der Aufgabe ausgeführt haben.
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
Starten wir den MySQL-Client auf allen Knoten, allen Datenbankknoten. Lassen Sie uns die Show-Prozessliste auf dem Master überprüfen, damit Sie sehen können, dass dieser hier ausgeführt wird.
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)
Okay, ab jetzt arbeiten wir zuerst mit der Salbe und dem Meister.
Also setzen wir zuerst force_gtid_consistency =‘warn’ auf slave, auf slave master.
Slave 192.168.66.7
set global enforce_gtid_consistency = 'warn';
Meister 192.168.66.5
set global enforce_gtid_consistency = 'warn';
Wir sind hier fertig und überprüfen den MySQL-Fehler. Siehe Fehlerprotokoll. Dies sollte in Ordnung sein. Sie werden keinen Fehler im Fehlerprotokoll sehen. Der nächste Schritt besteht darin, überall set global force_gtid_consistency=’on’ auszuführen und dann den Pfeil erneut zu prüfen.
Slave 192.168.66.7
set global enforce_gtid_consistency='on';
Meister 192.168.66.5
set global enforce_gtid_consistency='on';
Der nächste Schritt ist also das Setzen von global gtid_mode=’off_permissive’; Also werde ich den MySQL-Client erneut starten und einstellen. Und dann prüfen wir das Fehlerprotokoll
Slave 192.168.66.7
set global gtid_mode='off_permissive';
Master 192.168.66.5
set global gtid_mode='off_permissive';
Auf jedem Server setzen wir gtid_mode=’on_permissive’; damit wir an dieser Stelle GTID-Transaktionen generieren.
Slave 192.168.66.7
set global gtid_mode='on_permissive';
Master 192.168.66.5
set global gtid_mode='on_permissive';
Es ist also überall eingestellt. Sehen wir uns die Fehlerprotokolle an
In Ordnung, also werden wir jetzt prüfen, ob einer der Knoten laufende anonyme Transaktionen hat, denn wenn dies der Fall ist, akzeptiert der Server keine anonymen Transaktionen mehr, wenn wir gtid_mode='on' setzen, und wir erhalten Fehler.
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)
Meister 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)
Beide Server haben also keine, was bedeutet, dass wir bereit sind, GTIDs einzuschalten. Ich werde gtid_mode =on aktivieren.
Meister 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)
Jetzt müssen wir auf den Slaves die Replikation neu initialisieren, um master-auto-position=1
zu verwendenSlave 192.168.66.7
stop slave; change master to master_auto_position=1; start slave;
Also, was das macht, dieser „Change Master“ hier, wenn der Salve-Thread bereits konfiguriert war, dann wird, wenn irgendein Parameter nicht durch den Change Master-Befehl berührt wird, er einfach auf dem aktuellen Wert belassen.
Lassen Sie uns den Slave-Status auf den Slaves anzeigen und den Master-Status auf dem Master anzeigen. alles sollte gut laufen.
mysql> show salve status\G; mysql> show master status;
Jetzt ist die Migration abgeschlossen:
Da wir wissen, dass kein Upgrade erfolgreich ist, wenn Sie keinen Rollback-Plan haben, klicken Sie zum Zurücksetzen bitte auf den folgenden Link, um den nächsten Artikel zu lesen.
Rollback zur traditionellen Replikation von GTID
