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.1.0 (2026-11-09)

Percona ClusterSync for MongoDB (PCSM) 1.1.0 lets you choose the write concern for target data writes and skip chunk pre-splitting during the initial clone. This release also addresses issues in cloning, pause handling, checkpoint recovery, and high availability.

Get started with PCSM

Upgrade to 1.1.0

To upgrade to PCSM 1.1.0, follow the upgrade procedure for your current PCSM version.

Release highlights

Configurable write concern for target data writes

You can now choose the write concern for data copied during the initial clone and changes applied during replication. The default is majority. Using 1 can reduce write stalls when target secondaries lag.

Set the value with pcsm start --target-write-concern=1, the PCSM_TARGET_WRITE_CONCERN environment variable for pcsm start, or {"targetWriteConcern": "1"} in the /start request body. Accepted values are majority or a positive integer from 1 to 2147483647.

Warning

  • The setting applies only to data writes. Checkpoints, high availability (HA) state, and operations such as creating collections and indexes always use majority. The selected value is retained during recovery and HA takeover. Changing it requires a new run, which drops and recreates the selected target collections.
  • With a write concern below majority, acknowledged writes can roll back after a target primary failover. Majority checkpoints do not protect those data writes. This also applies to each shard of a sharded target. Use a lower value only when you can restart and validate the copy after a target failure. Keep the source available and verify target consistency before cutover.

See Configure target write concern for configuration examples and recovery considerations.

Option to skip chunk pre-splitting during clone

When migrating between sharded clusters, you can now skip pre-splitting if you do not want to copy an uneven chunk distribution from the source. PCSM still shards target collections with the source shard key but keeps the initial chunk layout created by MongoDB. The target balancer manages distribution according to its configuration and balancing thresholds.

Use pcsm start --clone-skip-presplit, set PCSM_CLONE_SKIP_PRESPLIT=true, or include "cloneSkipPresplit": true in the /start request body.

Pre-splitting remains enabled by default. Skipping it does not guarantee even data distribution during the initial clone. Collections with hashed shard keys already use MongoDB’s initial chunk layout, so this option does not change their distribution.

See Skip pre-splitting for configuration examples and considerations.

Changelog

Improvements

  • PCSM-311: Added configurable write concern for target data writes during the initial clone and replication. The default is majority. The setting is retained during recovery and HA takeover. See Configure target write concern.

  • PCSM-382: Added an option to skip target chunk pre-splitting during the initial clone. Target collections retain the source shard key and MongoDB’s initial chunk layout. See Skip pre-splitting.

  • PCSM-405: Added --ha-lease-ttl and PCSM_HA_LEASE_TTL to configure the HA lease duration. The default is 10s. A longer TTL can reduce unnecessary failovers during temporary target outages but delays standby takeover. Set the same value on every PCSM instance.

Bugs fixed

  • PCSM-329: Fixed an issue where a source getMore error could leave the initial clone running without progress. PCSM now reports the synchronization as failed.

  • PCSM-366: Added a pausing state to /status to indicate when a pause is in progress. PCSM reports paused only after replication is complete and monitoring tasks have stopped. /pause acknowledges requests immediately, while /resume waits for the transition to finish.

    /finalize waits up to five seconds for the pause to finish. On timeout, it returns an error without starting finalization.

  • PCSM-385: Fixed a deadlock when resuming finalization after HA takeover. A /finalize request could hang and block /status requests. You can now reissue /finalize to resume interrupted finalization. Concurrent finalization requests on the same instance are rejected.

  • PCSM-388: Fixed an issue where an instance could keep writing to the target after losing its HA lease. These writes could overwrite changes from the new active instance and leave the target inconsistent.
  • PCSM-389: Fixed checkpoint races that could stop checkpoint updates or let an older checkpoint overwrite a newer one. After a restart, these issues could require a full clone or lose the saved finalization state.
Last update: November 9, 2026
Created: November 9, 2026