Warum schlug meine AWS DMS-CDC-Aufgabe mit „Error 1236“ fehl, als ich MySQL als Quelle verwendet habe?

Kurzbeschreibung

Mit AWS DMS kannst du einmalige Migrationen durchführen und laufende Änderungen replizieren, um Quellen und Ziele synchron zu halten. Um laufende Änderungen aus der Quelldatenbank zu lesen, verwendet AWS DMS Engine-spezifische API-Aktionen, um die Transaktionsprotokolle der Quell-Engine zu lesen. Wenn du MySQL als Quelle verwendest, liest AWS DMS-Änderungen aus den zeilenbasierten binären Protokollen (Binlogs). Anschließend migriert AWS DMS diese Änderungen zum Ziel.

Wenn es Probleme mit den binären Protokollen gibt, erhältst du die Meldung „Error 1236“. Stelle sicher, dass du alle binären Protokollierungsparameter korrekt konfigurierst, um AWS DMS CDC zu unterstützen, wenn du eine selbstverwaltete oder von AWS verwaltete MySQL-kompatible Datenbank verwendest.

Lösung

Um den „Error 1236“ zu beheben, ergreife auf der Grundlage der Fehlermeldung, die du erhältst, die folgenden Maßnahmen.

„Could not find first log file name in binary log index file reading binlog“

Beispielfehler aus den Aufgabenprotokollen:

[SOURCE_CAPTURE  ]I: Setting position in binlog 'mysql-bin-changelog.014448' at 119624570  (mysql_endpoint_capture.c:886)
[SOURCE_CAPTURE  ]I: Position was set in binlog 'mysql-bin-changelog.014448' at 119624570  (mysql_endpoint_capture.c:922)
[SOURCE_CAPTURE  ]E: Error 1236 (Could not find first log file name in binary log index file) reading binlog [1020493]
[TASK_MANAGER    ]I: Task - ABCDXXXXXXXXXXXXXX is in ERROR state, updating starting status to AR_NOT_APPLICABLE

Der vorherige Fehler tritt auf, wenn die MySQL-Quelldatenbank das binäre Protokoll entfernt hat, das AWS DMS verwendet, um Datenänderungen auf das Ziel zu replizieren. MySQL könnte das binäre Protokoll aus den folgenden Gründen entfernen:

• Die Aufbewahrungsfrist für binäre Protokolle ist zu niedrig.
• Die AWS DMS-Aufgabe steckt fest oder wurde aufgrund eines Problems gestoppt.

Um zu überprüfen, ob das binäre Protokoll verfügbar ist, führe den folgenden Befehl aus, um alle binären Protokolldateien aufzulisten:

mysql> SHOW BINARY LOGS;

Führe dann den folgenden Befehl aus, um die aktuelle binäre Protokolldatei und Position aufzulisten:

mysql> SHOW MASTER STATUS;

Weitere Informationen zu den vorherigen Befehlen findest du unter SHOW BINARY LOGS-Anweisung und SHOW MASTER STATUS-Anweisung auf der MySQL-Website.

Um den Fehler zu beheben, überprüfe die Aufbewahrungsdauer des binären Protokolls in der MySQL-Quelldatenbank. Erhöhe bei Bedarf die Aufbewahrungsfrist. Starte die AWS DMS-Aufgabe neu, um die Volllast-Phase erneut auszuführen.

Ergreife je nach Datenbanktyp die folgenden Maßnahmen.

Selbstverwaltete MySQL-Datenbanken

Um den Aufbewahrungszeitraum für binäre Protokolle On-Premises oder Amazon Elastic Compute Cloud (Amazon EC2) zu überprüfen, überprüfe den Wert von expire_logs_days. Weitere Informationen findest du auf der MySQL-Website unter expire logs days.

**Hinweis:**Es hat sich bewährt, den globalen Parameter der SET-Variablen auf 1 oder höher zu setzen. Weitere Informationen findest du unter SET-Syntax für die Variablenzuweisung auf der MySQL-Website.

Von AWS verwaltete MySQL-Datenbanken

Prüfe die Aufbewahrungszeiten für binäre Protokolle, die in einer Amazon Relational Database Service (Amazon RDS) für MySQL- oder Amazon Aurora MySQL-kompatiblen Edition-Datenbank festgelegt sind. Führe den folgenden Befehl aus:

mysql> call mysql.rds_show_configuration;

Führe den folgenden Befehl aus, um die Protokollspeicherung auf 24 Stunden zu erhöhen:

mysql> call mysql.rds_set_configuration('binlog retention hours', 24);

„Log event entry exceeded max_allowed_packet; increase max_allowed_packet on master...“

Beispielfehler aus den Aufgabenprotokollen:

