Semi-synchrone Replikation: Lag systematisch überwachen

1. Unterschied zwischen ACK-Wartezeit und tatsächlichem Replikations-Lag

Die ACK-Wartezeit ist die Zeitspanne, die ein Source auf die Bestätigung mindestens eines Replicas wartet, bevor er den Commit dem Client meldet. Diese Zeit ist üblicherweise sehr kurz, oft im niedrigen einstelligen Millisekundenbereich, weil das Replica lediglich bestätigen muss, dass das Event im eigenen Relay-Log angekommen ist, nicht dass es bereits angewendet wurde. Ein niedriger Wert für diese Wartezeit sagt daher wenig über den tatsächlichen Zustand der Datenbank auf dem Replica aus.

Der tatsächliche Replikations-Lag hingegen misst, wie weit der Apply-Prozess auf dem Replica hinter dem, was im Relay-Log bereits vorliegt, zurückliegt. Diese beiden Größen können weit auseinanderfallen: Ein Replica kann jede Transaktion binnen weniger Millisekunden bestätigen und trotzdem Minuten brauchen, um sie tatsächlich anzuwenden, wenn der SQL-Thread durch komplexe Statements oder Locking-Konflikte ausgebremst wird.

2. Wie das semi-synchrone ACK tatsächlich funktioniert

Semi-synchrone Replikation wird über die Plugins rpl_semi_sync_source auf dem Source und rpl_semi_sync_replica auf dem Replica realisiert. Sobald der Source eine Transaktion committet und die zugehörigen Binlog-Events an mindestens ein Replica gesendet hat, wartet er auf ein ACK-Signal, bevor er den Commit dem aufrufenden Client bestätigt. Dieses ACK sendet das Replica, sobald das empfangene Event im lokalen Relay-Log geschrieben, nicht angewendet, wurde.

Genau diese Design-Entscheidung macht semi-sync deutlich performanter als vollsynchrone Replikation, wie sie etwa Galera oder Group Replication im Zertifizierungsmodus umsetzen, weil kein Warten auf den vollständigen Apply-Vorgang nötig ist. Der Preis dafür ist, dass ein Ausfall des Sources direkt nach dem ACK, aber vor dem tatsächlichen Anwenden auf dem Replica, theoretisch zu einem Replica führen kann, das die Transaktion im Relay-Log, aber noch nicht in seinen Tabellen hat.

-- Auf dem Source
INSTALL PLUGIN rpl_semi_sync_source SONAME 'semisync_source.so';
SET PERSIST rpl_semi_sync_source_enabled = 1;

-- Auf dem Replica
INSTALL PLUGIN rpl_semi_sync_replica SONAME 'semisync_replica.so';
SET PERSIST rpl_semi_sync_replica_enabled = 1;
-- Anschliessend START REPLICA IO_THREAD auf dem Replica erneut ausführen

3. Warum eine niedrige ACK-Zeit nicht bedeutet, dass der Replica aktuell ist

Der Apply-Prozess auf dem Replica läuft historisch als einzelner SQL-Thread pro Kanal, der Events strikt sequenziell anwendet. Selbst mit aktivierter paralleler Replikation über replica_parallel_workers bleibt die Parallelität durch Abhängigkeiten zwischen Transaktionen auf derselben Zeile oder demselben Datenbankschema begrenzt, sodass ein einzelner langsamer Vorgang, etwa ein großes Batch-Update oder ein fehlender Index, den gesamten Apply-Fortschritt spürbar verzögert.

Ein Replica kann daher jede eingehende Transaktion binnen Millisekunden bestätigen und trotzdem einen Apply-Rückstand von mehreren Minuten aufbauen, sobald der SQL-Thread durch ressourcenintensive Operationen blockiert wird. Wer nur die semi-sync-ACK-Metriken überwacht, sieht in diesem Fall ein scheinbar völlig gesundes System, während Leseanfragen an diesen Replica bereits veraltete Daten zurückliefern.

4. Relevante Status-Variablen für semi-sync selbst

