Skip to content
Percona Software for MongoDB Documentation

Rate this page
☆ ☆ ☆ ☆ ☆
Thanks for your feedback
Thank you! The feedback has been submitted.

For help, click the link below to get free database assistance or contact our experts for personalized support.

Get help from Percona

Percona ClusterSync for MongoDB 1.0.0 (2026-09-28)

We are thrilled to unveil the latest release of Percona ClusterSync for MongoDB (PCSM) 1.0.0. This release marks the general availability of sharding support, introduces active-standby high availability during replication, and expands the supported migration topologies. It also allows you to run multiple PCSM instances against the same source cluster, with each instance synchronizing a different subset of data to a separate target.

Get started with PCSM

Upgrading from an earlier version requires a reset

PCSM 1.0.0 cannot use replication state created by an earlier PCSM version. Before upgrading, stop all instances of the earlier version and reset the stored replication state on the target cluster.

After the reset, start a new synchronization run with PCSM 1.0.0. The run begins with a full initial clone. Do not run PCSM 1.0.0 and an earlier version against the same target cluster at the same time.

Release highlights

Sharding support is now generally available

Starting with PCSM 1.0.0, sharding support is generally available (GA). PCSM supports migrations from a sharded source cluster to another sharded cluster or to a replica set target.

When migrating to a replica set, PCSM copies documents from both sharded and unsharded collections. It creates sharded collections as regular collections on the target, without the source cluster’s sharding metadata.

For migrations between sharded clusters, PCSM prepares the target chunk layout before cloning data. For ranged shard keys, it uses the source chunk boundaries to pre-split the target. Collections with a hashed shard key keep the initial layout created by MongoDB.

For more information, see sharding support.

High availability during replication

PCSM now supports active-standby high availability during replication. You can run two or more instances of PCSM with the same source and target. One instance handles replication while the others remain in standby mode.

If the active instance becomes unavailable, a standby instance takes over automatically. Replication resumes from the last checkpoint to minimize disruption without manual intervention.

For detailed information, see the documentation.

Parallel synchronization from one source to multiple targets

You can run multiple Percona ClusterSync for MongoDB (PCSM) instances against the same source cluster and replicate data to different target clusters at the same time.

Each instance has its own namespace filters, so you can control which data is sent to each target. The selected namespaces can differ or overlap, so the same source namespace can be synchronized to more than one target.

For more insights into this feature, see the documentation.

Extended platform support

PCSM 1.0.0 adds packages for new platforms, including RHEL 10 and its derivatives, and Debian 13.

Platform Architecture
RHEL 10 x86_64, ARM64
Rocky Linux 10 x86_64, ARM64
AlmaLinux 10 x86_64, ARM64
Oracle Linux 10 x86_64, ARM64
Debian 13 (Trixie) x86_64, ARM64

Changelog

New features

  • PCSM-203: For migrations between sharded clusters, PCSM now prepares the target chunk layout before cloning data. For ranged shard keys, it uses the source chunk boundaries to pre-split the target. Collections with a hashed shard key keep the initial layout created by MongoDB.
  • PCSM-296: Added support for migrating data from a sharded source cluster to a replica set target.
  • PCSM-302: Added Debian 13 (Trixie) AMD64 support for PCSM.
  • PCSM-344: Added Debian 13 (Trixie) ARM64 support for PCSM.
  • PCSM-360: Added RHEL 10 build support for PCSM.

Improvements

  • PCSM-93: Added active-standby high availability for the replication phase. Multiple PCSM instances coordinate through a lease on the target cluster, and a standby is promoted automatically when the active instance becomes unavailable.
  • PCSM-241: Improved how PCSM captures the clone start timestamp. PCSM now uses appendOplogNote to establish a precise replication starting point after earlier in-flight writes are durable.
  • PCSM-281: Updated the Go version used to build PCSM to 1.27.1.
  • PCSM-283: Improved migrations from a sharded source cluster to a replica set target. PCSM now detects the target topology and skips sharding operations that a replica set does not support.
  • PCSM-312: Added support for configuring the MongoDB connection pool size using maxPoolSize in the source and target connection strings.
  • PCSM-322: Improved handling of incomplete or inconsistent source indexes during finalization.
  • PCSM-328: Improved migration reliability by retrying MongoDB operations that fail because of transient errors, such as brief network interruptions or timeouts. Previously, a temporary source-side failure could stop a long-running initial data copy. PCSM now retries these operations before failing the migration.
  • PCSM-330: Added support for running multiple PCSM instances against the same source cluster and synchronizing selected data to separate target clusters at the same time. Each instance can use its own namespace filters.
  • PCSM-335: Updated log timestamps to use RFC 3339 format, making them easier to correlate with logs from other systems.
  • PCSM-336: Normalized PCSM log timestamps to UTC for consistent timestamps across deployments.

Bugs fixed

  • PCSM-249: Fixed handling of change stream events generated by movePrimary on a sharded source. These events could previously cause replicated data to be removed from the target or stop replication. PCSM now handles them without applying the internal collection changes to the target.
  • PCSM-338: Fixed an issue where PCSM could incorrectly report the initial sync as complete after restarting during catch-up. This might allow finalization to begin before the target has fully caught up, resulting in data loss. PCSM now preserves the clone completion timestamp during recovery and prevents finalization until synchronization is complete.
  • PCSM-345: Made the PCSM HTTP server bind host configurable. Previously, the server bound only to localhost, which could prevent Kubernetes probes or other services connecting through the pod or host IP from reaching PCSM. The default remains localhost.
  • PCSM-359: Fixed an issue where PCSM could advance its replication checkpoint past changes that had not yet been applied. If PCSM restarted during catch-up, those changes could be skipped and documents could be missing from the target. PCSM now resumes an interrupted run from the last safely applied checkpoint.
  • PCSM-369: Restricted the --mongodb-operation-timeout flag to the root pcsm command, which starts the PCSM server, and the reset command. Previously, other commands accepted the flag but silently ignored its value. The start, status, pause, resume, and finalize commands now return an unknown flag error when this flag is provided.
  • PCSM-367: Fixed an issue where an empty change-stream batch could reset the replication lag after the initial clone while events remained unapplied. This could cause initialSync.completed to become true before catch-up finished, allowing finalization to begin early and potentially resulting in data loss. Empty batches no longer count as applied replication progress.
  • PCSM-383: Fixed reported lag that grew after the initial clone. The applied timestamp stayed static during catch-up while PCSM worked through the oplog collected at clone time, so the lag value increased and suggested that PCSM had fallen behind. The timestamp now advances as catch-up progresses, and reported lag shows how far the applied oplog trails the source.
Last update: September 28, 2026
Created: September 28, 2026