GTID-Replikation und Problembehandlung

Werfen wir zunächst einen Blick darauf, was GTID ist:

GTID (Global TransAktions ID) ist die Nummer einer übermittelten Transaktion und eine weltweit eindeutige Nummer.

GTID besteht eigentlich aus UUID+TID. Die UUID ist die eindeutige Kennung einer MySQL-Instanz. TID stellt die Anzahl der Transaktionen dar, die auf dieser Instanz festgeschrieben wurden, und steigt monoton an, wenn Transaktionen festgeschrieben werden. Anhand der GTID können Sie erkennen, auf welcher Instanz die Transaktion ursprünglich übermittelt wurde, und es erleichtert das Failover.

Als nächstes schauen wir uns an, wie man schnell einen Slave im GTID-Modus hinzufügt:

Wir wissen, dass die MySQL-Replikation darauf basierte, bevor es keine GTID-Replikation gab Binärprotokoll und Position ist fertig. Für die vorherige Kopie müssen wir die folgende Änderungsanweisung ausführen:

CHANGE MASTER TO MASTER_HOST='',MASTER_PORT=3306,MASTER_USER='repl',MASTER_PASSWORD='*****',MASTER_LOG_FILE='mysqlbinlog.000003',MASTER_LOG_POS=99721204;

Und wir können die folgende Änderungsanweisung in GTID ausführen:

CHANGE MASTER TO  MASTER_HOST='****', MASTER_USER='repl',  MASTER_PASSWORD='******',  MASTER_PORT=3306,  master_auto_position=1;

Wir können sehen, dass die ursprüngliche Binärprotokollmethode grundsätzlich die Angabe von MASTER_LOG_FILE und MASTER_LOG_POS erfordert, wenn die Replikation angegeben wird, die GTID-Replikation diese jedoch nicht kennen muss Parameter.

Sehen wir uns an, wie man eine Master-Slave-Replikation im GTID-Modus erstellt:

Wie Sie oben sehen können, müssen wir im GTID-Modus die beiden Parameter MASTER_LOG_FILE und nicht mehr kennen MASTER_LOG_POS Im Gegensatz dazu müssen wir nur den Master angeben, was die Erstellung einer Replikation viel einfacher macht. Im GTID-Modus müssen wir die folgenden zwei globalen Variablen kennen:

root@perconatest09:23:44>show global variables like 'GTID_%'\G*************************** 1. row ***************************Variable_name: gtid_executed
Value: 5031589f-3551-11e7-89a0-00505693235d:1-12,
806ede0c-357e-11e7-9719-00505693235d:1-11,
a38c33ee-34b7-11e7-ae1d-005056931959:1-24*************************** 2. row ***************************Variable_name: gtid_executed_compression_period
Value: 1000*************************** 3. row ***************************Variable_name: gtid_mode
Value: ON*************************** 4. row ***************************Variable_name: gtid_owned
Value:*************************** 5. row ***************************Variable_name: gtid_purged
Value: 5031589f-3551-11e7-89a0-00505693235d:1-12,
806ede0c-357e-11e7-9719-00505693235d:1-11,
a38c33ee-34b7-11e7-ae1d-005056931959:1-12

Was wir hauptsächlich sehen müssen, sind die beiden Parameter gtid_executed und gtid_purged: Dies ist eine Reihe von GTIDs aller ausgeführten Dinge. die Seriennummer der Dinge, die im Binärprotokoll abgelegt wurden. Dieser Parameter ist schreibgeschützt und kann nicht festgelegt werden.

gtid_purged: Diese Sequenz bezieht sich auf die Sequenznummer der GTID des Dings, das wir

im Binärprotokoll

löschen. Wir können es manuell festlegen, um die Verwaltung zu erleichtern. Nachdem wir diese beiden Parameter verstanden haben, schauen wir uns an, wie man eine Slave-Datenbank mit GTID-Replikation hinzufügt:

(1): Erstellen Sie eine vollständige Sicherung von der Master-Datenbank und zeichnen Sie die Master-Datenbank auf Datenbank gtid_executed

(2) zum Zeitpunkt der Bibliothekssicherung: Wiederherstellung aus der Bibliothek und Setzen von gtid_purged aus der Bibliothek auf gtid_executed

(3) des Masters, den wir im ersten Schritt erhalten haben Schritt: CHANGE MASTER-Anweisung ausführen.

Wir

verwenden mysql

dump, um die Hauptdatenbank zu sichern und die Sicherung auf einem neuen Computer als Slave-Datenbank wiederherzustellen. Schauen Sie sich vor der Ausführung die Parameter in der Hauptbibliothek an:

root@perconatest09:23:58>show global variables like 'GTID_e%'\G*************************** 1. row ***************************Variable_name: gtid_executed
Value: 5031589f-3551-11e7-89a0-00505693235d:1-12,
806ede0c-357e-11e7-9719-00505693235d:1-11,
a38c33ee-34b7-11e7-ae1d-005056931959:1-242 rows in set (0.01 sec)
root@perconatest09:41:33>show global variables like 'GTID_p%'\G*************************** 1. row ***************************Variable_name: gtid_purged
Value: 5031589f-3551-11e7-89a0-00505693235d:1-12,
806ede0c-357e-11e7-9719-00505693235d:1-11,
a38c33ee-34b7-11e7-ae1d-005056931959:1-121 row in set (0.01 sec)