Auf dem Source geben Rpl_semi_sync_source_yes_tx und Rpl_semi_sync_source_no_tx Auskunft darüber, wie viele Transaktionen erfolgreich beziehungsweise nicht rechtzeitig bestätigt wurden, letzteres ein Hinweis auf einen Fallback zu asynchroner Replikation. Rpl_semi_sync_source_avg_net_wait_time zeigt die durchschnittliche Netzwerk-Wartezeit auf das ACK, ein Wert, der bei stabilen Netzwerkverbindungen nahezu konstant bleiben sollte.

Ein plötzlicher Anstieg bei Rpl_semi_sync_source_no_tx deutet fast immer auf Netzwerkprobleme oder überlastete Replicas hin, die das ACK-Zeitfenster regelmäßig verpassen. Da dieser Wert kumulativ seit dem letzten Server-Start gezählt wird, ist für ein Dashboard eine Ableitung der Differenz über ein festes Zeitfenster deutlich aussagekräftiger als der absolute Zählerstand.

SHOW STATUS LIKE 'Rpl_semi_sync_source_yes_tx';
SHOW STATUS LIKE 'Rpl_semi_sync_source_no_tx';
SHOW STATUS LIKE 'Rpl_semi_sync_source_avg_net_wait_time';
SHOW STATUS LIKE 'Rpl_semi_sync_source_status';

5. Performance-Schema-Tabellen zur Überwachung des tatsächlichen Apply-Lags

Für den tatsächlichen Rückstand liefert performance_schema.replication_applier_status_by_worker pro Apply-Worker den Zeitstempel der zuletzt angewendeten Transaktion, woraus sich eine präzise Differenz zur aktuellen Zeit berechnen lässt. Diese Tabelle ist deutlich aussagekräftiger als das klassische Seconds_Behind_Source aus SHOW REPLICA STATUS, das bei paralleler Replikation und bei Verbindungsabbrüchen bekanntermaßen ungenaue oder sogar NULL-Werte liefern kann.

Ergänzend zeigt replication_connection_status den zeitlichen Abstand zwischen dem Zeitpunkt, an dem eine Transaktion auf dem Source committet wurde, und dem Zeitpunkt, an dem sie auf dem Replica empfangen wurde, über die Spalten LAST_QUEUED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP und LAST_QUEUED_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP. Die Kombination beider Tabellen trennt sauber zwischen Netzwerk-Lag und Apply-Lag.

SELECT WORKER_ID,
       TIMESTAMPDIFF(SECOND, APPLYING_TRANSACTION_START_APPLY_TIMESTAMP, NOW())
         AS apply_lag_sekunden
FROM performance_schema.replication_applier_status_by_worker
WHERE SERVICE_STATE = 'ON';

6. Den echten Lag mit einer Heartbeat-Tabelle messen

Für eine anwendungsnahe, vom Replikationsprotokoll unabhängige Lag-Messung hat sich das Heartbeat-Muster bewährt, bekannt aus Werkzeugen wie pt-heartbeat: Eine kleine Tabelle auf dem Source wird in festem Intervall mit einem aktuellen Zeitstempel aktualisiert, dieses Update repliziert wie jede andere Transaktion. Auf dem Replica wird die Differenz zwischen dem gespeicherten Zeitstempel und der lokalen Serverzeit berechnet, was den tatsächlichen End-to-End-Lag inklusive Apply-Zeit unabhängig von internen Replikationsmetriken liefert.

Dieser Ansatz hat den Vorteil, dass er dieselbe Apply-Pipeline durchläuft wie jede reale Anwendungstransaktion und damit realistischer misst als eine reine Metadaten-Abfrage. Für Magento-Umgebungen mit Read Replicas für Reporting oder Suche empfiehlt sich diese Heartbeat-Tabelle zusätzlich zu den internen Metriken, weil sie unmittelbar die für Endnutzer relevante Datenaktualität widerspiegelt.

-- Auf dem Source alle 2 Sekunden per Cron/Event ausgefuehrt
UPDATE heartbeat SET ts = NOW(6) WHERE id = 1;

