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

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 oder. Identifizierung des Engpasses bei der Replikationsverzögerung Behebung von SQL-Thread-Verzögerungen

MySQL-Replikationsarchitektur

Die MySQL-Replikation wird über spezielle Threads implementiert:

Der Replikationsvorgang funktioniert wie folgt:

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.

Source_Log_File:       mysql-bin.000045
Read_Source_Log_Pos:   524288000
Relay_Source_Log_File: mysql-bin.000045
Exec_Source_Log_Pos:   524200000

File:     mysql-bin.000045
Position: 1073741824

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:

Optimierungsstrategien für I/O Thread-Lag

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 vonSHOW MASTER STATUS) mit der SQL-Thread-Anwendungsrate auf dem Replikat (das Exec_Source_Log_Pos Delta).

Häufige Ursachen und Lösungen:

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;

SELECT trx_id, trx_started, trx_rows_modified, trx_query
FROM information_schema.innodb_trx
WHERE trx_rows_modified > 10000
ORDER BY trx_started;

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;

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.

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_committedundsequence_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:

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.

Paralleler Typ (replica_parallel_type)

Der replica_parallel_type Parameter bestimmt, wie Transaktionen auf die Worker-Threads verteilt werden. Es gibt zwei Optionen:

MTR-Konfiguration

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.

Ü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:

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:

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:

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 (sieheIdentifizierung des Engpasses bei der Replikationsverzögerung) — 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_Poserhö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

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:

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

+--------------+--------------------------+------------------------+-----------------------------------+
| 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

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 QuelleCOMMIT_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 entsprichtsequence_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;

WRITESETberechnet 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 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

ReplicaLagSpitzenwerte 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 vonBehebung von SQL-Thread-Verzögerungen:

+--------------+----------------+
| 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

Überprüfung: Nach dem Hinzufügen des Primärschlüssels verweilt der Worker nicht mehrUpdating, 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

ReplicaLagspringt 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 aktiviertreplica_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).

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

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.