[SOURCE_CAPTURE  ]I:  Position was set in binlog 'mysql-bin.056367' at 787323674  (mysql_endpoint_capture.c:922)
[SOURCE_CAPTURE  ]D:  net_safe_read error 1236 (log event entry exceeded max_allowed_packet; Increase max_allowed_packet on master; the first event 'mysql-bin.056367' at 787323674, the last event read from '/mnt/data/logs/mysql-bin.056367' at 123, the last byte read from '/mnt/data/logs/mysql-bin.056367' at 787323693.)  (mysql_endpoint_capture.c:1119)
[SOURCE_CAPTURE  ]I:  Error 1236 (log event entry exceeded max_allowed_packet; Increase max_allowed_packet on master; the first event 'mysql-bin.056367' at 787323674, the last event read from '/mnt/data/logs/mysql-bin.056367' at 123, the last byte read from '/mnt/data/logs/mysql-bin.056367' at 787323693.) reading binlog. Try reconnect  (mysql_endpoint_capture.c:1123)

Der vorherige Fehler kann aus folgenden Gründen auftreten:

• Eine Zeile enthält mehr Daten als der Wert des max_allowed_packet in der Quelle. Weitere Informationen findest du unter max allowed packet auf der MySQL-Website.
• Eine einzelne Transaktion enthält große Datenmengen oder es gibt mehrere Zeilenaktualisierungen in einer einzigen Transaktion.
• In der Quelldatenbank ist das binäre Protokoll beschädigt.

Wenn du binäre große Objekt-Spalten (Binary Large Object) oder lange Zeichenfolgen verwendest, setze den Wert max_allowed_packet auf das größte BLOB, das du verwendest. Dieser Parameter kann einen Wert von bis zu 1 GB haben. Weitere Informationen findest du unter Die BLOB- und TEXT-Typen auf der MySQL-Website.

Um den Umfang deiner größten Transaktion zu überprüfen, überprüfe deine binären Protokolle. Stelle sicher, dass die Transaktionsgröße die Größe des maximal zulässigen max_allowed_packet nicht überschreitet. Informationen zum Aufteilen einer großen Transaktion findest du unter Packet too large auf der MySQL-Website.

Wenn der Fehler weiterhin auftritt, liegt möglicherweise eine Beschädigung der binären Quell-Protokolle vor.

Gehe wie folgt vor, um die binären Protokolle auf Probleme zu überprüfen:

1. Führe den folgenden Befehl aus, um zu überprüfen, ob das binäre Protokoll existiert:

   mysql> SHOW BINARY LOGS;

2. Führe den folgenden Befehl aus, um die Ereignisse im binären Protokoll anzuzeigen:

   mysql> SHOW BINLOG EVENTS IN 'binlog file' FROM position;

   Hinweis: Ersetze die binäre Protokolldatei durch den Namen des binären Protokolls und Position durch die Position, an der das Ereignis auftritt.

3. Führe den folgenden Befehl aus, um die binären Protokolle herunterzuladen:

   shell> mysqlbinlog \
       --read-from-remote-server \
       --host=MySQLInstance1.cg034hpkmmjt.region.rds.amazonaws.com \
       --port=3306  \
       --user ReplUser \
       --password \
       --raw \
       --verbose \
       --result-file=/tmp/ \
       binlog.00098

4. Überprüfe das binäre Protokoll, das in der Fehlermeldung erwähnt wird, auf Beschädigungen.

5. Wenn das binäre Protokoll beschädigt ist, erstelle einen AWS-Supportfall.

„Binlog truncated in the middle of event; consider out of disk space on master...“

Beispielfehler aus den Aufgabenprotokollen:

[SOURCE_CAPTURE ]I: Read next binary log event failed; net_safe_read error 1236 (binlog truncated in the middle of event; consider out of disk space on master; the first event 'mysql-bin-changelog.017672' at 486, the last event read from '/rdsdbdata/log/binlog/mysql-bin-changelog.017672' at 125, the last byte read from '/rdsdbdata/log/binlog/mysql-bin-changelog.017672' at 4756.) (mysql_endpoint_capture.c:1069)
[SORTER ]I: Transaction consistency reached (sorter_transaction.c:347)
[TASK_MANAGER ]I: Starting replication now (replicationtask.c:2774)
[TASK_MANAGER ]I: Task - MGLVRIRUJH6FE2GP6F7SW46BPBW6YKF2JUJPSVY is in RUNNING state, updating starting status to AR_RUNNING (repository.c:5110)

Der vorherige Fehler kann aus folgenden Gründen auftreten:

