Reparaturlösung für inkonsistenten MySQL GTID-Master und -Slave

Inhaltsverzeichnis

Lösung 1: Replikate neu erstellen

Voraussetzungen
Vorteil
Mangel
Verfahren

Master
Sklave

Lösung 2: Percona-Toolkit zur Datenreparatur verwenden

Voraussetzungen

Vorteil

Mangel

Verfahren

Hintergrundbeispiel
Überprüfen der Konsistenz

Lösung 1: Replikate neu erstellen

MySQL 5.6 und höher führt eine neue Unterstützung für globale Transaktions-IDs (GTID) bei der Replikation ein. Beim Durchführen von Backups von MySQL und MySQL 5.7 mit aktiviertem GTID-Modus speichert Percona XtraBackup den GTID-Wert automatisch in xtrabackup_binlog_info. Diese Informationen können zum Erstellen neuer (oder Reparieren beschädigter) GTID-basierter Replikate verwendet werden.

Voraussetzungen

Percona xtrabackup muss auf der MySQL-Maschine installiert sein

Vorteil

Relativ sicher und einfach zu bedienen

Mangel

Bei großen Datenmengen verlängert sich die Sicherungszeit.
Wenn die Datenbank eine Lese-/Schreibtrennung aufweist, müssen die vom Slave ausgeführten Leseanforderungen an den Master übertragen werden.

Verfahren

Master

Verwenden Sie das Tool xtrabackup auf dem Master, um die aktuelle Datenbank zu sichern. Der Benutzer, der diesen Befehl ausführt, muss über die Berechtigung zum Lesen des MySQL-Datenverzeichnisses verfügen.

innobackupex --default-file=/etc/my.cnf --user=root -H 127.0.0.1 --password=[PASSWORT] /tmp

Kopieren Sie die Sicherungsdatei auf den Slave-Rechner

Sklave

Führen Sie diesen Befehl auf dem Slave-Rechner aus, um die Sicherungsdatei vorzubereiten

innobackupex --default-file=/etc/my.cnf --user=root -H 127.0.0.1 --password=[PASSWORT] --apply-log /tmp/[ZEITSTEMPEL]

Sichern und löschen Sie das Slave-Datenverzeichnis

systemctl stoppt mysqld
mv /data/mysql{,.bak}

Kopiere das Backup in das Zielverzeichnis, erteile die entsprechenden Berechtigungen und starte anschließend den Slave neu.

innobackupex --default-file=/etc/my.cnf --user=root -H 127.0.0.1 --password=[PASSWORT] --copy-back /tmp/[ZEITSTEMPEL]
chmod 750 /data/mysql
chown mysql.mysql -R /data/mysql
systemctl starte mysqld

Zeigen Sie die letzte GTID des aktuell ausgeführten Backups an, wie im folgenden Beispiel gezeigt

$ cat /tmp/[ZEITSTEMPEL]/xtrabackup_binlog_info
mysql-bin.000002 1232 c777888a-b6df-11e2-a604-080027635ef5:1-4

Diese GTID wird auch ausgedruckt, nachdem das Innobackupex-Backup abgeschlossen ist.

innobackupex: MySQL-Binlog-Position: Dateiname „mysql-bin.000002“, Position 1232, GTID der letzten Änderung „c777888a-b6df-11e2-a604-080027635ef5:1-4“

Melden Sie sich als Root bei MySQL an und konfigurieren Sie wie folgt

Neuer Slave > MASTER ZURÜCKSETZEN;
Neuer Slave > SET GLOBAL gtid_purged='c777888a-b6df-11e2-a604-080027635ef5:1-4';
NewSlave > MASTER ÄNDERN IN
       MASTER_HOST="$masterip",
       MASTER_USER="Antwort",
       MASTER_PASSWORD="$Slavepass",
       MASTER_AUTO_POSITION = 1;
Neuer Slave > SLAVE STARTEN;

Überprüfen Sie, ob der Replikationsstatus des Slaves normal ist

NewSlave > SLAVE-STATUS ANZEIGEN\G
     [..]
     Slave_IO_Running: Ja
     Slave_SQL_Running: Ja
     [...]
     Abgerufen_Gtid_Set: c777888a-b6df-11e2-a604-080027635ef5:5
     Ausgeführtes_Gtid_Set: c777888a-b6df-11e2-a604-080027635ef5:1-5

Wir können sehen, dass die Replik die neue Transaktion mit der Nummer 5 abgerufen hat, sodass sich die Transaktionen von 1 bis 5 bereits auf dieser Replik befinden. Damit haben wir den Bau einer neuen Replik abgeschlossen.

Lösung 2: Percona-Toolkit zur Datenreparatur verwenden

