Percona ClusterSync for MongoDB 0.7.0 (2026-01-14)¶
We are excited to announce the general availability (GA) of Percona ClusterSync for MongoDB (PCSM) for data replication across replica sets. The GA status means PCSM has passed the stability and reliability milestones required for enterprise use. You can confidently deploy it in production for data migration across replica sets with near-zero downtime.
This release also introduces data replication in sharded clusters in a tech preview stage. While not yet GA, this feature is available for testing. We encourage you to try it in non‑production environments and share feedback to help shape future improvements.
Release highlights¶
This release provides the following new features and improvements:
Data replication in sharded clusters¶
You can now replicate data between sharded MongoDB clusters or sync data from one sharded deployment to another. This makes it easier to migrate clusters with minimal downtime, set up disaster recovery across sharded environments, or keep data in sync for testing and development.
PCSM connects to mongos in both the source and target sharded clusters. This means clusters can have different numbers of shards, and you don’t need to disable the balancer. Note that PCSM replicates data only, not metadata. That means chunk distribution and the primary shard for a collection may look different between your source and target clusters.
This feature is in the tech preview stage. We don’t recommend using it in production yet, but we encourage you to try it in testing or staging environments and share your feedback. Your input will help us improve and shape the future of Percona ClusterSync for MongoDB.
Learn more about sharding support in our documentation
New deployment options¶
In addition to installing Percona ClusterSync for MongoDB from repositories or building from source, you now have two new options:
- Run PCSM in Docker – quickly spin up a containerized environment with consistent dependencies and easy portability.
- Install from binary tarballs – drop in pre-built binaries for fast setup, even in environments without package managers or container runtimes.
These new deployment methods give you more flexibility to choose the approach that best fits your infrastructure, whether you’re working in cloud-native setups, air‑gapped systems, or lightweight test environments.
Refer to our Quickstart guide for detailed instructions on these new deployment options.
Fine-tune the timeout for MongoDB client operations¶
In smaller and medium‑sized clusters, the default MongoDB client operations timeout of 5 minutes is usually enough to complete data replication. However, in larger clusters, replication could fail if operations like insert, delete, or update take longer than this default limit.
You can now override the default timeout using the PCSM_MONGODB_CLI_OPERATION_TIMEOUT environment variable. This gives you control to extend the timeout when working with large datasets or complex replication tasks, ensuring replication continues smoothly without being interrupted by the 5‑minute limit.
Learn more about this and other available environment variables in our documentation.
Changelog¶
New Feature¶
- PCSM-167 - Improved the status output to include the total number of events and display the time of the last replication operation in human-readable format
- PCSM-195 - Added the ability to clone sharded collections
- PCSM-207 - Expose MongoDB client operation timeout via env variable (Thank you user @balthazar for contributing to this issue)
Improvement¶
- PCSM-238 - Finalization stage logs now include the namespace for each index
Bugs Fixed¶
-
PCSM-185 - Fixed a bug in the
pcsm statuscommand whereinitialSync.lagTimewas incorrectly reported as non-zero value after the initial sync phase was finished. -
PCSM-230 - Fixed the issue with incorrect handling of exclude and include filtered during the filtered sync.
Created: January 13, 2026