MySQL Fehler 1236 Bei der Verwendung von GTID

Question

Ich ermöglichten eine Replik auf meinen Percona Server mit GTID erstellen möge, aber haben diesen Fehler, wenn i Slave-Status anzeigen:

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.' 

Normalerweise würde ich meinen Sklaven stoppen, zurücksetzen Setzen Sie den Master (am Slave) zurück und holen Sie sich einen neuen GTID_PURGED-Wert vom Master. Aber dieses Mal hat der Master einen sehr ungewöhnlichen Wert (e), und ich bin nicht sicher, wie Sie feststellen können, welche zu benutzen:

mysql> show master status\G 
*************************** 1. row *************************** 
      File: mysqld-bin.000283 
     Position: 316137263 
    Binlog_Do_DB: 
Binlog_Ignore_DB: 
Executed_Gtid_Set: 1570dee1-165b-11e6-a4a2-00e081e93212:1-3537, 
c73f3ee7-e8d4-ee19-6507-f898a9930ccd:1-18609, 
cdb70eaa-f753-ee1b-5c95-ecb8024ae729:1-2357789559:2357789561-2357790104:2357790106-2514115701:2514115703-2514115705:2514115707-2546512667 
1 row in set (0.00 sec) 

vom Slave mit der neuen Sicherungskopie, bekomme ich diese:

root@ubuntu:/var/lib/mysql# cat xtrabackup_binlog_info 
mysqld-bin.000283  294922064  1570dee1-165b-11e6-a4a2-00e081e93212:1-3537, 
c73f3ee7-e8d4-ee19-6507-f898a9930ccd:1-18609, 
cdb70eaa-f753-ee1b-5c95-ecb8024ae729:1-2357789559:2357789561-2357790104:2357790106-2514115701:2514115703-2514115705:2514115707-2546400960 

Noch eine Sache, ich löschte gerade die Binärprotokolle auf dem Master, bevor ich eine Sicherung machte. Die automatische binlog-Bereinigung ist auf 7 Tage eingestellt. Also ich weiß es nicht, weil das Bin-Protokoll gelöscht wurde, wie der Fehler vorschlägt.

Ich benutze Ubuntu 14.04 und Percona Server Version 5.6.31-77.

Wie kann ich dieses Problem beheben? Was ist der korrekte Wert des GTID_PURGED des Masters?

Answer 1

mysql 5.6 GTID-Replikationsfehler und -behebungen Was ist GTID? 

4c2ad77f-697e-11E3-b2c3-c80aa9f17dc4

• Dies ist der 128-Bit-Identifikationsnummer des Servers (SERVER_UUID). Es identifiziert, wo die Transaktion entstanden ist. Jeder Server hat seine eigene SERVER_UUID. Welche Probleme löst GTID?

• Es ist möglich, eine Transaktion auf den Replikationsservern eindeutig zu identifizieren. Erleichtern Sie die Automatisierung des Failover-Prozesses. Es ist nicht notwendig, Berechnungen durchzuführen, das Binärlog usw. zu überprüfen. Nur MASTER_AUTO_POSITION = 1.

• Auf Anwendungsebene ist es einfacher, WRITE/READ-Split durchzuführen. Nach einem Schreibvorgang auf dem MASTER haben Sie eine GTID, überprüfen Sie also, ob diese GTID auf dem SLAVE ausgeführt wurde, den Sie für Lesevorgänge verwenden.
• Die Entwicklung neuer Automatisierungswerkzeuge ist jetzt kein Problem. Wie kann ich es implementieren?

Drei Variablen werden in ALLEN Servern der Replikationskette benötigt

• gtid_mode: Es kann ein- oder ausgeschaltet sein (nicht 1 oder 0). Es aktiviert die GTID auf dem Server.
• log_bin: Binärprotokolle aktivieren. Obligatorisch zum Erstellen einer Replikationsumgebung.
• log-slave-updates: Slave-Server müssen die Änderungen, die vom Master kommen, in einem eigenen Binärprotokoll protokollieren.
• erzwingen-gtid-konsistenz: Anweisungen, die nicht in einer transaktionssicheren Weise protokolliert werden können, werden vom Server abgelehnt. ref: http://dev.mysql.com/doc/refman/5.6/en/replication-gtids-howto.html

