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.
# Behebung von Verzögerungen bei der Replikation von Binärprotokollen für Aurora MySQL
Dieser Abschnitt enthält Anleitungen zur Verzögerung der binären Log-Replikation für Aurora MySQL, das als binäres Log-Replikat konfiguriert ist. Er behandelt die Replikationsarchitektur, die parallele Replikation, die Nachverfolgung von Abhängigkeiten, die Überwachung und bewährte Methoden zur Konfiguration.
Bei der binären Protokollreplikation werden Daten zwischen MySQL-compatible Datenbanken repliziert. Die in diesem Abschnitt behandelte Binärprotokollreplikation ist asynchron: Die Quelle wartet nicht, bis die Replikate die Anwendung der Änderungen bestätigen, bevor sie Transaktionen festschreibt. Dies gilt nicht für die halbsynchrone Replikation. Bei der halbsynchronen Replikation wartet die Quelle, bis mindestens ein Replikat den Empfang der Transaktion bestätigt, bevor sie den Commit durchführt. Beispielsweise verwenden Multi-AZ DB-Cluster für Amazon RDS for MySQL die halbsynchrone Replikation, was in diesem Abschnitt nicht behandelt wird. Das Replikat unterhält über den I/O Thread eine persistente Verbindung zur Quelle, um binäre Protokollereignisse kontinuierlich zu streamen. Dieser Abschnitt gilt für alle Binlog-Replikationstopologien, bei denen Aurora MySQL das Replikat ist. Die Quelle kann ein anderer Aurora MySQL-Cluster, Amazon RDS für MySQL, lokales MySQL oder MySQL auf Amazon EC2 sein. Dieser Abschnitt gilt auch, wenn Aurora MySQL die Quelle ist, die auf ein beliebiges Ziel repliziert. MySQL-compatible
**Anmerkung**
Für Anwendungsfälle der regionsübergreifenden Replikation sollten Sie die Verwendung [Verwenden von Amazon Aurora Global Database](aurora-global-database.md) als Alternative zur binären logbasierten Replikation in Betracht ziehen. Aurora Global Database verwendet eine dedizierte Infrastruktur für die Replikation, die eine geringere Latenz bietet und weniger Betriebsmanagement erfordert als die regionsübergreifende binäre Protokollreplikation.
**Erleben Sie gerade einen Anstieg der Verzögerungen? ** Überspringen Sie das Hintergrundmaterial und stellen Sie zunächst fest, ob der I/O Thread oder der SQL-Thread der Engpass ist. Folgen Sie dann dem Link für dieses Szenario: [Problembehandlung bei I/O Threadverzögerungen](#aurora-mysql-replication-lag-io-thread) oder. [Identifizierung des Engpasses bei der Replikationsverzögerung](#aurora-mysql-replication-lag-identifying) [Behebung von SQL-Thread-Verzögerungen](#aurora-mysql-replication-lag-sql-thread)
**Topics**
+ [MySQL-Replikationsarchitektur](#aurora-mysql-binlog-replication-lag-overview)
+ [Identifizierung des Engpasses bei der Replikationsverzögerung](#aurora-mysql-replication-lag-identifying)
+ [Problembehandlung bei I/O Threadverzögerungen](#aurora-mysql-replication-lag-io-thread)
+ [Behebung von SQL-Thread-Verzögerungen](#aurora-mysql-replication-lag-sql-thread)
+ [Multi-threaded Replikation (MTR)](#aurora-mysql-replication-lag-mtr)
+ [Aurora-specific Optimierungen bei der Replikation](#aurora-mysql-replication-lag-aurora-optimizations)
+ [Überwachung der parallelen Replikation](#aurora-mysql-replication-lag-monitoring)
+ [Bewährte Methoden zur Minimierung von Verzögerungen bei der Replikation](#aurora-mysql-replication-lag-best-practices)
## MySQL-Replikationsarchitektur
Die MySQL-Replikation wird über spezielle Threads implementiert:
+ **Binärer Log-Dump-Thread (Quelle) ** — Wird erstellt, wenn ein Replikat eine Verbindung herstellt. Sendet den Inhalt des Binärlogs an das Replikat. Sichtbar `SHOW PROCESSLIST` als „Binlog Dump“ -Thread.
+ ** I/O Replikationsthread (Replikat) ** — Stellt eine Verbindung zur Quelle her und fordert Binärprotokollaktualisierungen an. Schreibt sie in das Relay-Log des Replikats. Immer ein einzelner Thread pro Replikationskanal, unabhängig von der Konfiguration der Multithread-Replikation (MTR).
+ **Replikations-SQL-Thread (Replikat) ** — Liest das Relay-Protokoll und wendet Transaktionen an. Der Applier besteht immer aus einem Koordinator-Thread, der Transaktionen aus dem Relay-Log liest, sowie aus N Worker-Threads, die sie anwenden, wobei N der Wert von ist. `replica_parallel_workers` Bei `replica_parallel_workers=1` wendet der einzelne Worker Transaktionen sequentiell an. Mit `replica_parallel_workers >= 2` weist der Koordinator mehreren Worker-Threads unabhängige Transaktionen zur parallelen Anwendung zu.
**Anmerkung**
`replica_parallel_workers=0`Die Einstellung ist ab MySQL 8.0.30 veraltet und kann in einer zukünftigen MySQL-Version entfernt werden. Verwenden Sie stattdessen `replica_parallel_workers=1` für Singlethread-Anwendungen.
Der Replikationsvorgang funktioniert wie folgt:
1. Die Quelle führt DML-, DCL- oder DDL-Anweisungen aus.
1. Beim Commit schreibt die Quelle die Daten in das Binärlog.
1. Der I/O Thread auf dem Replikat ruft Ereignisse ab und schreibt sie in das Relay-Log.
1. Der SQL-Thread wendet Änderungen aus dem Relay-Log an (Single-Threading oder Multi-Threading).
## Identifizierung des Engpasses bei der Replikationsverzögerung
Verzögerungen bei der Replikation können in zwei Bereichen auftreten: im I/O Thread oder im SQL-Thread. Der erste Schritt besteht darin, festzustellen, welche Komponente verzögert ist.
**Anmerkung**
Das `Seconds_Behind_Source` Feld in `SHOW REPLICA STATUS` misst die Verzögerung zwischen dem Zeitpunkt, an dem ein Ereignis in der Quelle protokolliert wurde, und dem Zeitpunkt, zu dem der SQL-Thread es anwendet. Diese Metrik gibt nicht speziell die Verzögerung des I/O Threads an. Um I/O Thread-Lag zu identifizieren, müssen Sie die Binärlogpositionen vergleichen, wie in den folgenden Schritten beschrieben.
**Anmerkung**
Einige MySQL-Befehle und interne Zeichenketten, die in diesem Abschnitt beschrieben werden`SHOW MASTER STATUS`, verwenden z. B. veraltete Terminologie. In dieser Dokumentation werden durchgehend die bevorzugten Begriffe „Quelle“ und „Replikat“ verwendet.
**Um festzustellen, welcher Replikations-Thread verzögert ist**
1. Führen Sie auf dem Replikat`Source_Log_File`/`Read_Source_Log_Pos`(I/O Thread-Position) aus `SHOW REPLICA STATUS` und vergleichen Sie es mit`File`/`Position`from in `SHOW MASTER STATUS` der Quelle. Wenn sich diese signifikant unterscheiden (>50 MB oder >1 Binlog-Datei auseinander), hinkt der I/O Thread hinterher.
1. Vergleichen Sie die I/O Thread-Position mit der SQL-Thread-Position (/). `Relay_Source_Log_File` `Exec_Source_Log_Pos` Wenn der I/O Thread aufgeholt ist, der SQL-Thread aber im Rückstand ist (>50 MB Abstand), ist der SQL-Thread der Engpass.
**Schnelle erste Bewertung anhand von Daten, die nur aus Replikaten stammen**
Sie können eine erste Bewertung nur anhand von Daten auf der Replikatseite durchführen. Führen Sie den `SHOW REPLICA STATUS` Vorgang zweimal im Abstand von 1—2 Minuten durch und beachten Sie dabei Folgendes:
Wenn der SQL-Thread `Read_Source_Log_Pos` voranschreitet, aber `Exec_Source_Log_Pos` ins Stocken gerät oder viel langsamer voranschreitet, ist der SQL-Thread der Engpass (Szenario B). Fahren Sie mit [Behebung von SQL-Thread-Verzögerungen](#aurora-mysql-replication-lag-sql-thread) fort.
Wenn beide `Read_Source_Log_Pos` während des Wachstums ins `Exec_Source_Log_Pos` Stocken geraten, `Seconds_Behind_Source` ist der I/O Thread wahrscheinlich im Rückstand. Bevor Sie Änderungen an der Konfiguration vornehmen, überprüfen Sie dies, indem Sie die Replikatpositionen mit der Quelle vergleichen. Gehen Sie dabei `SHOW MASTER STATUS` wie in Schritt 1 des vorherigen Verfahrens beschrieben vor.
| Szenario | I/O Thread gegen Quelle | SQL-Thread gegen I/O Thread | Engpass |
| --- | --- | --- | --- |
| A | Weit dahinter (>50 MB) | Schliessen (<10 MB) | I/O Gewinde |
| B | Schließen (<10 MB) | Schließen (50 MB) | SQL-Thread |
| C | Weit dahinter | Weit dahinter | Beides (beginne mit I/O) |
**Example Interpretieren von Binärlogpositionen**
Das folgende Beispiel zeigt, wie Binärlogpositionen verglichen werden, um den Engpass zu ermitteln.
Gibt auf dem Replikat Folgendes zurück: `SHOW REPLICA STATUS`
```
Source_Log_File: mysql-bin.000045
Read_Source_Log_Pos: 524288000
Relay_Source_Log_File: mysql-bin.000045
Exec_Source_Log_Pos: 524200000
```
Gibt in der Quelle Folgendes `SHOW MASTER STATUS` zurück:
```
File: mysql-bin.000045
Position: 1073741824
```
Um die I/O Thread-Verzögerung zu ermitteln, subtrahieren Sie die I/O Threadposition von der Quellposition:
(1073741824 − 524288000)/1048576 = ** 524 MB ** — Der Thread befindet sich weit hinter der Quelle (Szenario A). I/O
Um die SQL-Thread-Verzögerung zu ermitteln, subtrahieren Sie die SQL-Thread-Position von der Thread-Position: I/O
(524288000 − 524200000)/1048576 = ** 0,08 MB ** — Der SQL-Thread hält mit dem Thread Schritt. I/O
Konzentrieren Sie sich in diesem Fall auf die Problembehandlung auf den Thread. I/O Weitere Informationen finden Sie unter [Problembehandlung bei I/O Threadverzögerungen](#aurora-mysql-replication-lag-io-thread).
**Anatomie einer Verzögerung bei der Replikation**
Ein häufiges Muster ist ein plötzlicher Anstieg, `Seconds_Behind_Source` gefolgt von einer schnellen Rückkehr auf nahe Null. Dies tritt auf, wenn die Ausführung einer DML mit langer Laufzeit auf der Quelle (z. B. ein UPDATE, das Millionen von Zeilen scannt, aber nur wenige ändert) Minuten dauert. Bei der ROW-based Binärprotokollierung werden nur die geänderten Zeilen in das Binärlog geschrieben. Wenn der SQL-Thread dieses Ereignis erkennt, berechnet er die Verzögerung auf der Grundlage der Startzeit der Transaktion an der Quelle. Dadurch entsteht ein großer Anfangswert. Da jedoch nur wenige Zeilen angewendet werden müssen, holt das Replikat schnell auf. Dies ist ein erwartetes Verhalten und weist nicht auf ein anhaltendes Replikationsproblem hin.
## Problembehandlung bei I/O Threadverzögerungen
Der I/O Thread ist dafür verantwortlich, binäre Protokollereignisse von der Quelle abzurufen und sie in das Relay-Log zu schreiben. Häufige Ursachen und Lösungen:
| Ursache | Wie identifiziere ich | Auflösung |
| --- | --- | --- |
| Einschränkungen der Netzwerkbandbreite | Prüfen CloudWatch NetworkReceiveThroughput/NetworkTransmitThroughput | Verwenden Sie Instances mit höherer Netzwerkkapazität; achten Sie auf ähnliche Instance-Klassen in Quelle und Replikat |
| Netzwerklatenz (regionsübergreifend oder lokal) | Geografische Entfernung zwischen Quelle und Replikat; hohe Round-Trip-Zeit | Verwenden Sie diese Option für lokale Quellen, um dedizierte Konnektivität mit niedriger Latenz zu gewährleisten |
| Ressourcenbeschränkungen an der Quelle | Hohe CPU (CPUUtilization), Speicherauslastung (FreeableMemory) | Skalieren Sie die Quellinstanz hoch. Jedes verbundene Replikat erstellt einen Binlog-Dump-Thread auf der Quelle. Reduzieren Sie die Anzahl der verbundenen Replikate, wenn die Quelle nur über begrenzte Ressourcen verfügt. |
| Große Transaktionen mit Daten BLOB/TEXT | Überwachen Sie die Größe von binären Log-Ereignissen anhand einer SumBinaryLogSize CloudWatch Metrik | Setzenbinlog\_row\_image=noblob; aktiviert die binäre Log-Transaktionskomprimierung (binlog\_transaction\_compression=ON). Testen Sie zuerst außerhalb der Produktion — die Komprimierung erhöht die CPU-Auslastung sowohl in der Quelle als auch im Replikat. |
| Speicherlimit für Relay-Logs erreicht | Replica\_IO\_Statezeigt „Es wird darauf gewartet, dass der Replikat-SQL-Thread genügend Speicherplatz für das Relay-Protokoll freigibt“ | Dies bedeutet, dass der SQL-Thread die Hauptursache ist, nicht der I/O Thread. Beheben Sie zuerst die Verzögerung des SQL-Threads. In Aurora MySQL relay\_log\_space\_limit ist die Standardeinstellung ungefähr 953 MiB. Diese Nachricht ist Teil des normalen Betriebs, wenn der SQL-Thread Änderungen nicht schnell genug anwenden kann. Diese Meldung weist nicht unbedingt auf ein I/O Thread-Leistungsproblem hin. |
### Optimierungsstrategien für I/O Thread-Lag
1. **Verwenden Sie mindestens dieselbe Instanzklasse wie die Quelle ** — Dieser Ansatz bietet ausreichend CPU, Arbeitsspeicher, I/O Kapazität und Netzwerkbandbreite.
1. **Sorgen Sie für eine ausreichende Netzwerkbandbreite ** — Verwenden Sie Instances mit hoher Netzwerkkapazität. Bei lokalen Quellen sollten Sie eine dedizierte Bandbreite und ein konsistenteres Netzwerkerlebnis in Betracht ziehen.
1. **Überprüfen Sie die quellseitigen Ressourcen, insbesondere bei vielen Replikaten ** — Überwachen Sie die CPU, den Arbeitsspeicher, das Netzwerk und das Binlog der Quelle. I/O Jedes verbundene Replikat fügt der Quelle einen Binlog-Dump-Thread hinzu, sodass eine Quelle, die viele Replikate bedient, selbst zum Engpass werden kann. Wir empfehlen, vor der Skalierung des Replikats zu überprüfen, ob die Quelle nicht gesättigt ist. Wenn die Quelle nur über begrenzte Ressourcen verfügt, sollten Sie erwägen, die Anzahl der verbundenen Replikate zu reduzieren.
1. **Stellen Sie sicher, dass der I/O Aurora-Binlog-Cache aktiv ist ** — Der I/O Binlog-Cache reduziert den Speicherplatz I/O auf der Quelle, um binäre Protokollereignisse zu verarbeiten. In Aurora MySQL Version 2.10 und höher wird er automatisch aktiviert — eine Konfiguration ist nicht erforderlich. Wenn es sich bei der Quelle um einen Aurora-Cluster handelt, stellen Sie sicher, dass der Cache mit `SHOW GLOBAL STATUS LIKE 'aurora_binlog_io_cache%'` verwendet wird. Weitere Informationen finden Sie unter [Optimieren einer Binlog-Replikation](binlog-optimization.md#binlog-optimization-binlog-io-cache).
1. **Binärlog-Transaktionskomprimierung aktivieren ** — `binlog_transaction_compression=ON` In der Parametergruppe festgelegt. Reduziert die Bandbreitenanforderungen. Bei dieser Einstellung sind die folgenden Aspekte zu berücksichtigen:
+ Die Komprimierung erhöht die CPU-Auslastung sowohl auf der Quelle als auch auf dem Replikat.
+ Testen Sie zuerst in einer Umgebung ohne Produktion, um das optimale Gleichgewicht zwischen Komprimierung und Ressourcenauslastung zu finden.
+ Passen Sie den Komprimierungsgrad optional mit `binlog_transaction_compression_level_zstd` (Standard: 3, Bereich: 1—22) an.
1. **Schreibvorgänge in Binärprotokolle minimieren ** — Legt fest`binlog_row_image=noblob`, dass BLOB/TEXT Daten aus Binärprotokollen entfernt werden. Nicht verwenden, wenn das Replikat Trigger hat, die auf BLOB-Spalten verweisen. Weitere Informationen finden Sie unter [https://dev.mysql.com/doc/refman/8.0/en/replication-options-binary-log.html#sysvar_binlog_row_image](https://dev.mysql.com/doc/refman/8.0/en/replication-options-binary-log.html#sysvar_binlog_row_image) binlog\_row\_image auf der MySQL-Website.
1. **Implementieren Sie Replikationsfilter in der Quelle ** — Verwenden Sie `binlog-do-db` oder `binlog-ignore-db` schließen Sie unnötige Datenbanken aus. Dies sind statische Parameter, die einen Neustart erfordern.
**Wichtig**
Source-side Filter wirken sich vollständig darauf aus, was in Binärprotokolle geschrieben wird. Ausgeschlossene Datenbanken werden nicht in ein Downstream-Replikat repliziert. Handelt es sich bei der Quelle um eine selbstverwaltete MySQL-Instance (lokal oder auf Amazon EC2), sind ausgeschlossene Datenbanken auch nicht für die Point-in-Time-Wiederherstellung auf Binärprotokollbasis verfügbar. Amazon RDS for MySQL unterstützt keine quellseitige Binlogfilterung (`binlog-do-db`/`binlog-ignore-db`sind nicht konfigurierbar); verwenden Sie stattdessen replikatseitige Replikationsfilter. Aurora verwendet das Cluster-Volume für PITR und ist nicht von binären Logfiltern für Backup-Zwecke betroffen.
## Behebung von SQL-Thread-Verzögerungen
Der SQL-Thread ist der Engpass, wenn der I/O Thread die Quelle eingeholt hat, aber `Seconds_Behind_Source` wächst. Um die Verzögerung zu quantifizieren, sollten Sie die Überwachung über einen Zeitraum von 15 Minuten durchführen. Vergleichen Sie die Binlog-Generierungsrate auf der Quelle (das `Position` Delta von`SHOW MASTER STATUS`) mit der SQL-Thread-Anwendungsrate auf dem Replikat (das `Exec_Source_Log_Pos` Delta).
Häufige Ursachen und Lösungen:
| Ursache | Wie identifiziere ich | Auflösung |
| --- | --- | --- |
| Single-threaded Replikation | SELECT @@global.replica\_parallel\_workers;gibt 0 oder 1 zurück | Aktivieren Sie Multithread-Replikation (MTR) mit WRITESET-Abhängigkeitsverfolgung. MTR allein löst Verzögerungen nicht auf, wenn es häufig zu Uhrenkonflikten kommt. Informationen [Verfolgung der Abhängigkeiten von der Quelle](#aurora-mysql-replication-lag-mtr-dependency) zur Optimierung der Nachverfolgung von Abhängigkeiten und [Fehlerprotokoll für Multithread-Replikatstatistiken](#aurora-mysql-replication-lag-monitoring-error-log) zur Identifizierung von Uhrkonflikten finden Sie unter. |
| Fehlende Primärschlüssel | Ohne Primärschlüssel (oder eindeutigen Schlüssel mit NOT NULL) führt das Replikat bei UPDATE- und DELETE-Vorgängen einen vollständigen Tabellenscan für jede geänderte Zeile durch. Verwenden Sie die folgende Abfrage, um Tabellen ohne Primärschlüssel zu identifizieren: SELECT t.table_schema, t.table_name
FROM information_schema.tables t
LEFT JOIN information_schema.table_constraints tc
ON t.table_schema = tc.table_schema
AND t.table_name = tc.table_name
AND tc.constraint_type = 'PRIMARY KEY'
WHERE tc.constraint_type IS NULL
AND t.table_type = 'BASE TABLE'
AND t.table_schema NOT IN ('information_schema', 'mysql', 'performance_schema', 'sys')
ORDER BY 1;
| Fügen Sie allen replizierten Tabellen Primärschlüssel hinzu. Wenn das Hinzufügen expliziter Primärschlüssel nicht sofort möglich ist, sollten Sie erwägen, Generated Invisible Primary Keys (GIPK) zu aktivieren, indem Sie den sql\_generate\_invisible\_primary\_key Parameter auf ON (verfügbar in Aurora MySQL 3-Versionen, die auf MySQL 8.0.30 und höher basieren) setzen. Weitere Informationen zu generierten unsichtbaren Primärschlüsseln finden Sie unter [ Generierte unsichtbare Primärschlüssel ](https://dev.mysql.com/doc/refman/8.0/en/create-table-gipks.html) auf der MySQL-Website. |
| Große Schreibtransaktionen an der Quelle | Eine Transaktion, die viele Zeilen ändert (z. B. ein Bulk-UPDATE oder DELETE), repliziert als eine Einheit, die unabhängig von der MTR-Konfiguration nur von einem Worker-Thread angewendet werden kann. Identifizieren Sie in der Quelle aktive, lang andauernde Schreibtransaktionen mit: SELECT trx_id, trx_started, trx_rows_modified, trx_query
FROM information_schema.innodb_trx
WHERE trx_rows_modified > 10000
ORDER BY trx_started;
Auf dem Replikat ist ein Worker mit derselben Anweisung beschäftigt, SHOW PROCESSLIST während die anderen untätig sind. Long-running Transaktionen im Leerlauf oder Transaktionen, die auf Sperren in der Quelle warten, verursachen an sich keine Verzögerung bei der Replikation. Nur das zugeschriebene Schreibvolume ist von Bedeutung, da Ereignisse das Binärlog zum Zeitpunkt des Commits erreichen. | Teilen Sie Massenvorgänge in kleinere Transaktionen auf (z. B. einige tausend Zeilen pro Commit), damit das Replikat sie parallel anwenden kann. Ein funktionierendes Beispiel finden Sie unter[Beispiel 4: Eine einzelne große Transaktion kann nicht parallelisiert werden](#aurora-mysql-replication-lag-monitoring-example4). |
| DDL-Vorgänge | DDL blockiert andere Replikationsereignisse | Verwenden Sie ein Online-Tool zur Schemaänderung oder verwenden Sie Blue/Green Bereitstellungen. Planen Sie DDL in Zeiten mit geringem Verkehrsaufkommen ein. Weitere Informationen finden Sie unter [ Percona Toolkit ](https://docs.percona.com/percona-toolkit/) auf der Percona-Website. pt-online-schema-change Siehe gh-ost [https://github.com/github/gh-ost](https://github.com/github/gh-ost) gh-ost auf der Website. GitHub |
| Suboptimale Konfiguration der parallelen Replikation | Niedrige Auslastung der Mitarbeiter; hohe Taktkonflikte in den Koordinatorstatistiken. Überprüfen Sie das Feld „Um die Uhr auf Konflikte gewartet“ im Fehlerprotokolleintrag für Multithread-Replikatstatistiken (siehe[Fehlerprotokoll für Multithread-Replikatstatistiken](#aurora-mysql-replication-lag-monitoring-error-log)). Hohe Werte im Verhältnis zu „verstrichenen Sekunden“ deuten darauf hin, dass Transaktionen häufig durch Abhängigkeiten blockiert werden. | Optimieren Sie das Abhängigkeits-Tracking (WRITESET) und die Anzahl der Worker |
| Ressourcenkonflikte aufgrund analytischer Arbeitslasten | Komplexe OLAP-Abfragen konkurrieren mit SQL-Threads um Ressourcen (CPU, Arbeitsspeicher) | Trennen Sie analytische Workloads auf dedizierte Replikate |
| Veraltete Tabellenstatistiken | Suboptimale Abfragepläne für das Replikat. Verwenden Sie die folgende Abfrage, um Tabellen mit veralteten Statistiken (älter als 7 Tage) zu identifizieren: SELECT database_name, table_name,
MIN(last_update) AS oldest_stat_update,
DATEDIFF(NOW(), MIN(last_update)) AS stats_age_in_days
FROM mysql.innodb_index_stats
WHERE database_name NOT IN ('mysql', 'sys')
GROUP BY database_name, table_name
HAVING stats_age_in_days > 7
ORDER BY stats_age_in_days DESC;
| Führen Sie ANALYZE TABLE regelmäßig Tabellen mit veralteten Statistiken aus |
### Reduzieren Sie den Arbeitsaufwand bei der Anwendung mit replikatseitigen Replikationsfiltern
Aurora MySQL Version 3.01.0 und höher unterstützt replikatseitige Replikationsfilter. Verwenden Sie diese, um irrelevante Datenbanken oder Tabellen bei der Anwendung zu überspringen und so die Arbeitslast des SQL-Threads zu reduzieren. Replica-side Filter werden vom SQL-Thread angewendet — der I/O Thread ruft trotzdem alle binären Log-Ereignisse von der Quelle ab, sodass diese Filter nur die Anwendungsarbeit reduzieren, nicht die Netzwerkübertragung. Im Gegensatz zu quellseitigen Filtern (die nur auf Datenbankebene funktionieren) unterstützen replikatseitige Filter die Granularität auf Tabellenebene mithilfe von und. `replicate-do-table` `replicate-ignore-table` Weitere Informationen finden Sie unter [Konfigurieren von Replikationsfiltern mit Aurora MySQL](AuroraMySQL.Replication.Filters.md).
## Multi-threaded Replikation (MTR)
Bei MTR wendet das Replikat unabhängige Transaktionen parallel an. Es kann eine einzelne große Transaktion nicht in parallele Teile aufteilen. Der Grad der Parallelität wird durch die von der Quelle geschriebenen Abhängigkeitsinformationen begrenzt.
Wenn MTR aktiviert ist (`replica_parallel_workers >= 2`), wird der SQL-Applier in einen ** Koordinator-Thread ** und mehrere Worker-Threads aufgeteilt. ** ** Der Koordinator liest Transaktionen aus dem Relay-Log. Er untersucht die logischen Zeitstempel (`last_committed`und`sequence_number`), die die Quelle in jede Transaktion einbettet. Anschließend weist es den verfügbaren Worker-Threads unabhängige Transaktionen zur parallelen Ausführung zu. Zwei Transaktionen sind unabhängig, wenn sie keine gemeinsamen Datenabhängigkeiten haben — das heißt, wenn sie unterschiedliche Zeilen ändern. Die Quelle ermittelt diese Abhängigkeiten zum Zeitpunkt der Übertragung mithilfe der konfigurierten Methode zur Nachverfolgung von Abhängigkeiten und zeichnet sie im Binärlog auf. Das Replikat kann die Parallelität nicht über das hinaus erhöhen, was die Quelle zulässt.
### MTR ist die empfohlene Standardeinstellung
Wir empfehlen, Replikate mit aktivierter MTR auszuführen. MTR ist in MySQL 8.0.27 und höher standardmäßig aktiviert (`replica_parallel_workers=4`), einschließlich der Aurora MySQL 3-Versionen, die auf diesen Versionen basieren. In früheren Versionen (Aurora MySQL 2.12.1 und höher oder Versionen, die auf MySQL-Versionen vor 8.0.27 basieren), aktivieren Sie es explizit, indem Sie es auf einen Wert von 2 oder mehr `replica_parallel_workers` setzen. Wenn Parallelität nicht verfügbar ist, kostet es wenig, MTR aktiviert zu lassen, und das Replikat kann sie nutzen, wann immer es die Arbeitslast zulässt.
MTR reduziert die Verzögerung in den folgenden Fällen nicht:
+ Der Engpass ist der I/O Thread (network/bandwidth Problem).
+ Die Verzögerung wird durch eine einzelne Transaktion mit langer Laufzeit verursacht.
+ Die Replik ist CPU-saturated (mehr Threads machen es noch schlimmer).
+ Tabellen haben keine Primärschlüssel (erzwingt vollständige Tabellenscans, wodurch Parallelität zunichte gemacht wird).
### Verfolgung der Abhängigkeiten von der Quelle
Die Quelle bestimmt mithilfe des `binlog_transaction_dependency_tracking` Parameters, welche Transaktionen parallel angewendet werden können. Empfohlener Wert:`WRITESET`.
+ **COMMIT\_ORDER ** — Verfolgt Abhängigkeiten auf der Grundlage des Commit-Timings. Funktioniert am besten bei hoher Parallelität und großen Gruppen-Commits. Eingeschränkte Parallelität in Umgebungen mit geringer Parallelität.
+ **WRITESET (empfohlen) ** — Verfolgt die tatsächlichen Datenabhängigkeiten auf Zeilenebene. Die Leistung ist immer mindestens so gut wie die von COMMIT\_ORDER. Deutlich besser bei Workloads mit geringer Parallelität. Erfordert, dass Tabellen Primärschlüssel haben.
Die WRITESET-Abhängigkeitsverfolgung erzeugt in den folgenden Fällen leere oder teilweise Schreibsätze (was die Parallelität einschränkt):
+ Tabellen ohne primäre oder eindeutige Schlüssel
+ DDL-Anweisungen (CREATE TABLE, ALTER TABLE usw.)
+ Transaktionen, die übergeordnete Tabellen in Fremdschlüsselbeziehungen ändern
Darüber hinaus wird der Abhängigkeitsverlauf gelöscht, wenn das Binärlog rotiert oder wenn das `binlog_transaction_dependency_history_size` Limit erreicht wird, wodurch die Parallelität vorübergehend reduziert wird.
+ **WRITESET\_SESSION ** — Wie WRITESET mit der zusätzlichen Einschränkung, dass Transaktionen aus derselben Sitzung nicht parallelisiert werden können.
**Anmerkung**
MySQL 8.4 hat WRITESET entfernt `binlog_transaction_dependency_tracking` und verwendet standardmäßig WRITESET (nicht konfigurierbar). Frühere Versionen verwenden standardmäßig COMMIT\_ORDER.
### Paralleler Typ (replica\_parallel\_type) ``
Der `replica_parallel_type` Parameter bestimmt, wie Transaktionen auf die Worker-Threads verteilt werden. Es gibt zwei Optionen:
+ **LOGICAL\_CLOCK (empfohlen) ** — Ermittelt anhand logischer Zeitstempel, welche Transaktionen parallel ausgeführt werden können, auch innerhalb derselben Datenbank. Dieser Ansatz führt bei den meisten Workloads zu einem höheren Replikationsdurchsatz und einer geringeren Latenz. Verwenden Sie ihn, es sei denn, Sie haben einen bestimmten Workload mit mehreren Datenbanken, der nicht davon profitiert.
+ **DATENBANK ** — Weist Transaktionen Worker-Threads zu, basierend auf der Datenbank, auf die sie sich auswirken. Ziehen Sie dies nur in Betracht, wenn Ihre Anwendung mehrere Datenbanken mit klar getrennten Arbeitslasten verwendet und Transaktionen selten Datenbankgrenzen überschreiten. Wenn Sie DATABASE verwenden, wird die `binlog_transaction_dependency_tracking` Einstellung auf der Quelle nicht verwendet — die Parallelität wird ausschließlich davon bestimmt, auf welche Datenbank eine Transaktion abzielt.
**Anmerkung**
In MySQL-Versionen 8.0.26 und früher ist die Standardeinstellung. `replica_parallel_type` `DATABASE` Ab MySQL 8.0.27 ist es standardmäßig. `LOGICAL_CLOCK` Wenn Sie eine ältere Version verwenden, setzen Sie diesen Parameter explizit auf, um die Vorteile einer detaillierteren Nachverfolgung von Abhängigkeiten `LOGICAL_CLOCK` zu nutzen.
### MTR-Konfiguration
**Source-side Parameter**
| Parameter | Empfohlener Wert | Hinweise |
| --- | --- | --- |
| binlog\_transaction\_dependency\_tracking | WRITESET | Cluster-Parametergruppe. Dynamisch. Für MySQL 8.4 nicht erforderlich. |
| binlog\_transaction\_dependency\_history\_size | 25000 (Standard) | Cluster-Parametergruppe. Dynamisch. Steuert, wie viele Zeilen-Hashes die Quelle für das WRITESET-Abhängigkeits-Tracking speichert. Wenn der Verlauf voll ist oder das Binärlog rotiert, wird es gelöscht und die Parallelität wird vorübergehend unterbrochen. Erwägen Sie, den Wert bei Quellen mit hohem Schreibaufkommen zu verdoppeln (z. B. auf 50000), wenn das Replikat periodische Spitzen in der Fehlerprotokollstatistik „Konflikte, die um die Uhr gewartet haben“ (siehe) aufweist, die mit der Rotation des Binärprotokolls übereinstimmen. [Fehlerprotokoll für Multithread-Replikatstatistiken](#aurora-mysql-replication-lag-monitoring-error-log) Größere Werte verbrauchen mehr Speicher in der Quelle. |
| binlog\_format | ROW | Cluster-Parametergruppe. Statisch (erfordert Neustart). |
| binlog\_group\_commit\_sync\_delay | 0 (Standard) | Mikrosekunden, um den Gruppen-Commit zu verzögern. Wenn Sie diesen Wert erhöhen, werden mehr Transaktionen zu einer Gruppe zusammengefasst. Dadurch wird die Parallelität auf dem Replikat verbessert, allerdings auf Kosten einer leichten Erhöhung der Commit-Latenz an der Quelle. Nur nützlich, wenn das COMMIT\_ORDER-Abhängigkeits-Tracking verwendet wird — WRITESET verfolgt bereits die tatsächlichen Abhängigkeiten auf Zeilenebene, unabhängig vom Commit-Timing. Dynamisch. |
| binlog\_group\_commit\_sync\_no\_delay\_count | 0 (Standard) | Maximale Anzahl von Transaktionen, auf die gewartet werden muss, bevor ein Commit abgeschlossen wird. Verwenden Sie withbinlog\_group\_commit\_sync\_delay, um die Verzögerung zu begrenzen, sobald genügend Transaktionen gebündelt sind. Nur relevant für das COMMIT\_ORDER-Abhängigkeits-Tracking. Dynamisch. |
**Replica-side Parameter**
| Parameter | Empfohlener Wert | Hinweise |
| --- | --- | --- |
| replica\_parallel\_workers | Beginnen Sie mit der vCPU-Anzahl, bis zum Doppelten der vCPU-Anzahl | Instanzparametergruppe. Dynamisch, erfordert aber einen Neustart der Replikation. Der Community-Standard ist ab MySQL 8.0.27 (und den darauf basierenden Aurora MySQL 3-Versionen) 4; frühere Versionen haben standardmäßig 0, was ab MySQL 8.0.30 veraltet ist. Wir empfehlen, mit der Anzahl der vCPUs zu beginnen und dann die CPU-Auslastung und die Fehlerprotokollstatistik „Wartet (Anzahl), wenn Mitarbeiter besetzt sind“ zu überwachen (siehe). [Fehlerprotokoll für Multithread-Replikatstatistiken](#aurora-mysql-replication-lag-monitoring-error-log) Erhöhen Sie den Wert nur, wenn der Wert „Bei Belegung der Mitarbeiter gewartet (Anzahl)“ konstant hoch ist und die CPU-Auslastung unter 80% bleibt. |
| replica\_parallel\_type | LOGISCHE\_UHR | Cluster-Parametergruppe. Dynamisch, erfordert aber einen Neustart der Replikation. |
| replica\_pending\_jobs\_size\_max | > = max\_allowed\_packet keine Quelle | Parametergruppe für Instanzen. Dynamisch. |
| replica\_preserve\_commit\_order | ON | Cluster-Parametergruppe. Dynamisch, erfordert aber einen Neustart der Replikation. |
| binlog\_format | OFF | Cluster-Parametergruppe. Statisch. Aurora-specific Erweiterung zum Deaktivieren der binären Protokollierung. |
Starten Sie die Replikation neu, nachdem Sie die Parallel-Worker-Einstellungen geändert haben:
```
CALL mysql.rds_stop_replication;
CALL mysql.rds_start_replication;
```
## Aurora-specific Optimierungen bei der Replikation
Aurora MySQL bietet die folgenden Funktionen zur Verbesserung der Leistung bei der Replikation von Binärprotokollen. In der folgenden Tabelle werden die Verfügbarkeit, der Standardstatus und die Art und Weise, wie die einzelnen Funktionen aktiviert werden, zusammengefasst.
| Feature | Version | Standard | Wie aktiviere/verifiziere ich |
| --- | --- | --- | --- |
| In-memory Relay-Protokoll | Aurora MySQL 3.10\+ | ON (für die Aurora-managed Replikation, wenn die Bedingungen erfüllt sind) | Wird automatisch für die Aurora-managed Replikation (blue/green Bereitstellungen und regionsübergreifende Replikate) aktiviert Aurora-to-Aurora, wenn das Replikat die Single-Thread-Replikation (replica\_parallel\_workers=0), die Multithread-Replikation mit GTID-Modus und aktivierter automatischer Positionierung oder die dateibasierte Replikation mit verwendet. replica\_preserve\_commit\_order=ON Wird durch den dynamischen aurora\_in\_memory\_relaylog Parameter (DB-Cluster- oder Instance-Ebene) gesteuert: Stoppen Sie die Replikation, setzen Sie sie auf ON oder OFF in der Parametergruppe und starten Sie dann die Replikation neu — kein Instance-Neustart erforderlich. Nicht verfügbar amAurora Serverless. Überprüfen Sie den aktuellen Status mitSHOW GLOBAL STATUS LIKE 'Aurora\_in\_memory\_relaylog\_status'. Weitere Informationen finden Sie unter [In-memory Relay-Protokoll](binlog-optimization.md#binlog-optimization-in-memory-relay-log). |
| Parallele Änderungen am sekundären Index | Aurora MySQL 3.06\+ | AUS () 0 | Stellen Sie aurora\_binlog\_replication\_sec\_index\_parallel\_workers die gewünschte Threadanzahl ein. Stoppen Sie die Replikation, legen Sie den Parameter fest und starten Sie dann die Replikation. Ein Neustart der Instanz ist nicht erforderlich. Weitere Informationen finden Sie unter [Multithread-Replikation für binäre Protokolle](binlog-optimization.md#binlog-optimization-multithreading). |
| Binlog-Cache I/O | Aurora MySQL 2.10\+ und 3.x | EIN (automatisch) | Automatisch aktiviert. Reduziert die I/O Festplattenkapazität an der Quelle, wenn binäre Protokollereignisse an Replikate übertragen werden. Keine Konfiguration erforderlich. Weitere Informationen finden Sie unter [Optimieren einer Binlog-Replikation](binlog-optimization.md#binlog-optimization-binlog-io-cache). |
## Überwachung der parallelen Replikation
Verwenden Sie die folgenden Methoden, um die Replikationsleistung zu überwachen und gleichzeitig Engpässe zu identifizieren:
### Leistungsschema
Schlüsseltabellen für die Überwachung der MTR:
+ `performance_schema.replication_applier_status_by_worker`— Zeigt Details der Transaktionen an, die von jedem Worker-Thread verarbeitet werden, einschließlich Anwendungszeitstempeln und Fehlern.
+ `performance_schema.replication_applier_status_by_coordinator`— Zeigt Informationen über die Pufferaktivität des Coordinator-Threads an.
Verwenden Sie die folgende Abfrage, um zu ermitteln, wie gleichmäßig die Arbeit auf die Worker-Threads verteilt ist:
```
SELECT
a.channel_name,
rw1.thread_id AS replica_worker_thread_id,
ts1.count_star AS number_of_trx_executed,
ROUND((ts1.count_star / sum_count_star) * 100, 2) AS percent_of_trx_executed_by_worker
FROM (
SELECT rw.channel_name, SUM(ts.count_star) AS sum_count_star
FROM performance_schema.events_transactions_summary_by_thread_by_event_name AS ts
JOIN performance_schema.replication_applier_status_by_worker AS rw
ON ts.thread_id = rw.thread_id
GROUP BY rw.channel_name
) AS a
JOIN performance_schema.replication_applier_status_by_worker AS rw1
ON a.channel_name = rw1.channel_name
JOIN performance_schema.events_transactions_summary_by_thread_by_event_name AS ts1
ON rw1.thread_id = ts1.thread_id;
```
Wenn ein oder zwei Worker die Mehrheit der Transaktionen abwickeln, deutet dies auf hohe Transaktionsabhängigkeiten hin, die die Parallelität einschränken. Erwägen Sie, auf das WRITESET-Abhängigkeits-Tracking für die Quelle umzusteigen.
Wenn die Positionen von I/O Thread und SQL-Thread nahe beieinander liegen, aber `Seconds_Behind_Source` immer noch wachsen, könnte der Koordinator-Thread selbst der Engpass sein. Suchen Sie nach `performance_schema.replication_applier_status_by_coordinator` Verzögerungen beim Puffern. Ein Koordinator-Engpass deutet in der Regel auf starke Transaktionsabhängigkeiten oder auf einen überlasteten einzelnen Koordinator-Thread hin, der Ereignisse nicht schnell genug verteilen kann.
### Fehlerprotokoll für Multithread-Replikatstatistiken
Wenn `log_error_verbosity=3` (Standardeinstellung), schreibt Aurora MySQL in regelmäßigen Abständen Replikatstatistiken mit mehreren Threads in das MySQL-Fehlerprotokoll. Sie können diese Einträge wie folgt anzeigen:
+ Sehen Sie sich in der RDS-Konsole im ** Abschnitt ** Logs & Events das Fehlerprotokoll an.
+ Herunterladen über die AWS-CLI: `aws rds download-db-log-file-portion --db-instance-identifier --log-file-name error/mysql-error-running.log`
+ Wenn der CloudWatch Protokollexport für das Fehlerprotokoll aktiviert ist, suchen Sie in der exportierten Protokollgruppe.
Um die Multithread-Replikatstatistikeinträge im Fehlerprotokoll zu finden, suchen Sie nach der im folgenden Beispiel gezeigten Zeichenfolge. Das MySQL-Fehlerprotokoll verwendet in dieser internen Zeichenfolge veraltete Terminologie; in dieser Dokumentation wird durchgehend der bevorzugte Begriff „Replikat“ verwendet.
Im Folgenden finden Sie ein Beispiel für einen Fehlerprotokolleintrag:
```
2026-05-10 14:54:28.045308 [Note] [MY-010559] [Repl] Multi-threaded slave statistics for channel '': seconds elapsed = 120; events assigned = 7215200; worker queues filled over overrun level = 0; waited due a Worker queue full = 0; waited due the total size = 0; waited at clock conflicts = 1203644200 waited (count) when Workers occupied = 1022462 waited when Workers occupied = 62349203500
```
Wichtige zu analysierende Felder:
| Feld | Description | Action |
| --- | --- | --- |
| Sekunden sind vergangen | Zeit in Sekunden seit der letzten Statistikausgabe. Aurora MySQL schreibt keine Statistiken in regelmäßigen Abständen — es schreibt sie auf der Grundlage der Anzahl der ausgeführten Ereignisse plus der verstrichenen Zeit. | Wird zur Berechnung des Durchsatzes verwendet: zugewiesene Ereignisse/ verstrichene Sekunden = durchschnittliche Ereignisse pro Intervall. |
| zugewiesene Ereignisse | Anzahl der Ereignisse, die der Koordinator-Thread seit der letzten Ausgabe Worker-Threads zugewiesen hat. | Überwachen Sie, ob sich der Replikationsdurchsatz im Laufe der Zeit geändert hat. |
| Überschreitung der Überschreitungsrate der Arbeitswarteschlangen | Die Anzahl der Ereignisse, die in Worker-Threads in die Warteschlange gestellt wurden, überschreitet den Überschreitungswert (90% der maximalen Warteschlangenlänge von 16384 Ereignissen). Bei einem Wert von Null arbeiten keine Worker mit der höchsten Kapazität. | Zeigt an, dass Mitarbeiter nicht mit dem Koordinator Schritt halten können. Suchen Sie nach Transaktionen mit langer Laufzeit oder fehlenden Indizes. |
| Gewartet, eine Worker-Warteschlange ist voll | Gibt an, wie oft der Koordinator warten musste, weil die Warteschlange eines Worker-Threads voll war (Kapazität von 100% erreicht). | Suchen Sie nach Transaktionen mit langer Laufzeit, fehlenden Indizes oder Sperrkonflikten in Worker-Threads. |
| Auf die Gesamtgröße wurde gewartet | Häufigkeit, mit der der Koordinator gewartet hat, weil das replica\_pending\_jobs\_size\_max Limit erreicht wurde. Wenn ein ungewöhnlich großes Ereignis diese Größe überschreitet, wird die Transaktion so lange ausgesetzt, bis alle Mitarbeiter keine Warteschlangen mehr haben. | Erhöhenreplica\_pending\_jobs\_size\_max. Suchen Sie an der Quelle nach großen Transaktionen. |
| Es wurde um die Uhr auf Konflikte gewartet | Anzahl der Nanosekunden, auf die der Koordinator gewartet hat, weil eine Transaktion von einer anderen Transaktion abhing, die noch nicht bestätigt wurde. Dies quantifiziert die Zeit, in der Ereignisse aufgrund von Abhängigkeiten nicht zugewiesen werden konnten. | Wechseln Sie zur WRITESET-Abhängigkeitsverfolgung für die Quelle. Stellen Sie sicher, dass Tabellen Primärschlüssel haben. Es ist zu erwarten, dass es zu einem gewissen Zeitkonflikt kommt. Konzentrieren Sie sich darauf, das Verhältnis zu anderen Wartezeiten zu verringern. |
| Es wurde gewartet (gezählt), als die Arbeiter beschäftigt waren | Gibt an, wie oft der Koordinator das erste Ereignis einer Transaktion zuordnen musste, aber nicht alle Warteschlangen der Mitarbeiter leer waren. Der Koordinator schläft, bis eine Warteschlange leer ist. | Dies weist auf replica\_parallel\_workers eine unzureichende Versorgung hin. Abhängigkeiten sind nicht der Engpass — Sie hätten mehr Ereignisse parallel ausführen können, aber es fehlten die verfügbaren Worker-Threads. Erhöhen. replica\_parallel\_workers |
| Wartete, als die Arbeiter beschäftigt waren | Insgesamt hat der Koordinator in Nanosekunden geschlafen, während er auf eine leere Arbeiterwarteschlange wartete. | Hohe Werte bestätigen, dass die Arbeitskapazität der Engpass ist. Erhöhen. replica\_parallel\_workers |
### Bewährte Beispiele: Diagnose von Engpässen bei parallelen Anwendungen
Die folgenden Beispiele zeigen, wie die oben genannten Überwachungsquellen verwendet werden können, um häufig auftretende Engpässe bei der parallelen Anwendung zu diagnostizieren. Jedes Beispiel geht von demselben Symptom aus — `Seconds_Behind_Source` es wächst stetig, und Sie haben bereits bestätigt, dass der SQL-Thread der Engpass ist (siehe[Identifizierung des Engpasses bei der Replikationsverzögerung](#aurora-mysql-replication-lag-identifying)) — und verwendet die Multithread-Replikatstatistiken und das Leistungsschema, um die Korrekturmaßnahmen zu ermitteln.
#### Beispiel 1: Mitarbeiter sind nicht ausreichend versorgt
In CloudWatch steigt die `ReplicaLag` Kennzahl innerhalb von 30 Minuten stetig von nahezu Null auf etwa 400 Sekunden. Die CPU-Auslastung auf dem Replikat bleibt bei etwa 55%, das Replikat also nicht. CPU-bound
Führen Sie den Vorgang `SHOW REPLICA STATUS` zweimal im Abstand von 60 Sekunden durch, um zu überprüfen, wo die Verzögerung liegt. `Read_Source_Log_Pos`erhöht sich um etwa 1,2 GB, während `Exec_Source_Log_Pos` der Fortschritt nur um etwa 300 MB zunimmt. Der I/O Thread hält mit der Quelle Schritt, aber der SQL-Thread fällt ins Hintertreffen — der SQL-Thread ist der Engpass.
MTR ist aktiviert mit. `replica_parallel_workers=4` Rufen Sie die neuesten Multithread-Replikatstatistiken aus dem Fehlerprotokoll ab (siehe): [Fehlerprotokoll für Multithread-Replikatstatistiken](#aurora-mysql-replication-lag-monitoring-error-log)
```
2026-05-10 14:54:28.045308 [Note] [MY-010559] [Repl] Multi-threaded slave statistics for channel '': seconds elapsed = 123; events assigned = 9876544; worker queues filled over overrun level = 0; waited due a Worker queue full = 0; waited due the total size = 0; waited at clock conflicts = 8455000 waited (count) when Workers occupied = 2456789 waited when Workers occupied = 110293847000
```
Interpretieren Sie die Schlüsselfelder:
+ **wartete, als die Arbeiter beschäftigt waren = 110293847000 ** Nanosekunden oder ungefähr 110 Sekunden. Von den 123 Sekunden in diesem Intervall verbrachte der Koordinator ungefähr 90% seiner Zeit damit, darauf zu warten, dass ein Worker-Thread frei wird.
+ **wartete bei Uhrkonflikten = 8455000 ** Nanosekunden oder ungefähr 0,008 Sekunden, was vernachlässigbar ist. Transaktionsabhängigkeiten sind nicht der limitierende Faktor.
**Diagnose: ** Der Koordinator hat durchweg mehr unabhängige Transaktionen zur Verfügung, die beantragt werden können, als er Mitarbeiter hat, die sie durchführen. Da das Warten auf Zeitkonflikte vernachlässigbar ist, wird die Parallelität durch die Anzahl der Mitarbeiter begrenzt, nicht durch Abhängigkeiten.
**Aktion: ** Erhöhen `replica_parallel_workers` Sie die Anzahl der vCPUs des Replikats (z. B. 16 bei a) und starten Sie die Replikation neu: `db.r6g.4xlarge`
```
CALL mysql.rds_stop_replication;
CALL mysql.rds_start_replication;
```
**Überprüfung: ** Eine spätere Statistikzeile zeigt, dass die Wartezeit fast verschwunden ist und nun `ReplicaLag` wieder unter 5 Sekunden liegt:
```
2026-05-10 15:02:14.882201 [Note] [MY-010559] [Repl] Multi-threaded slave statistics for channel '': seconds elapsed = 120; events assigned = 31840552; worker queues filled over overrun level = 0; waited due a Worker queue full = 0; waited due the total size = 0; waited at clock conflicts = 9120000 waited (count) when Workers occupied = 41233 waited when Workers occupied = 5980411000
```
Die „Wartezeit, wenn Mitarbeiter beschäftigt waren“ fiel von etwa 110 Sekunden auf etwa 6 Sekunden, und der Durchsatz (zugewiesene Ereignisse) hat sich mehr als verdreifacht. Stellen Sie die Erhöhung der Anzahl der Mitarbeiter ein, sobald sich die CPU-Auslastung 80% nähert oder die Wartezeit nicht mehr abnimmt.
#### Beispiel 2: Durch das COMMIT\_ORDER-Abhängigkeits-Tracking wird ein Workload mit geringer Parallelität serialisiert
Die Quelle ist eine Amazon RDS for MySQL-Instance, auf der ein OLTP-Workload mit nur 4—8 Anwendungs-Threads gleichzeitig ausgeführt wird. Das Replikat ist ein mit und. `db.r6g.4xlarge` `replica_parallel_workers=16` `replica_parallel_type=LOGICAL_CLOCK` Trotz 16 Mitarbeitern `ReplicaLag` hält es etwa 600 Sekunden konstant und die Replikat-CPU-Auslastung liegt nur bei etwa 20% — die Mitarbeiter sehen inaktiv aus.
Prüfen Sie zunächst mithilfe der Worker-Distribution-Abfrage von: [Leistungsschema](#aurora-mysql-replication-lag-monitoring-perf-schema)
```
+--------------+--------------------------+------------------------+-----------------------------------+
| channel_name | replica_worker_thread_id | number_of_trx_executed | percent_of_trx_executed_by_worker |
+--------------+--------------------------+------------------------+-----------------------------------+
| | 45 | 1903556 | 96.41 |
| | 46 | 23104 | 1.17 |
| | 47 | 18995 | 0.96 |
| | 48 | 16720 | 0.85 |
.
.
+--------------+--------------------------+------------------------+-----------------------------------+
```
Die vorherige Ausgabe zeigt die ersten 4 der 16 Worker-Threads. Ein Worker wendet über 96% der Transaktionen an, während die anderen 15 fast inaktiv sind (jeder der verbleibenden Worker hat weniger als 0,05% ausgeführt). Die Bewerbung erfolgt praktisch seriell.
Bestätigen Sie dies als Nächstes mit den Multithread-Replikatstatistiken im Fehlerprotokoll:
```
2026-05-10 15:22:11.110432 [Note] [MY-010559] [Repl] Multi-threaded slave statistics for channel '': seconds elapsed = 120; events assigned = 2014500; worker queues filled over overrun level = 0; waited due a Worker queue full = 0; waited due the total size = 0; waited at clock conflicts = 98712340000 waited (count) when Workers occupied = 50122 waited when Workers occupied = 1209847000
```
+ **wartete bei Uhrkonflikten = 98712340000 ** Nanosekunden oder ungefähr 99 der 120 Sekunden. Der Koordinator verbrachte ungefähr 82% des Intervalls damit, die nächste Transaktion nicht versenden zu können, da dies davon abhing, dass eine Transaktion noch ausgeführt wurde.
+ **wartete, als die Arbeiter beschäftigt waren = 1209847000 ** Nanosekunden oder ungefähr 1,2 Sekunden. Arbeiter hatten fast immer frei, mehr Arbeiter helfen also nicht.
Das deutet auf ein Abhängigkeitsproblem hin, nicht auf ein Kapazitätsproblem. Überprüfen Sie die Methode zur Nachverfolgung von Abhängigkeiten an der ** Quelle**:
```
SELECT @@global.binlog_transaction_dependency_tracking;
```
```
+-------------------------------------------------+
| @@global.binlog_transaction_dependency_tracking |
+-------------------------------------------------+
| COMMIT_ORDER |
+-------------------------------------------------+
```
**Grundursache: ** Mit entscheidet die Quelle`COMMIT_ORDER`, welche Transaktionen parallel ausgeführt werden können, basierend darauf, welche Transaktionen zusammen in derselben Binärloggruppen-Commit festgeschrieben wurden. Bei diesem Workload mit geringer Parallelität wird nur eine Handvoll Threads gleichzeitig ausgeführt, sodass Gruppen-Commits winzig sind. Daher stempelt die Quelle fast jede Transaktion mit einem `last_committed` Wert, der dem Wert der vorherigen Transaktion entspricht`sequence_number`, und markiert sie als abhängig von der vorherigen Transaktion. Das Replikat muss sie dann nacheinander anwenden — obwohl sie völlig unabhängige Zeilen modifizieren — weshalb 15 der 16 Worker untätig sitzen.
**Aktion: Stellen ** Sie die Quelle auf das Abhängigkeits-Tracking auf Zeilenebene um, das unabhängig vom Commit-Timing ist. Stellen Sie es dynamisch ein und speichern Sie es in der Cluster-Parametergruppe (oder DB):
```
SET GLOBAL binlog_transaction_dependency_tracking = WRITESET;
```
`WRITESET`berechnet einen Hash der Zeilen, die jede Transaktion ändert, sodass Transaktionen, die verschiedene Zeilen berühren, unabhängige Zeitstempel erhalten und parallel angewendet werden können, unabhängig davon, wann sie festgeschrieben wurden. Stellen Sie sicher, dass alle Tabellen Primärschlüssel haben, da WRITESET leere Schreibsätze für Tabellen ohne Primärschlüssel erzeugt (siehe). [Behebung von SQL-Thread-Verzögerungen](#aurora-mysql-replication-lag-sql-thread) In MySQL 8.4 ist WRITESET die Standardeinstellung und dieser Parameter existiert nicht mehr.
**Überprüfung: ** Nach der Änderung zeigt die Abfrage zur Mitarbeiterverteilung, dass die Arbeit gleichmäßig auf alle Mitarbeiter verteilt ist (es werden die ersten 4 von 16 angezeigt; jeder Mitarbeiter wickelt jetzt etwa 6% der Transaktionen ab):
```
+--------------+--------------------------+------------------------+-----------------------------------+
| channel_name | replica_worker_thread_id | number_of_trx_executed | percent_of_trx_executed_by_worker |
+--------------+--------------------------+------------------------+-----------------------------------+
| | 45 | 132540 | 6.30 |
| | 46 | 125610 | 5.97 |
| | 47 | 129774 | 6.17 |
| | 48 | 122901 | 5.84 |
.
.
+--------------+--------------------------+------------------------+-----------------------------------+
```
und die Statistik des Fehlerprotokolls zeigt, dass Uhrkonflikte zusammenbrechen, während `ReplicaLag` sie fast auf Null fallen:
```
2026-05-10 15:41:55.204713 [Note] [MY-010559] [Repl] Multi-threaded slave statistics for channel '': seconds elapsed = 120; events assigned = 19874100; worker queues filled over overrun level = 0; waited due a Worker queue full = 0; waited due the total size = 0; waited at clock conflicts = 412300000 waited (count) when Workers occupied = 88122 waited when Workers occupied = 7019847000
```
„Konflikte, die um die Uhr gewartet wurden“, sind von etwa 99 Sekunden auf etwa 0,4 Sekunden gesunken, der Durchsatz hat sich etwa verzehnfacht, und der Engpass verlagerte sich von Abhängigkeiten hin zur Arbeitskapazität. An diesem Punkt können Sie die Anzahl der Mitarbeiter wie in Beispiel 1 anpassen.
#### Beispiel 3: Ein fehlender Primärschlüssel erzwingt vollständige Tabellenscans auf dem Replikat
`ReplicaLag`Spitzenwerte während eines nächtlichen Batch-Jobs, bei dem große `DELETE` AND-Anweisungen ausgeführt werden, `UPDATE` und danach wiederhergestellt werden. Während der Spitzenzeiten ist die Replikat-CPU moderat, aber ein Worker scheint festgefahren zu sein.
Führen Sie auf dem Replikat aus `SHOW PROCESSLIST` und sehen Sie sich die Replikationsworker-Threads an. Ein Worker verbleibt mehrere Sekunden lang in dem `Updating` Zustand, in dem dieselbe Anweisung ausgeführt wurde:
```
+----+-------------+------+---------+----------+------+
| Id | User | db | Command | State | Time |
+----+-------------+------+---------+----------+------+
| 12 | system user | app | Connect | Updating | 38 |
+----+-------------+------+---------+----------+------+
```
Prüfen Sie anhand der Erkennungsabfrage von[Behebung von SQL-Thread-Verzögerungen](#aurora-mysql-replication-lag-sql-thread):
```
+--------------+----------------+
| table_schema | table_name |
+--------------+----------------+
| app | events_archive |
+--------------+----------------+
```
**Hauptursache: ** Bei der ROW-based binären Protokollierung muss sich jede Zeile in einem `UPDATE` `DELETE` OR-Ereignis auf dem Replikat befinden, bevor es angewendet werden kann. Wenn die Tabelle keinen Primärschlüssel oder einen eindeutigen NOT-NULL-Schlüssel hat, führt das Replikat für ** jede ** betroffene Zeile einen vollständigen Tabellenscan durch. Bei einer Tabelle mit mehreren Millionen Zeilen führt ein Batch-Vorgang zu Millionen vollständiger Scans, und der Worker, der den Scan durchführt, kommt zum Stillstand, wodurch der Anwendungsfortschritt blockiert und die Verzögerung erhöht wird.
**Aktion: ** Fügen Sie der Tabelle einen Primärschlüssel hinzu. Wenn Sie einen expliziten Schlüssel nicht sofort definieren können, aktivieren Sie Generated Invisible Primary Keys (GIPK), indem Sie den `sql_generate_invisible_primary_key` Parameter auf `ON` (verfügbar in Aurora MySQL 3-Versionen, die auf MySQL 8.0.30 und höher basieren) setzen, sodass neue Tabellen einen automatischen Primärschlüssel erhalten (siehe). [Behebung von SQL-Thread-Verzögerungen](#aurora-mysql-replication-lag-sql-thread)
**Überprüfung: ** Nach dem Hinzufügen des Primärschlüssels verweilt der Worker nicht mehr`Updating`, die Anwendungsrate des SQL-Threads wird wiederhergestellt und `ReplicaLag` kehrt im nächsten Batch-Fenster zum Ausgangswert zurück.
#### Beispiel 4: Eine einzelne große Transaktion kann nicht parallelisiert werden
`ReplicaLag`springt jeden Tag zu einer vorhersehbaren Zeit stark, hält mehrere Minuten lang an und fällt dann wieder auf nahezu Null zurück. Die WRITESET-Abhängigkeitsverfolgung ist aktiviert`replica_parallel_workers=16`, und alle Tabellen verfügen über Primärschlüssel, sodass die früheren Beispiele nicht zutreffen.
Während der Spitzenzeiten zeigt die Worker-Distribution-Abfrage, dass ein Mitarbeiter beschäftigt ist und der Rest untätig ist. Im Gegensatz zu Beispiel 2 zeigt das Fehlerprotokoll jedoch weder hohe Uhrzeiten noch Wartezeiten, die von Mitarbeitern besetzt sind:
```
2026-05-10 02:13:40.551922 [Note] [MY-010559] [Repl] Multi-threaded slave statistics for channel '': seconds elapsed = 95; events assigned = 4120000; worker queues filled over overrun level = 0; waited due a Worker queue full = 0; waited due the total size = 0; waited at clock conflicts = 1530000 waited (count) when Workers occupied = 980 waited when Workers occupied = 210440000
```
Sowohl die Wartezeiten als auch die Wartezeiten bei Belegschaft sind gering, aber nur eine Arbeitskraft ist aktiv. Dadurch werden sowohl der Engpass bei den Abhängigkeiten (Beispiel 2) als auch der Kapazitätsengpass der Arbeitnehmer (Beispiel 1) ausgeschlossen.
Inspizieren Sie den beschäftigten Arbeiter, oder rennen Sie los. `performance_schema.replication_applier_status_by_worker` `SHOW PROCESSLIST` Während der gesamten Dauer des Anstiegs wendet ein einzelner Mitarbeiter eine Transaktion an. In der Quelle führt ein Anwendungsauftrag eine große Anweisung — `DELETE FROM orders WHERE created_at < '2025-01-01'` die sich beispielsweise auf mehrere Millionen Zeilen auswirkt — als eine einzige Transaktion aus.
**Grundursache: ** MTR parallelisiert ** unabhängige Transaktionen; eine einzelne Transaktion kann nicht ** auf mehrere Worker aufgeteilt werden. Eine große Transaktion wird von genau einem Worker ausgeführt. Es hilft also nicht, Worker hinzuzufügen, zu WRITESET zu wechseln oder Primärschlüssel hinzuzufügen. Weitere Informationen finden Sie unter [Multi-threaded Replikation (MTR)](#aurora-mysql-replication-lag-mtr).
**Handlung: ** Teilen Sie den großen Vorgang an der Quelle in kleinere Batches auf (löschen Sie beispielsweise Abschnitte von ein paar tausend Zeilen pro Transaktion, mit einer kurzen Pause zwischen den Batches). Kleinere Transaktionen werden unabhängig voneinander ausgeführt, sodass das Replikat sie auf mehrere Worker verteilen kann. Planen Sie Massenaufträge nach Möglichkeit in Zeiten mit wenig Verkehr ein.
**Überprüfung: ** Nach der Stapelverarbeitung des Auftrags flacht die tägliche `ReplicaLag` Spitze ab, und die Abfrage zur Verteilung der Mitarbeiter zeigt, dass der Stapel auf mehrere Mitarbeiter verteilt ist, anstatt auf einen.
### Überwachung bewährter Verfahren
1. Konfigurieren Sie CloudWatch Alarme für die `ReplicaLag` Metrik mit entsprechenden Schwellenwerten.
1. Verwenden Sie Heartbeat-Tabellen für eine genauere Lag-Messung als. `Seconds_Behind_Source` Zum Beispiel verwenden`pt-heartbeat`, was eine separate Installation erfordert (siehe [ Percona Toolkit ](https://docs.percona.com/percona-toolkit/) auf der Percona-Website).
1. Überwachen Sie die `SumBinaryLogSize` CloudWatch Metrik an der Quelle, um die Generierungsrate von Binärprotokollen zu verfolgen.
1. Aktivieren Sie CloudWatch Logs-Protokollexporte für das Fehlerprotokoll, um Multithread-Replikatstatistiken beizubehalten.
1. Verwenden Sie Enhanced Monitoring für CPU, Arbeitsspeicher und I/O Auslastung sowohl für die Quelle als auch für das Replikat.
1. Verwenden Sie Amazon CloudWatch Database Insights, um Ereignisse mit der höchsten Wartezeit und Abfragen zu identifizieren, die zu Ressourcenkonflikten führen. Performance Insights endet am 31. Juli 2026. Nach diesem Datum leitet die Performance Insights-Konsole zu CloudWatch Database Insights weiter. Wählen Sie den Database Insights-Modus, der Ihren Anforderungen entspricht. Im Standardmodus bleiben die wichtigsten Funktionen zur Überwachung und Preisgestaltung erhalten, während im Modus „Erweitert“ die Überwachung auf Flottenebene, Sperrdiagnosen und die Erfassung von Ausführungsplänen hinzugefügt werden. Weitere Informationen finden Sie unter [Überwachen der DB-Auslastung mit Amazon CloudWatch Database Insights Amazon Aurora](USER_PerfInsights.md).
## Bewährte Methoden zur Minimierung von Verzögerungen bei der Replikation
Die folgenden Empfehlungen fassen die wichtigsten Maßnahmen zur Minimierung der Replikationsverzögerung zusammen. Eine ausführliche Anleitung zu den einzelnen Themen finden Sie unter den Querverweisen.
1. **Stellen Sie sicher, dass alle Tabellen Primärschlüssel haben ** — Ohne Primärschlüssel führt das Replikat bei UPDATE- und DELETE-Vorgängen vollständige Tabellenscans für jede geänderte Zeile durch. Weitere Informationen finden Sie unter [Behebung von SQL-Thread-Verzögerungen](#aurora-mysql-replication-lag-sql-thread).
1. **Aktivieren Sie Multithread-Replikation mit WRITESET ** — SQL-Parallelisierungen gelten für unabhängige Transaktionen. Einzelheiten zur Konfiguration finden Sie unter. [Multi-threaded Replikation (MTR)](#aurora-mysql-replication-lag-mtr)
1. **Verwenden Sie mindestens dieselbe Instanzklasse wie die Quelle ** — Stellt ausreichend CPU-, Speicher- und Netzwerkressourcen für die Replikation bereit. Weitere Informationen finden Sie unter [Optimierungsstrategien für I/O Thread-Lag](#aurora-mysql-replication-lag-io-optimization).
1. **Halten Sie die Transaktionsgrößen klein ** — Große Transaktionen reduzieren die Parallelität und verlängern die Länge der Verlaufsliste. Weitere Informationen finden Sie unter [Behebung von SQL-Thread-Verzögerungen](#aurora-mysql-replication-lag-sql-thread).
1. **Binärprotokollierung auf Replikaten deaktivieren ** — Diese Option wird gesetzt, `binlog_format=OFF` sofern keine Downstream-Replikation erforderlich ist. Einzelheiten zu den Parametern finden Sie unter [MTR-Konfiguration](#aurora-mysql-replication-lag-mtr-config).
1. **Vermeiden Sie langwierige Transaktionen und Abfragen auf Replikaten ** — Long-running Lesetransaktionen verhindern das Löschen der Verlaufsliste, was die Replikationsleistung beeinträchtigen kann.
1. ** GTID-based Replikation aktivieren ** — Ermöglicht die automatische Positionsverfolgung und aktiviert das Aurora-In-Memory-Relay-Log (Aurora MySQL 3.10\+). Weitere Informationen finden Sie unter [Aurora-specific Optimierungen bei der Replikation](#aurora-mysql-replication-lag-aurora-optimizations).