Erstellen Sie dann ein Backup in der Hauptdatenbank:

mysqldump --all-databases --single-transaction --triggers --routines --host=127.0.0.1 --port=18675 --user=root--p > /home/sa/backup.sql

Wir können einen Blick auf die Sicherungsdatei werfen:

[root@localhost sa]# head -30 backup.sql

Wir können folgende Parameter sehen:

SET @@GLOBAL.GTID_PURGED='5031589f-3551-11e7-89a0-00505693235d:1-12,
806ede0c-357e-11e7-9719-00505693235d:1-11,
a38c33ee-34b7-11e7-ae1d-005056931959:1-24';

Das heißt, wenn wir wiederherstellen, wird GTID_PURGED automatisch festgelegt, und dieser Wert ist zufällig der gtid_executed des Masters, sodass wir ihn nach der Wiederherstellung aus der Bibliothek grundsätzlich nicht angeben müssen .

Geben Sie die Datenwiederherstellung aus der Datenbank ein:

source backup.sql;

Wir wissen, dass es nicht nötig ist, den Wert von GTID_PURGE anzugeben. Wenn Sie sich nicht sicher sind, Sie können es bestätigen:

show global variables like 'gtid_executed';
show global variables like 'gtid_purged';

Geben Sie einfach das an später kopieren:

CHANGE MASTER TO MASTER_HOST="***", MASTER_USER="root", MASTER_PASSWORD="*****", MASTER_PORT=3306, MASTER_AUTO_POSITION = 1;

Ersetzen Sie * durch den Host Sie müssen angeben, dass die relevanten Informationen der Bibliothek in Ordnung sind.

Wenn im GTID-Master-Slave-Replikationsmodus ein Fehler auftritt, wie sollten wir ihn beheben?

Wenn die Protokolle unserer Hauptbibliothek gelöscht wurden und Vorgänge wie

Zurücksetzen

ausgeführt werden, meldet unsere Slave-Bibliothek den folgenden Fehler:

Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.'

meldet uns, dass das Protokoll nicht gefunden werden kann, und die Master-Slave-Replikation wird gestoppt. Schauen wir uns die Verarbeitung an Methode:

(1) Die Hauptbibliothek führt die folgenden Vorgänge aus:

root@perconatest09:41:38>show global variables like 'GTID_EXECUTED';+---------------+---------------------------------------------------------------------------------------------------------------------------------+| Variable_name | Value |+---------------+---------------------------------------------------------------------------------------------------------------------------------+| gtid_executed | 5031589f-3551-11e7-89a0-00505693235d:1-12,
806ede0c-357e-11e7-9719-00505693235d:1-11,
a38c33ee-34b7-11e7-ae1d-005056931959:1-24 |+---------------+---------------------------------------------------------------------------------------------------------------------------------+1 row in set (0.01 sec)

(2) Aus der Bibliothek

root@(none)03:04:49>set global GTID_PURGED='5031589f-3551-11e7-89a0-00505693235d:1-12,806ede0c-357e-11e7-9719-00505693235d:1-11,a38c33ee-34b7-11e7-ae1d-005056931959:1-24';

Hinweis: Bevor Sie angeben, müssen Sie zunächst bestätigen, dass dieser Wert leer ist. Andernfalls müssen wir Folgendes tun:

root@(none)03:04:49>reset master;
root@(none)03:04:49>set global GTID_PURGED='5031589f-3551-11e7-89a0-00505693235d:1-12,806ede0c-357e-11e7-9719-00505693235d:1-11,a38c33ee-34b7-11e7-ae1d-005056931959:1-24';
root@(none)03:04:49>start slave;
root@(none)03:04:49>show slave status\G

Die Reparatur ist abgeschlossen, aber wir sollten besser die Prüfsumme verwenden, um die Konsistenz der Master-Slave-Daten zu überprüfen.

Fehlermeldung:

Ich habe beim Lesen von Daten aus dem Binärprotokoll den schwerwiegenden Fehler 1236 vom Master erhalten: „Der Slave stellt eine Verbindung mit CHANGE MASTER TO MASTER_AUTO_POSITION = 1 her, aber der Master hat Binärprotokolle gelöscht, die GTIDs enthalten, die der Slave benötigt.

(Gepostet FehlermeldungUm die Anzahl der Aufrufe zu erhöhen)

Natürlich garantiert die obige Methode nicht die vollständige Konsistenz der Daten. Wir müssen auch die Daten mithilfe von pt-table-checksum überprüfen pt-table-sync, aber dies ist nicht unbedingt die effizienteste Methode, eine vollständige Sicherung durchzuführen, dann wiederherzustellen und dann den Master anzugeben, wie zuvor beschrieben.

Das obige ist der detaillierte Inhalt vonGTID-Replikation und Problembehandlung. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!