-- Auf dem Replica ausgewertet
SELECT TIMESTAMPDIFF(MICROSECOND, ts, NOW(6)) / 1000000 AS lag_sekunden
FROM heartbeat WHERE id = 1;

7. Alerting-Schwellenwerte für den Praxisbetrieb

Für die meisten Magento-nahen Setups mit Read Replicas hat sich eine gestaffelte Alarmierung bewährt: eine Warnung ab etwa fünf Sekunden Apply-Lag, die eher informativ ist und auf kurzzeitige Lastspitzen hindeutet, sowie ein kritischer Alarm ab etwa dreißig Sekunden, ab dem Leseanfragen an diesen Replica für zeitkritische Anwendungsfälle wie Bestandsanzeigen oder Bestellstatus aktiv umgeleitet werden sollten. Diese konkreten Werte sind kein Naturgesetz, sondern müssen an die tatsächliche Schreiblast und Fehlertoleranz der jeweiligen Anwendung angepasst werden.

Wichtiger als ein einzelner fixer Schwellenwert ist eine Trendbetrachtung: Ein Lag, der über mehrere Messintervalle hinweg kontinuierlich wächst, signalisiert ein strukturelles Problem, etwa einen dauerhaft überlasteten Replica, während ein kurzer Ausschlag nach einem großen Batch-Import meist unkritisch ist und sich von selbst wieder abbaut. Alerting-Regeln sollten deshalb auf Trend und Dauer reagieren, nicht ausschließlich auf einen einzelnen Momentanwert.

8. Der Fallback-Mechanismus bei überschrittenem ACK-Timeout

Antwortet kein Replica innerhalb der über rpl_semi_sync_source_timeout konfigurierten Zeitspanne, üblicherweise standardmäßig zehn Sekunden, fällt der Source automatisch auf asynchrone Replikation zurück, um Schreibzugriffe der Anwendung nicht unbegrenzt zu blockieren. Dieser Fallback wird über Rpl_semi_sync_source_status sichtbar, das dann von ON auf OFF wechselt, während semi-sync selbst aktiviert bleibt und bei der nächsten erfolgreichen Bestätigung automatisch wieder in den synchronen Modus zurückkehrt.

Für das Monitoring ist entscheidend, diesen Statuswechsel selbst zu überwachen, nicht nur die Lag-Werte, denn ein dauerhafter Fallback in den asynchronen Modus bedeutet, dass die semi-sync-Garantie faktisch nicht mehr greift, obwohl die Konfiguration weiterhin semi-sync ausweist. Ein Alert auf jeden Wechsel von Rpl_semi_sync_source_status auf OFF deckt genau diesen stillen Garantieverlust zuverlässig auf.

9. Praxisbeispiel: ein kompaktes Monitoring-Query-Set für Dashboards

Ein praxistaugliches Dashboard kombiniert typischerweise drei Ebenen: die semi-sync-Statuswerte für die ACK-Garantie selbst, die Performance-Schema-Abfrage für den Apply-Lag pro Worker, sowie die Heartbeat-Tabelle für die End-to-End-Sicht aus Anwendungsperspektive. Alle drei Werte lassen sich mit geringem Aufwand über ein einfaches Cron-Skript regelmäßig abfragen und an ein Monitoring-System wie Prometheus über den mysqld-exporter weiterleiten.

Für Alerting-Regeln empfiehlt sich, alle drei Werte gemeinsam zu betrachten statt isoliert: Ein hoher Apply-Lag bei gleichzeitig normalem semi-sync-Status weist auf ein Performance-Problem des Apply-Threads hin, während ein Fallback-Status bei niedrigem Apply-Lag eher auf ein Netzwerkproblem zwischen Source und Replica hindeutet. Diese Kombination erlaubt eine deutlich präzisere Diagnose als jede einzelne Metrik für sich.

10. Zusammenfassung

11. FAQ: Semi-Sync-Lag: Das Wichtigste auf einen Blick