• Es gibt einen sync_binlog != 1 auf dem primären Server. Dies bedeutet, dass binäre Protokollereignisse möglicherweise nicht auf der Festplatte synchronisiert werden. Weitere Informationen findest du unter binäres Protokoll synchronisieren auf der MySQL-Website.
• In der Quelldatenbank ist das binäre Protokoll beschädigt.

Um diesen Fehler zu beheben, stelle sicher, dass der Wert des Parameters sync_binlog in der Quelle auf 1 gesetzt ist. Starte anschließend die Aufgabe erneut.

Wenn der Parameter sync_binlog bereits auf 1 gesetzt ist, überprüfe das binäre Protokoll auf Beschädigungen. Eine Anleitung dazu findest du im vorherigen Abschnitt „Log event entry exceeded max_allowed_packet; increase max_allowed_packet on master...“.

„Client requested master to start replication from impossible position“

Beispielfehler aus den Aufgabenprotokollen:

[SOURCE_CAPTURE  ]I:  Position was set in binlog 'mysql-bin-changelog.007989' at 1631  (mysql_endpoint_capture.c:922)
[SOURCE_CAPTURE  ]I:  Read next binary log event failed; net_safe_read error 1236 (Client requested master to start replication from impossible position; the first event 'mysql-bin-changelog.007989' at 1631, the last event read from 'mysql-bin-changelog.007989' at 4, the last byte read from 'mysql-bin-changelog.007989' at 4.)  (mysql_endpoint_capture.c:1053)
[SOURCE_CAPTURE  ]D:  Error reading binary log. [1020493]  (mysql_endpoint_capture.c:3995)
[SOURCE_CAPTURE  ]E:  Error 1236 (Client requested master to start replication from impossible position; the first event 'mysql-bin-changelog.007989' at 1631, the last event read from 'mysql-bin-changelog.007989' at 4, the last byte read from 'mysql-bin-changelog.007989' at 4.) reading binlog events [1020493]  (mysql_endpoint_capture.c:1074)

Dieser Fehler tritt auf, wenn der MySQL-Quelldatenbankserver unerwartet stoppt. Ein unerwarteter Stopp kann aufgrund eines Hardwarefehlers wie eines Festplattenfehlers oder eines Stromausfalls auftreten.

Um diesen Fehler zu beheben, führe je nach AWS-DMS-Aufgabentyp eine der folgenden Aktionen aus:

• Starte für Volllast- und CDC-Aufgaben die AWS DMS-Aufgabe neu.
• Für reine CDC-Aufgaben startet die AWS DMS-Aufgabe von der nächsten binären Protokollposition aus.

„Client requested master to start replication from position > file size“

Beispielfehler aus den Aufgabenprotokollen:

[SOURCE_CAPTURE  ]I:  Position was set in binlog 'binlog.000012' at 2179  (mysql_endpoint_capture.c:922)
[SOURCE_CAPTURE  ]I:  Read next binary log event failed; net_safe_read error 1236 (Client requested master to start replication from position > file size)  (mysql_endpoint_capture.c:1052

Dieser Fehler kann aufgrund verschlüsselter binärer Protokolle auftreten. Wenn in deiner MySQL-Quelldatenbank MySQL Version 8.0 ausgeführt wird und du die binäre Protokolle verschlüsselst, kann AWS DMS die Protokolle bei der Aufgabeninitialisierung nicht lesen. Daher protokolliert AWS DMS diesen Fehler. Wenn du die binäre Protokollverschlüsselung aktivierst, kannst du keine CDC-Replikation verwenden, die MySQL 8.0 als Quelle verwendet. Weitere Informationen findest du unter Verschlüsseln von binären Protokolldateien und Relay-Protokolldateien auf der MySQL-Website.

Gehe wie folgt vor, um dieses Problem zu beheben:

1. Führe den folgenden Befehl aus, um die MySQL-Version zu überprüfen:

   mysql> SELECT VERSION();

2. Führe den folgenden Befehl aus, um zu überprüfen, ob binlog_encryption EIN ist:

   mysql> SELECT * FROM performance_schema.global_variables WHERE VARIABLE_NAME = 'binlog_encryption';

3. Führe den folgenden Befehl aus, um binlog_encryption zu deaktivieren:

   mysql> SET GLOBAL binlog_encryption = OFF;

   -oder-
   Starte die AWS DMS-Aufgabe mit deaktivierter binlog_encryption und führe dann den folgenden Befehl aus, um binlog_encryption zu aktivieren:

   mysql> SET GLOBAL binlog_encryption = ON;

Ähnliche Informationen

Wie behebe ich Fehler bei der binären Protokollierung, die ich erhalte, wenn ich AWS DMS mit Aurora MySQL-Compatible als Quelle verwende?