Parametri chiave che accelerano Percona ClusterSync per MongoDB
Percona ha pubblicato una guida dettagliata alla messa a punto di Percona ClusterSync per MongoDB (PCSM), uno strumento di sincronizzazione che copia i dati da un cluster MongoDB di origine a un cluster di destinazione. Il post del blog, scritto da Ivan Groenewold e Adnan Supic e pubblicato il 1° ottobre 2026, spiega quali parametri contano per le due fasi del processo di sincronizzazione e suggerisce valori di partenza per i test. PCSM crea innanzitutto un punto di partenza coerente clonando le collezioni e gli indici esistenti, catturando al contempo le modifiche dell'origine tramite i change stream di MongoDB, un feed in tempo reale delle operazioni del database. Una volta completata la copia iniziale, PCSM applica le modifiche catturate finché la destinazione non raggiunge l'origine. Le ultime modifiche architetturali introducono diversi nuovi parametri per migliorare la velocità di clonazione iniziale e il throughput di replica continua.
Gli autori consigliano di procedere gradualmente con la messa a punto e di osservare CPU, disco, utilizzo di rete, numero di connessioni e ritardo di replica di origine e destinazione dopo ogni modifica. Raccomandano di usare Percona Monitoring and Management (PMM), uno strumento di monitoraggio, per identificare i colli di bottiglia e di tenere d'occhio le stesse metriche per l'host che esegue PCSM. Questo approccio misurato evita che una modifica di messa a punto saturi storage o connessioni.
La fase di clonazione iniziale è influenzata principalmente dal parallelismo delle collezioni, dai worker di lettura e inserimento, dalla dimensione del segmento e dalla dimensione del batch di lettura. Questi valori vengono configurati all'avvio del processo PCSM. Il parallelismo delle collezioni è controllato da clone-num-parallel-collections, che ha un valore predefinito di 2, un'impostazione conservativa che limita il numero di collezioni clonate contemporaneamente. Percona consiglia di aumentarlo quando l'origine ha molte collezioni e quando sia l'origine che la destinazione hanno capacità di CPU e disco inutilizzate. Un punto di partenza ragionevole è 4 collezioni parallele per core CPU, per poi testare valori più alti finché la destinazione non è satura. Un parallelismo eccessivo aumenterà la contesa del disco e l'utilizzo delle connessioni.
La fase di clonazione utilizza anche clone-num-read-workers e clone-num-insert-workers. Il valore predefinito per i worker di lettura è max(NumCPU/4, 1), mentre quello per i worker di inserimento è NumCPU moltiplicato per 2. I worker di lettura recuperano i documenti dall'origine, mentre i worker di inserimento scrivono i batch nella destinazione. Aumentare i worker di lettura quando le letture dall'origine limitano il throughput. Aumentare i worker di inserimento quando la destinazione ha capacità di scrittura disponibile e le code di inserimento si stanno accumulando. Poiché gli indici della destinazione vengono mantenuti durante gli inserimenti del clone, worker di inserimento aggiuntivi possono aumentare la contesa di scrittura. Gli autori mettono in guardia dall'aumentare entrambi in modo aggressivo contemporaneamente. Se la CPU o la latenza del disco della destinazione aumentano senza un corrispondente guadagno di throughput, ridurre la concorrenza di inserimento. PCSM espone anche metriche di profondità della coda in PMM per la replica continua, tra cui percona_clustersync_mongodb_repl_event_queue_size, percona_clustersync_mongodb_repl_worker_event_queue_size e percona_clustersync_mongodb_repl_worker_bulk_queue_size.
La replica continua è influenzata principalmente dal numero di worker, dalla dimensione del batch del change stream, dalle dimensioni delle code, dalla dimensione del bulk, dall'intervallo di flush e dalla modalità di scrittura bulk. Il numero di worker di replica è impostato con repl-num-workers, che ha come valore predefinito il numero di CPU. La guida suggerisce di aumentarlo quando le code dei worker crescono e la destinazione ha ancora CPU, storage e connessioni disponibili; un valore di test utile è il doppio del numero di CPU. Tuttavia, più worker non miglioreranno il throughput per carichi di lavoro ad alta contesa, come le operazioni che riguardano lo stesso insieme di documenti, perché gli eventi per lo stesso documento vengono elaborati in ordine su un singolo worker alla volta.
La dimensione del batch del change stream è controllata da repl-change-stream-batch-size, con un valore predefinito di 10.000 eventi. Valori più grandi riducono i round trip al change stream durante carichi di lavoro sostenuti. Gli autori suggeriscono di sperimentare con 20.000 o 50.000 eventi, ma avvertono che batch più grandi usano più memoria e possono aumentare la latenza di burst.
Due parametri di coda, repl-event-queue-size e repl-worker-queue-size, hanno entrambi un valore predefinito di 5.000 eventi. Assorbono burst temporanei tra la lettura del change stream, l'instradamento degli eventi e le scritture sulla destinazione. Valori di test come 10.000 o 25.000 quando le code si riempiono brevemente durante gli stalli di scrittura. Code più grandi non migliorano il throughput sostenuto se la destinazione è permanentemente più lenta dell'origine, e la coda dei worker è allocata per worker, quindi il suo impatto sulla memoria aumenta con repl-num-workers.
La dimensione del bulk write e l'intervallo di flush sono impostati con repl-bulk-ops-size e repl-worker-flush-interval. La dimensione predefinita del bulk è di 5.000 operazioni e l'intervallo di flush predefinito è di 1 secondo. Per un throughput più elevato, Percona consiglia di testare repl-bulk-ops-size=10000 e repl-worker-flush-interval=2s. Bulk più grandi riducono l'overhead dei comandi MongoDB ma possono aumentare la latenza di replica. Per una latenza inferiore, usare un intervallo di flush più breve, ad esempio da 100 ms a 500 ms. I bulk effettivi sono comunque limitati dalla dimensione del messaggio wire di MongoDB, quindi documenti di grandi dimensioni potrebbero raggiungere il limite di byte prima del conteggio di operazioni configurato.
La coda bulk asincrona è impostata con repl-worker-bulk-queue-size, che ha un valore predefinito di 3 e controlla quanti bulk completati possono attendere dietro una scrittura in corso. Gli autori suggeriscono di testare 5 o 10 quando le scritture sulla destinazione sono più lente dell'elaborazione degli eventi. Aumentare questo valore mantiene i worker occupati ma aumenta anche l'uso della memoria e potrebbe consentire al ritardo di replica di crescere quando la destinazione non riesce a tenere il passo.
Un'altra opzione è use-collection-bulk-write, che è false per impostazione predefinita. Per impostazione predefinita, un singolo bulk write può contenere operazioni per più database e collezioni. Impostandolo su true, le operazioni vengono raggruppate per namespace, il che può migliorare i carichi di lavoro distribuiti su molte collezioni. PCSM può selezionare automaticamente scritture a livello di collezione per versioni di destinazione senza supporto per bulk write a livello di client.
PCSM supporta l'opzione URI di MongoDB maxPoolSize. Se omessa, il valore predefinito del driver è di 100 connessioni per client. La guida fornisce un URI di esempio: mongodb://target-host/?maxPoolSize=300. Il dimensionamento del pool di connessioni diventa importante quando si aumentano i worker di clonazione o replica. Iniziare con un valore esplicito moderato e aumentarlo solo quando i worker sono in attesa di connessioni. Evitare pool illimitati a meno che non ci sia un motivo specifico per rimuovere il limite.
La compressione può essere regolata separatamente per le connessioni di origine e destinazione con source-client-compressors e target-client-compressors. La preferenza predefinita è snappy, zstd, zlib. PCSM corrisponde all'ordine in cui MongoDB negozia i compressori per impostazione predefinita. In genere si usa snappy perché ha l'overhead più basso, ma la sua compressione non è buona come quella di zstd o zlib. I team che ottimizzano per il minor utilizzo possibile di larghezza di banda di rete possono provare gli altri compressori.
Il flusso di lavoro di messa a punto consigliato consiste nello stabilire una baseline con le impostazioni predefinite, impostare un maxPoolSize appropriato sugli URI di origine e destinazione, trovare il parallelismo ideale di clonazione delle collezioni, regolare indipendentemente i worker di lettura e inserimento del clone e infine mettere a punto il numero di worker di replica. Alla fine, la configurazione più veloce è quella che mantiene PCSM e MongoDB occupati senza saturare storage, CPU, memoria o connessioni né sull'origine né sulla destinazione.
Per le organizzazioni che eseguono MongoDB o archivi dati simili, un provider gestito di cloud e infrastruttura dati come AEU Data può occuparsi del monitoraggio, dei backup e della pianificazione della capacità sottostanti, così i team possono concentrarsi sull'applicare in sicurezza modifiche di messa a punto come queste.