Schlüsselparameter, die Percona ClusterSync für MongoDB beschleunigen
Percona hat einen detaillierten Leitfaden zur Optimierung von Percona ClusterSync für MongoDB (PCSM) veröffentlicht, einem Synchronisierungstool, das Daten von einem Quell-MongoDB-Cluster in einen Ziel-Cluster kopiert. Der Blogbeitrag, verfasst von Ivan Groenewold und Adnan Supic und veröffentlicht am 1. Oktober 2026, erklärt, welche Parameter für die beiden Phasen des Synchronisierungsprozesses wichtig sind, und schlägt Ausgangswerte für Tests vor. PCSM erstellt zunächst einen konsistenten Ausgangspunkt, indem es vorhandene Sammlungen und Indizes klont und gleichzeitig Quelländerungen über MongoDB Change Streams erfasst, einen Echtzeit-Feed von Datenbankoperationen. Sobald die anfängliche Kopie abgeschlossen ist, wendet PCSM diese erfassten Änderungen an, bis das Ziel den Quellstand erreicht hat. Die neuesten architektonischen Änderungen führen mehrere neue Parameter ein, um die Geschwindigkeit des anfänglichen Klonens und den Durchsatz der kontinuierlichen Replikation zu verbessern.
Die Autoren raten zu schrittweisem Tuning und zur Beobachtung von CPU-, Festplatten- und Netzwerkauslastung, Verbindungsanzahl und Replikationsverzögerung auf Quell- und Zielsystem nach jeder Änderung. Sie empfehlen die Verwendung von Percona Monitoring and Management (PMM), einem Überwachungstool, um Engpässe zu identifizieren, und die gleichen Metriken auch für den Host, auf dem PCSM läuft, im Auge zu behalten. Dieser maßvolle Ansatz verhindert, dass eine Tuning-Änderung Speicher oder Verbindungen sättigt.
Die anfängliche Klonphase wird hauptsächlich durch Sammlungsparallelität, Lese- und Einfüge-Worker, Segmentgröße und Lesebatchgröße beeinflusst. Diese Werte werden beim Start des PCSM-Prozesses konfiguriert. Die Sammlungsparallelität wird durch clone-num-parallel-collections gesteuert, das standardmäßig auf 2 gesetzt ist, eine konservative Einstellung, die begrenzt, wie viele Sammlungen gleichzeitig geklont werden. Percona empfiehlt, den Wert zu erhöhen, wenn die Quelle viele Sammlungen hat und sowohl Quelle als auch Ziel über freie CPU- und Festplattenkapazität verfügen. Ein vernünftiger Ausgangspunkt sind 4 parallele Sammlungen pro CPU-Kern; danach können höhere Werte getestet werden, solange das Ziel nicht gesättigt ist. Übermäßige Parallelität erhöht die Festplattenkonkurrenz und die Verbindungsnutzung.
Die Klonphase verwendet außerdem clone-num-read-workers und clone-num-insert-workers. Der Standardwert für Lese-Worker ist max(NumCPU/4, 1), und der Standardwert für Einfüge-Worker ist NumCPU multipliziert mit 2. Lese-Worker holen Dokumente von der Quelle, während Einfüge-Worker Batches in das Ziel schreiben. Erhöhen Sie die Lese-Worker, wenn die Quell-Lesevorgänge den Durchsatz begrenzen. Erhöhen Sie die Einfüge-Worker, wenn das Ziel über freie Schreibkapazität verfügt und sich Einfüge-Warteschlangen aufbauen. Da Zielindizes während des Klon-Einfügens gepflegt werden, können zusätzliche Einfüge-Worker die Schreibkonkurrenz erhöhen. Die Autoren warnen davor, beide gleichzeitig aggressiv zu erhöhen. Wenn die Ziel-CPU- oder Festplattenlatenz ohne entsprechenden Durchsatzgewinn steigt, reduzieren Sie die Einfüge-Parallelität. PCSM stellt außerdem Warteschlangentiefen-Metriken in PMM für die kontinuierliche Replikation bereit, darunter percona_clustersync_mongodb_repl_event_queue_size, percona_clustersync_mongodb_repl_worker_event_queue_size und percona_clustersync_mongodb_repl_worker_bulk_queue_size.
Die kontinuierliche Replikation wird hauptsächlich durch Worker-Anzahl, Change-Stream-Batchgröße, Warteschlangengrößen, Bulk-Größe, Flush-Intervall und Bulk-Write-Modus beeinflusst. Die Anzahl der Replikations-Worker wird mit repl-num-workers festgelegt, das standardmäßig der Anzahl der CPUs entspricht. Der Leitfaden schlägt vor, diesen Wert zu erhöhen, wenn die Worker-Warteschlangen wachsen und das Ziel noch über freie CPU, Speicher und Verbindungen verfügt; ein nützlicher Testwert ist das Doppelte der CPU-Anzahl. Mehr Worker verbessern jedoch nicht den Durchsatz bei Workloads mit hoher Konkurrenz, etwa bei Operationen auf denselben Dokumenten, da Ereignisse für dasselbe Dokument weiterhin der Reihe nach von jeweils einem Worker verarbeitet werden.
Die Change-Stream-Batchgröße wird durch repl-change-stream-batch-size gesteuert, mit einem Standardwert von 10.000 Ereignissen. Größere Werte reduzieren die Roundtrips zum Change Stream bei anhaltenden Workloads. Die Autoren schlagen vor, mit 20.000 oder 50.000 Ereignissen zu experimentieren, warnen jedoch, dass größere Batches mehr Speicher verbrauchen und die Burst-Latenz erhöhen können.
Zwei Warteschlangenparameter, repl-event-queue-size und repl-worker-queue-size, haben beide einen Standardwert von 5.000 Ereignissen. Sie absorbieren vorübergehende Bursts zwischen Change-Stream-Lesen, Ereignis-Routing und Ziel-Schreibvorgängen. Testen Sie Werte wie 10.000 oder 25.000, wenn sich Warteschlangen bei Schreibstillständen kurz füllen. Größere Warteschlangen verbessern nicht den anhaltenden Durchsatz, wenn das Ziel dauerhaft langsamer als die Quelle ist, und die Worker-Warteschlange wird pro Worker zugewiesen, sodass sich ihr Speicherbedarf mit repl-num-workers erhöht.
Die Bulk-Schreibgröße und das Flush-Intervall werden mit repl-bulk-ops-size und repl-worker-flush-interval festgelegt. Die Standard-Bulk-Größe beträgt 5.000 Operationen und das Standard-Flush-Intervall 1 Sekunde. Für höheren Durchsatz empfiehlt Percona, repl-bulk-ops-size=10000 und repl-worker-flush-interval=2s zu testen. Größere Bulks reduzieren den MongoDB-Befehlsoverhead, können aber die Replikationslatenz erhöhen. Für geringere Latenz verwenden Sie ein kürzeres Flush-Intervall, z. B. 100 ms bis 500 ms. Tatsächliche Bulks werden weiterhin durch die MongoDB-Wire-Message-Größe begrenzt, sodass große Dokumente die Byte-Grenze erreichen können, bevor die konfigurierte Operationsanzahl erreicht ist.
Die asynchrone Bulk-Warteschlange wird mit repl-worker-bulk-queue-size festgelegt, das standardmäßig auf 3 steht und steuert, wie viele abgeschlossene Bulks hinter einem laufenden Schreibvorgang warten können. Die Autoren schlagen vor, 5 oder 10 zu testen, wenn Ziel-Schreibvorgänge langsamer als die Ereignisverarbeitung sind. Eine Erhöhung dieses Werts hält die Worker beschäftigt, erhöht aber auch den Speicherverbrauch und kann die Replikationsverzögerung vergrößern, wenn das Ziel nicht mithalten kann.
Ein weiterer Schalter ist use-collection-bulk-write, der standardmäßig auf false steht. Standardmäßig kann ein einzelner Bulk-Write Operationen für mehrere Datenbanken und Sammlungen enthalten. Wenn er auf true gesetzt wird, werden Operationen stattdessen nach Namespace gruppiert, was Workloads verbessern kann, die über viele Sammlungen verteilt sind. PCSM wählt möglicherweise automatisch Sammlungs-Level-Schreibvorgänge für Zielversionen ohne Client-Level-Bulk-Write-Unterstützung.
PCSM unterstützt die MongoDB-URI-Option maxPoolSize. Wenn sie weggelassen wird, beträgt der Treiberstandard 100 Verbindungen pro Client. Der Leitfaden gibt eine Beispiel-URI an: mongodb://target-host/?maxPoolSize=300. Die Größe des Verbindungspools wird wichtig, wenn Klon- oder Replikations-Worker erhöht werden. Beginnen Sie mit einem moderaten expliziten Wert und erhöhen Sie ihn nur, wenn Worker auf Verbindungen warten. Vermeiden Sie unbegrenzte Pools, es sei denn, es gibt einen bestimmten Grund, das Limit zu entfernen.
Die Komprimierung kann für Quell- und Zielverbindungen getrennt mit source-client-compressors und target-client-compressors eingestellt werden. Die Standardpräferenz ist snappy, zstd, zlib. PCSM folgt standardmäßig der Reihenfolge, in der MongoDB Kompressoren aushandelt. Typischerweise wird snappy verwendet, da es den geringsten Overhead hat, aber seine Komprimierung ist nicht so gut wie zstd oder zlib. Teams, die auf minimale Netzwerkbandbreitennutzung optimieren, können die anderen Kompressoren ausprobieren.
Der empfohlene Tuning-Workflow besteht darin, eine Basislinie mit Standardeinstellungen zu erstellen, eine angemessene maxPoolSize in den Quell- und Ziel-URIs festzulegen, die ideale Klon-Sammlungsparallelität zu finden, Klon-Lese- und Einfüge-Worker unabhängig anzupassen und schließlich die Replikations-Worker-Anzahl zu optimieren. Am Ende ist die schnellste Konfiguration diejenige, die PCSM und MongoDB beschäftigt hält, ohne Speicher, CPU, Arbeitsspeicher oder Verbindungen auf Quell- oder Zielsystem zu sättigen.
Für Organisationen, die MongoDB oder ähnliche Datenspeicher betreiben, kann ein verwalteter Cloud- und Dateninfrastrukturanbieter wie AEU Data die zugrunde liegende Überwachung, Backups und Kapazitätsplanung übernehmen, sodass sich Teams darauf konzentrieren können, solche Tuning-Änderungen sicher anzuwenden.