Fehler bei eingehender Replikation beheben
Beheben Sie Probleme, die bei der eingehenden Replikation auftreten.
Fehler bei eingehender Replikation beheben
Isolieren Sie Fehler bei der Inbound-Replikation, indem Sie Informationen zur Inbound-Replikation abrufen.
MySQL-Shell verwenden
Verwenden Sie die Shell MySQL oder ein MySQL-Clientprogramm, um Informationen zur eingehenden Replikation abzurufen.
- Ein ausgeführtes DB-Systemreplikat.
- MySQL Shell oder ein MySQL-Clientprogramm, das mit dem Replikat-DB-System verbunden ist.
SHOW REPLICA STATUS \GZeigt Statusinformationen zu wesentlichen Parametern der Replikatthreads an. Siehe SHOW REPLICA STATUS.
SELECT * FROM performance_schema.replication_connection_status \GZeigt den aktuellen Status des I/O-Threads an, der die Verbindung des Replikats mit der Quelle verarbeitet. Siehe replication_connection_status.
SELECT * FROM performance_schema.replication_applier_status_by_worker \GZeigt Details der Transaktionen an, die von Applier-Threads auf einem Replikat verarbeitet werden. Siehe replication_applier_status_by_worker.
Eingehende Replikation - Empfängerfehlercodes
In dieser Tabelle werden einige der allgemeinen Empfängerfehlercodes für die eingehende Replikation angezeigt.
Tabelle 22-4: Empfängerfehlercodes bei eingehenden Replikationen
| Fehlercode | Beschreibung |
|---|---|
MY-1045: ER_ACCESS_DENIED_ERROR; Access denied for user '%s'@'%s' |
|
MY-1227 (42000): Access denied; you need (at least one of) the SUPER or SET_USER_ID privilege(s) for this operation |
Sie haben folgende Möglichkeiten:
|
MY-1236: ER_MASTER_FATAL_ERROR_READING_BINLOG Got fatal error %d from master when reading data from binary log: '%s' |
Siehe Schwerwiegenden Fehler 1236 beheben. |
MY-2003: Network connection has been refused |
Hostname und Port sind falsch, oder die Quelle wird nicht ausgeführt. Prüfen Sie den definierten Hostnamen und Port, und vergewissern Sie sich, dass die Quelle ausgeführt wird. |
MY-3159: ER_SECURE_TRANSPORT_REQUIRED Connections using insecure transport are prohibited while --require_secure_transport=ON |
Die Quelle erfordert eine sichere Verbindung. Vergewissern Sie sich, dass Sie bei der Definition des Kanals eine der SSL-Optionen ausgewählt haben. |
Eingehende Replikation - Applier-Fehlercodes
In dieser Tabelle werden einige der häufigsten Applier-Fehlercodes für eingehende Replikationen angezeigt.
Tabelle 22-5: Applier-Fehlercodes bei eingehenden Replikationen
| Fehlercode | Beschreibung |
|---|---|
|
Diese Fehler treten auf, wenn die Daten auf dem Replikat nicht mehr mit der Quelle synchronisiert sind. Dies kann beispielsweise geschehen, wenn die Daten auf dem Replikat manuell bearbeitet wurden. Um diese Fehler zu beheben, müssen Sie die Quelle und das Replikat neu synchronisieren und den Replikationskanal wieder aktivieren. |
MY-1205: ER_LOCK_WAIT_TIMEOUT |
Timeout überschritten. Um diesen Fehler zu beheben, nehmen Sie den Replikationskanal wieder auf. Siehe Kanäle wiederaufnehmen. |
MY-1595/ MY-013121: RELAY LOG READ FAILURE |
Das Relay-Log ist beschädigt und kann nicht gelesen werden. Um diesen Fehler zu beheben, setzen Sie den Replikationskanal zurück. Siehe Kanäle zurücksetzen. |
Schwerwiegenden Fehler 1236 beheben
Sie erhalten den Fehler, wenn entweder das GTID-Set aus dem logischen Dump nicht auf das DB-System angewendet wird oder die Binärlogs aus der Quelle gelöscht wurden. Binärlogs sind eine obligatorische Anforderung für Replikationen.
MySQL-Shell verwenden
Verwenden Sie die Shell MySQL, um den Fatal Error 1236 aufzulösen, der beim Ausführen der eingehenden Replikation angezeigt wird.
- Sie erhalten den schwerwiegenden Fehler
Fatal Error 1236beim Ausführen der eingehenden Replikation: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.
Im anfänglichen Verbindungs-Handshake sendet das Replikat (DB-System) ein GTID-Set mit den Transaktionen, die es bereits empfangen und/oder festgeschrieben hat. Die Quelle antwortet durch Senden aller in ihrem Binärlog aufgezeichneten Transaktionen, deren GTID nicht in dem vom Replikat gesendeten GTID-Set enthalten ist. Dieser Austausch stellt sicher, dass die Quelle nur Transaktionen mit einer GTID sendet, die das Replikat noch nicht erfasst oder festgeschrieben hat.
- Um das GTID-Set während des Ladevorgangs anzuwenden, verwenden Sie die Option
updateGtidSet: "append"im MySQL Shell-BefehlloadDump(). Siehe MySQL Shell-Dumpladeutility. - Prüfen und erhöhen Sie die Ablauflogkonfiguration der Quelle, um sicherzustellen, dass ausreichend Zeit für die Übertragung der Daten in das Replikat vorhanden ist. Siehe binlog_expire_logs_seconds und expire_logs_days.
Replikat- und Quellsynchronisierungsprobleme beheben
Sie erhalten die Synchronisierungsprobleme, wenn das Replikat weit hinter der Quelle zurückgeblieben ist und die Replikation nicht wiederhergestellt werden kann.
Bevor Sie versuchen, eine Wiederherstellung nach diesem Fehler durchzuführen, sollten Sie unbedingt zuerst prüfen, warum der Fehler aufgetreten ist, und Korrekturmaßnahmen ergreifen.
MySQL-Shell verwenden
Verwenden Sie die Shell MySQL, um die Probleme bei der Replikat- und Quellsynchronisierung zu beheben.
- Die Quelle der eingehenden Replikation und das Replikat sind nicht mehr synchronisiert, das Replikat ist weit hinter der Quelle zurückgeblieben und die Replikation ist nicht wiederherstellbar.
Wenn die GTID-Werte der Quelle auf einen niedrigeren Wert als die Werte des Replikats zurückgesetzt werden, weil beispielsweise ein fehlerhaftes
reset master für die Quelle ausgegeben wurde, kann die eingehende Replikation nicht wiederhergestellt werden. Erstellen Sie in diesem Szenario das DB-System und die Konfiguration der eingehenden Replikation neu.