Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Fehlersuche bei MySQL-Endpunkten
Dieser Abschnitt enthält spezifische Replikationsszenarien für MySQL. AWS DMS scannt das MySQL-Binärlog regelmäßig, um Änderungen zu replizieren. Dieser Prozess kann die Latenz in den folgenden Szenarien erhöhen:
Lang laufende Transaktion in der Quelle
Da MySQL nur freigeschaltete Transaktionen in das Binärprotokoll schreibt, verursachen lang laufende Transaktionen Latenzspitzen, die proportional zur Abfrageausführungszeit sind.
Verwenden Sie die folgende Abfrage oder das Slow-Query-Protokoll, um lang laufende Transaktionen zu identifizieren:
SHOW FULL PROCESSLIST;
Informationen zur Verwendung des Slow-Query-Protokolls finden Sie unter The Slow Query Log
Strukturieren Sie Ihre Quelltransaktionen neu, um entweder die Abfrageausführungszeit zu verringern oder die Häufigkeit der Commits zu erhöhen und dadurch Latenzspitzen aufgrund lang laufender Transaktionen zu vermeiden.
Hoher Workload in der Quelle
Da es sich bei CDC in DMS um einen Single-Thread-Prozess handelt, kann eine große Anzahl von Transaktionen zu einer höheren Quelllatenz führen. Vergleichen Sie die Anzahl und Größe der während der Latenzzeit generierten Binärprotokolle mit den vor der Latenzzeit generierten Protokollen, um zu ermitteln, ob die Quelllatenz auf einen hohen Workload zurückzuführen ist. Verwenden Sie die folgenden Abfragen, um die Binärprotokolle und den Status des DMS-CDC-Threads zu überprüfen:
SHOW BINARY LOGS; SHOW PROCESSLIST;
Weitere Informationen zu den Status von CDC-Binärprotokoll-Dump-Threads finden Sie unter Replication Source Thread States
Sie können die Latenz ermitteln, indem Sie die letzte Binärprotokoll-Position, die in der Quelle generiert wurde, mit dem Ereignis vergleichen, das DMS gerade verarbeitet. Gehen Sie wie folgt vor, um das neueste Binärprotokoll der Quelle zu identifizieren:
Aktivieren Sie Debug-Protokolle für die Komponente SOURCE_CAPTURE.
Rufen Sie das Binärprotokoll zur DMS-Verarbeitung und die Positionsdetails aus den Debug-Protokollen der Aufgabe ab.
Verwenden Sie die folgende Abfrage, um das neueste Binärprotokoll der Quelle zu identifizieren:
SHOW MASTER STATUS;
Optimieren Sie den Wert für EventsPollInterval, um die Leistung weiter zu verbessern. Standardmäßig fragt DMS das Binärprotokoll alle 5 Sekunden ab. Sie können die Leistung jedoch verbessern, indem Sie diesen Wert reduzieren. Weitere Informationen zur EventsPollInterval-Einstellung finden Sie unter Endpunkteinstellungen bei Verwendung von MySQL als Quelle für AWS DMS.
Binärprotokoll-Konflikt
Für die Migration mehrerer Tabellen mit einer großen Datenmenge empfehlen wir, die Tabellen in separate Aufgaben für MySQL 5.7.2 oder höher aufzuteilen. In den MySQL-Versionen 5.7.2 und höher erzeugt der Master-Dump-Thread weniger Sperrkonflikte und verbessert den Durchsatz. Daher sperrt der Dump-Thread das Binärprotokoll nicht mehr, wenn er ein Ereignis liest. Dies bedeutet, dass mehrere Dump-Threads die Binärprotokolldatei gleichzeitig lesen können. Außerdem bedeutet dies, dass Dump-Threads das Binärprotokoll lesen können, während Clients darin schreiben. Weitere Informationen zu Dump-Threads finden Sie unter Replication Threads
Zum Verbessern der Replikationsleistung für MySQL-Quellversionen vor 5.7.2 sollten Sie versuchen, Aufgaben mit CDC-Komponenten zusammenzufassen.