Das PT-Toolkit enthält zwei Tools, pt-table-checksum und pt-table-sync, die hauptsächlich dazu dienen, festzustellen, ob Master und Slave konsistent sind, und um Dateninkonsistenzen zu reparieren.

Voraussetzungen

Das Tool percona-toolkit muss auf der MySQL-Maschine installiert sein

Vorteil

Die Reparaturgeschwindigkeit ist schnell und es besteht keine Notwendigkeit, die Slave-Bibliothek anzuhalten

Mangel

Der Vorgang ist kompliziert. Sichern Sie die Datenbank vor dem Vorgang. Die zu reparierende Tabelle muss eine eindeutige Einschränkung aufweisen.

Verfahren

Hintergrundbeispiel

IP-Beziehungszuordnung

| IP | Rolle |
| ---- | ---- |
| 192.168.100.132 | Meister |
| 192.168.100.131 | Sklave |

Angenommen, die wiederherzustellende Tabellenstruktur ist wie folgt

mysql> anzeigen, Tabelle erstellen test.t;
+----------+-------------------------------------
| Tabelle | Tabelle erstellen |
+----------+-------------------------------------
| t | TABELLE ERSTELLEN `t` (
 `id` int(11) NICHT NULL,
 `Inhalt` varchar(20) DEFAULT NULL,
 PRIMÄRSCHLÜSSEL (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 |
+----------+-------------------------------------

Bei normaler Master-Slave-Konsistenz lauten die Daten von Master und Slave wie folgt

mysql> wähle * aus test.t;
+----+---------+
| ID | Inhalt |
+----+---------+
| 1 | ein |
| 2 | b |
+----+---------+
2 Zeilen im Satz (0,00 Sek.)

Im Extremfall stellt sich bei Auftreten der folgenden Master-Slave-Inkonsistenz die Situation wie folgt dar:

Der Master fügt einen Datensatz mit der ID 3 hinzu, wie unten gezeigt, dieser wird jedoch nicht mit dem Slave synchronisiert und führt automatisch ein Failover zum Slave durch.
Nachdem der alte Slave eine Zeit lang als neuer Master gedient hat, werden der Tabelle neue Datensätze hinzugefügt.

Nach dem Neustart des Old Masters lauten die Old Master-Daten wie folgt:

alter_master> wähle * aus test.t;
+----+---------+
| ID | Inhalt |
+----+---------+
| 1 | ein |
| 2 | b |
| 3 | c |
+----+---------+
3 Zeilen im Satz (0,00 Sek.)

Die Daten von New Master lauten wie folgt:

neuer_master> wähle * aus test.t;
+----+---------+
| ID | Inhalt |
+----+---------+
| 1 | ein |
| 2 | b |
| 3 |
| 4 | tt |
+----+---------+
4 Zeilen im Satz (0,00 Sek.)

Wenn zu diesem Zeitpunkt der alte Master als Slave des neuen Masters konfiguriert ist, wird ein Fehler gemeldet, beispielsweise der folgende Fehler

...Last_IO_Error: Binärprotokoll: ,,Slave hat mehr GTIDs als der Master, unter Verwendung der SERVER_UUID des Masters.

Sie können sehen, dass die GTID des alten Meisters 255 erreicht hat

Ausgeführtes_Gtid_Set: 5b750c75-86c2-11eb-af71-000c2973a2d5:1-10,
60d082ee-86c2-11eb-a9df-000c2988edab:1-255

Die GTID des neuen Masters beträgt nur 254

mysql> Masterstatus anzeigen\G
*************************** 1. Reihe ***************************
       Datei:mysql-bin.000001
     Position: 4062
   Binlog_Do_DB:
 Binlog_Ignore_DB:
Ausgeführtes_Gtid_Set: 5b750c75-86c2-11eb-af71-000c2973a2d5:1-2,
60d082ee-86c2-11eb-a9df-000c2988edab:1-254
1 Zeile im Satz (0,00 Sek.)

An diesem Punkt konfigurieren wir den alten Master so, dass der Fehler übersprungen wird und der alte Master in einen Zustand zurückversetzt wird, in dem er normal vom neuen Master replizieren kann.

alter_Master> Slave stoppen;
Abfrage OK, 0 Zeilen betroffen, 1 Warnung (0,00 Sek.)

old_master> set gtid_next='60d082ee-86c2-11eb-a9df-000c2988edab:254'; --Geben Sie die Version der nächsten Transaktion an, die GTID, die Sie überspringen möchten
Abfrage OK, 0 Zeilen betroffen (0,00 Sek.)

old_master> beginnen;
Abfrage OK, 0 Zeilen betroffen (0,00 Sek.)

old_master> commit; -- Fügt eine leere Transaktion ein
Abfrage OK, 0 Zeilen betroffen (0,00 Sek.)

old_master> set gtid_next='AUTOMATIC'; -- Auf automatische GTID zurücksetzen
Abfrage OK, 0 Zeilen betroffen (0,00 Sek.)

alter_Master> Slave starten;
Abfrage OK, 0 Zeilen betroffen (0,13 Sek.)

Dann können wir sehen, dass die Replikation auf dem alten Master normal verläuft.

mysql> Slave-Status anzeigen\G
      ...
       Slave_IO_Running: Ja
      Slave_SQL_Running: Ja
      ...
      Ausgeführtes_Gtid_Set: 5b750c75-86c2-11eb-af71-000c2973a2d5:1-10,
60d082ee-86c2-11eb-a9df-000c2988edab:1-255
        Auto_Position: 1
     DB replizieren_neu schreiben:
         Kanalname:
      Master_TLS_Version:

Zum Schluss löschen wir die Slave-Master-Informationen auf dem neuen Master.

new_master> alle Slaves für Kanal zurücksetzen '';
Abfrage OK, 0 Zeilen betroffen (0,00 Sek.)

neuer_Master> Slave-Status anzeigen\G;
Leerer Satz (0,01 Sek.)

Überprüfen der Konsistenz

Als nächstes müssen wir die Master-Slave-Konsistenz überprüfen. Führen Sie pt-table-checksum auf dem neuen Master aus. ROWS ist 4 und es gibt ein DIFFS

[root@localhost ~]# pt-table-checksum h='127.0.0.1',u='mha',p='[PASSWORT]',P=3306 --no-check-binlog-format --databases test
Überprüfen, ob für alle Tabellen eine Prüfsumme ermittelt werden kann ...
Prüfsumme starten ...
      TS FEHLER DIFFS REIHEN DIFF_ROWS CHUNKS ÜBERSPRINGEN ZEIT TABELLE
29.03.19:24:18 0 1 4 1 1 0 0,322 test.t

Zweiwege-Synchronisation (der Synchronisationsvorgang ändert die Daten, vor dem Vorgang wird eine Datensicherung durchgeführt)

Während des Synchronisierungsvorgangs ändert pt-table-sync Daten auf dem Master. Die Parameter von pt-table-sync lauten wie folgt:

pt-table-sync --Datenbanktest --bidirektional --Konfliktspalte='*' --Konfliktvergleich 'neueste' h='192.168.100.132',u='mha',p='[PASSWORT]',P=3306 h='192.168.100.131' --Drucken
--database gibt die auszuführende Datenbank an --bidirectional ist eine bidirektionale Synchronisation --conflict-column vergleicht die Spalten bei einem Konflikt --conflict-comparison Strategie zum Vergleichen von Konflikten --print gibt Vergleichsergebnisse aus --dry-run Testlauf --execute führt Test aus # Der DSN auf der linken Seite ist der Slave
# Der DSN auf der rechten Seite ist der Master

Hier geben wir „conflict-name='content'“ als Vergleichsspalte an und der geschäftliche Primärschlüssel wird im Allgemeinen als diese Spalte verwendet. Sie können sehen, dass die auszuführenden Anweisungen ausgedruckt werden

[root@localhost ~]# pt-table-sync --Datenbanktest --bidirektional --Conflict-Column='Inhalt' --Conflict-Comparison 'neueste' h='192.168.100.132',u='mha',p='[PASSWORT]',P=3306 h='192.168.100.131' --Drucken
/*192.168.100.132:3306*/ UPDATE `test`.`t` SET `content`='cc' WHERE `id`='3' LIMIT 1;
/*192.168.100.132:3306*/ INSERT INTO `test`.`t`(`id`, `content`) VALUES ('4', 'dd');

Führen Sie als nächstes die Anweisung aus

[root@localhost ~]# pt-table-sync --databases test --bidirectional --conflict-column='content' --conflict-comparison 'newest' h='192.168.100.132',u='mha',p='[PASSWORT]',P=3306 h='192.168.100.131' --execute

Führen Sie dann erneut einen Datenvergleich auf dem Master durch und Sie können sehen, dass die Daten normal sind.

[root@localhost ~]# pt-table-checksum h='127.0.0.1',u='mha',p='[PASSWORT]',P=3306 --no-check-binlog-format --databases test
Überprüfen, ob für alle Tabellen eine Prüfsumme ermittelt werden kann ...
Prüfsumme starten ...
      TS FEHLER DIFFS REIHEN DIFF_ROWS CHUNKS ÜBERSPRINGEN ZEIT TABELLE
30.03.12:09:57 0 0 4 0 1 0 0,330 test.t

Oben finden Sie den detaillierten Inhalt der Reparaturlösung für MySQL GTID Master-Slave-Inkonsistenzen. Weitere Informationen zur Reparatur von MySQL GTID Master-Slave-Inkonsistenzen finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!

Das könnte Sie auch interessieren: