Oplog-Fenster und Replikationsverzögerung messen

Befehl

// Oplog size and the time span it covers (oplog window):
rs.printReplicationInfo()
// Lag of each secondary relative to the primary:
rs.printSecondaryReplicationInfo()
// Lag in seconds and sync source, for monitoring/scripts:
const s = rs.status(); const p = s.members.find(m => m.stateStr === "PRIMARY");
s.members.filter(m => m.stateStr === "SECONDARY").map(m => ({ host: m.name, lagSec: (p.optimeDate - m.optimeDate) / 1000, syncSource: m.syncSourceHost }))
// Window (hours):
db.getReplicationInfo().timeDiffHours

Was es tut

Zeigt, wie viele Stunden an Schreibvorgängen das Oplog fasst (Oplog-Fenster) und wie viele Sekunden jeder Secondary hinter dem Primary liegt, zusammen mit seiner Sync Source.

Wann einsetzen

Bei einem Alarm wegen Replikationsverzögerung, vor einer geplanten Wartung, um zu berechnen, wie lange ein Mitglied ausfallen darf, und nach Massenschreibjobs.

Vorsicht

Bleibt ein Mitglied länger als das Oplog-Fenster ausgefallen, wird es 'too stale' und braucht eine Initial Sync. Massen-Update-/Delete-Jobs können das Fenster innerhalb von Stunden verkleinern; beurteile das Fenster nach seinem Wert unter Spitzenlast. Die Verzögerung wird aus der Differenz von optimeDate berechnet; erhält der Primary keine Schreibzugriffe, wirkt die Verzögerung nicht hoch, aber auch das Fenster schrumpft nicht.