Replikationsfehler und Korrekturen:

„'fatal erhielt Fehler 1236 von Master, wenn Daten aus Binärlog Lesen:“ Der Slave verbindet CHANGE MASTER mit 1 bis MASTER_AUTO_POSITION =, aber der Meister hat Binärlogs gelöscht, die GTIDs enthalten, die der Slave benötigt. "slave_io thread stop running.

Auflösung: Unter Berücksichtigung folgenden sind die Master - Slave UUID

MASTER UUID: 4c2ad77f-697e-11E3-b2c3-c80aa9f17dc4

SLAVE UUID: 5b37def1-6189-11e3-bee0-e89a8f22a444

Schritte:

Slave> Slave stoppen;

Slave> SPÜLTISCHE MIT READ LOCK;

Slave> Masterstatus anzeigen;

‚4c2ad77f-697e-11E3-b2c3-c80aa9f17dc4: 1-83345127,5b37def1-6189-11e3-bee0-e89a8f22a444: 1-13030: 13.032-13.317: 13.322-13.325: 13.328-653.183: 653.185-654.126: 654.128 -1400817: 1400820-3423394: 3423401-5779965 '

(HIER 83.345.127 Last GTID auf Master ausgeführt und 5.779.965 Last Slave GTID auf Meister ausgeführt)

Slave> Reset Master;

Slave> set global GTID_PURGED =‘4c2ad77f-697e-11E3-b2c3-c80aa9f17dc4: 1-83345127,5b37def1-6189-11e3-bee0-e89a8f22a444: 1-5779965 ';

Slave> Start Slave;

Slave> Tabellen entsperren;

Slave> Slave-Status anzeigen;

HINWEIS: Nach diesem Neustart andere Slave-Slaves erneut starten, wenn sie aufhören zu replizieren;

Fehler: 'Fehler' Tabelle ... 'nicht existiert' auf Abfrage. Standarddatenbank: ... Frage: „INTO OR Last_SQL_Error einfügen: ... .Error‚doppelte Eintrag‘SKIP Transaktion auf Slave (slave_sql Gewindeanschlag läuft) HINWEIS:

• SQL_SLAVE_SKIP_COUNTER funktioniert nicht mehr mit GTID.
• Wir müssen herausfinden, welche Transaktion die Replikation fehlschlägt.
  • - Von Binärlog
  • - Von SLAVE STATUS SHOW Art von Fehlern (vs ausgeführt abgerufen): (Check letzte SQL-Fehler in Show Slave-Status)

Auflösung: Unter Berücksichtigung folgender sind die Master -

Sklave UUID

MASTER UUID: 4c2ad77f-697e-11E3-b2c3-c80aa9f17dc4

SLAVE UUID: 5b37def1-6189-11e3-bee0-e89a8f22a444

Slave> Slave-Status anzeigen;

kopieren Sie den Wert 'Executed_Gtid_Set'. '4c2ad77f-697e-11E3-b2c3-c80aa9f17dc4: 1-659731804,5b37def1-6189-11e3-bee0-e89a8f22a444: 1-70734947-80436012: 80.436.021 bis 80.437.839'

-Seems diesen Slave (mit UUID 5b37def1-6189- 11e3-bee0-e89a8f22a444) die Transaktion '80437840' verursacht hier das Problem.

Slave> STOP SLAVE;

Slave> SET GTID_NEXT = "5b37def1-6189-11e3-bee0-e89a8f22a444: 80437840"; (last_executed_slave_gtid_on_master + 1)

Slave> BEGIN; VERPFLICHTEN;

Slave> SET GTID_NEXT = "AUTOMATIC";

Slave> START SLAVE;

Slave> Slave-Status anzeigen;

und es ist alles SET !!!