percona · rasika-chivate · Sep 8, 2026 · Sep 8, 2026 · Sep 8, 2026 · Sep 14, 2026
diff --git a/docs/limitations.md b/docs/limitations.md
@@ -4,7 +4,7 @@
 ---
 # Known issues and limitations
 
-This page lists known limitations for using {{pcsm.full_name}}.
+This page lists known limitations for using {{pcsm.full_name}} (PCSM).
 
 ## Versions and topology
 
@@ -28,13 +28,12 @@
 
 The following limitations apply specifically to sharded cluster replication:
 
-* {{pcsm.short}} replicates the data and doesn't replicate metadata. This means that the following information is not preserved from the source cluster:
-
-   * The primary shard name for a collection. The target cluster may have a different primary shard name.
-   * The chunk distribution information. The target cluster manages chunk distribution according to its own sharding configuration. See [Sharding support](sharding.md#limitations) for more information.
-   * The configuration of [zones for sharded data :octicons-link-external-16:](https://www.mongodb.com/docs/manual/core/zone-sharding/).
-
-* During data replication, the following commands are not supported: `movePrimary`, `reshardCollecton`, `unshardCollection`, `refineCollectionShardKey`. Running them results in failed replication and you must start it anew, from the initial data sync stage.
+* When both the source and target are sharded clusters, {{pcsm.short}} does not continuously replicate sharding metadata. For ranged shard keys, PCSM uses the source chunk boundaries to initialize the target during the initial sync. Subsequent chunk migrations, splits, and merges aren't reproduced on the target.
+* The primary shard assignment is not preserved. The target cluster can use a different primary shard.
+* Zone configuration is not replicated. See [Zones for sharded data :octicons-link-external-16:](https://www.mongodb.com/docs/manual/core/zone-sharding/).
+* Don't reshard a collection during an active synchronization.
+  Running `reshardCollection`, `unshardCollection`, or `refineCollectionShardKey` on a collection included in an active synchronization puts PCSM into a failure state. Complete or stop the synchronization first.
+* Replica set to sharded cluster migrations do not apply a shard key. PCSM can copy data from a replica set source to a sharded cluster target, but the migrated collections remain unsharded. If you need sharded collections on the target, apply the required shard key separately.
 
 ## Data types
 
@@ -50,12 +49,9 @@
 
 ## Other
 
-The following functionalities are not supported:
+The following limitations apply:
 
-* Multiple source or multiple target clusters 
-* You cannot resume initial synchronization if an issue occurred. You must start it from scratch.
+* You cannot resume the clone phase after it fails. Resolve the issue and start a new synchronization run from the beginning.
 * Arbitrary database upgrades during a sync are not supported. For supported staged upgrades from lower to higher MongoDB major versions, follow the cross-version replication procedure.
-* Reverse synchronization
-* External authentication via Kerberos, AWS and LDAP
-
-
+* Reverse synchronization, from the target cluster back to the source, is not supported.
+* External authentication through Kerberos, LDAP, and AWS IAM is not supported.
diff --git a/docs/release-notes.md b/docs/release-notes.md
@@ -4,6 +4,8 @@
 
     Starting with version 0.7.0, Percona Link for MongoDB has been rebranded as Percona ClusterSync for MongoDB. Any mentions of Percona Link for MongoDB in earlier release notes now refer to this product.
 
+* [Percona ClusterSync for MongoDB 0.10.0 ({{date.v0_10_0}})](release-notes/0.10.0.md)
+
 * [Percona ClusterSync for MongoDB 0.9.0 ({{date.v0_9_0}})](release-notes/0.9.0.md)
 
 * [Percona ClusterSync for MongoDB 0.8.1 ({{date.v0_8_1}})](release-notes/0.8.1.md)

diff --git a/docs/release-notes/0.10.0.md b/docs/release-notes/0.10.0.md
@@ -0,0 +1,85 @@
+# {{ pcsm.full_name }} 0.10.0 ({{ date.v0_10_0 }})
+
+We’re excited to announce {{ pcsm.full_name }} (PCSM) 0.10.0. This release adds high availability during replication and expands migration support for sharded deployment scenarios. You can also 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.short}}](../installation.md){.md-button}
+
+!!! warning "Upgrade from 0.9.0 requires a reset"
+
+    PCSM `0.10.0` cannot use replication state created by PCSM `0.9.0`. Before upgrading, **stop all** `0.9.0` instances and reset the stored replication state on the target cluster. 
+
+    After the reset, start a new synchronization run with PCSM `0.10.0`. The run starts with a full initial clone. Do not run PCSM `0.9.0` and `0.10.0` against the same target cluster at the same time.
+
+## Release highlights
+
+### High availability during replication
+
+PCSM now supports active-standby high availability during replication. For example you can run two or more instances of PCSM with the same source and target. While one of them is actively replicating the others are idle in standby mode. 
+
+In the event of an active instance failure, one of the passive instances will take over. Replication will then continue from the last checkpoint to minimize disruption without manual intervention.
+
+For detailed information, see our [documentation](https://docs.percona.com/percona-clustersync-for-mongodb/high-availability.html)
+
+
+### Broader migration support for sharded clusters
+
+PCSM can now migrate collection data from a sharded source cluster to a replica set target. It copies documents from both sharded and unsharded collections. Sharded collections are created as regular collections on the replica set target, without the source cluster's sharding metadata.
+
+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.
+
+To dive deeper into this topic, check out the [documentation](https://docs.percona.com/percona-clustersync-for-mongodb/sharding.html#chunk-distribution).
+
+
+### Parallel synchronization from one source to multiple targets
+
+You can run multiple {{pcsm.full_name}} (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. Namespace selections can differ or overlap. This means the same source namespace can be synchronized to more than one target when needed.
+
+For more insights into this feature, see the [documentation](https://docs.percona.com/percona-clustersync-for-mongodb/multiple-targets.html)
+
+### Extended platform support: Red Hat Enterprise Linux (RHEL) 10 and its derivatives, and Debian 13
+
+PCSM 0.10.0 adds packages for new platforms, including RHEL 10 and its derivatives, and Debian 13.
+
+| **Platform** | **Derivative of** | **Architecture** |
+|---|---|---|
+| RHEL 10 | — | x86_64, ARM64 |
+| Rocky Linux 10 | RHEL 10 | x86_64, ARM64 |
+| AlmaLinux 10 | RHEL 10 | x86_64, ARM64 |
+| Oracle Linux 10| RHEL 10 | x86_64, ARM64 |
+| Debian 13 (Trixie) | — | x86_64, ARM64 |
+
+## Changelog
+
+### New features
+
+* [PCSM-203](https://perconadev.atlassian.net/browse/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](https://perconadev.atlassian.net/browse/PCSM-296): Added support for migrating data from a sharded source cluster to a replica set target.
+* [PCSM-302](https://perconadev.atlassian.net/browse/PCSM-302): Added Debian 13 (Trixie) AMD64 support for PCSM.
+* [PCSM-344](https://perconadev.atlassian.net/browse/PCSM-344): Added Debian 13 (Trixie) ARM64 support for PCSM.
+* [PCSM-360](https://perconadev.atlassian.net/browse/PCSM-360): Added RHEL 10 build support for PCSM.
+
+### Improvements
+
+* [PCSM-93](https://perconadev.atlassian.net/browse/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](https://perconadev.atlassian.net/browse/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](https://perconadev.atlassian.net/browse/PCSM-281): Updated the Go version used to build PCSM to 1.27.1.
+* [PCSM-283](https://perconadev.atlassian.net/browse/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](https://perconadev.atlassian.net/browse/PCSM-312): Added support for configuring the MongoDB connection pool size using `maxPoolSize` in the source and target connection strings.
+* [PCSM-322](https://perconadev.atlassian.net/browse/PCSM-322): Improved handling of incomplete or inconsistent source indexes during finalization.
+* [PCSM-328](https://perconadev.atlassian.net/browse/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](https://perconadev.atlassian.net/browse/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](https://perconadev.atlassian.net/browse/PCSM-335): Updated log timestamps to use RFC 3339 format, making timestamps easier to correlate with logs from other systems.
+* [PCSM-336](https://perconadev.atlassian.net/browse/PCSM-336): Normalized PCSM log timestamps to UTC for consistent timestamps across deployments.
+
+### Bugs
+
+* [PCSM-249](https://perconadev.atlassian.net/browse/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](https://perconadev.atlassian.net/browse/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](https://perconadev.atlassian.net/browse/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](https://perconadev.atlassian.net/browse/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](https://perconadev.atlassian.net/browse/PCSM-369): The `--mongodb-operation-timeout` flag was accepted by every subcommand, but only the server and `reset` commands actually create MongoDB clients. Passing it to `pcsm start` or `pcsm status` did nothing at all, with no indication that the value had been discarded.
+
+      The flag is now scoped to the commands that use it. If you pass it to `status`, `start`, `pause`, `resume`, or `finalize`, PCSM returns an unknown flag error rather than accepting it and ignoring it.
+
diff --git a/docs/sharding.md b/docs/sharding.md
@@ -44,9 +44,9 @@
 
 ### Chunk distribution
 
-{{pcsm.short}} does not preserve chunk distribution information from the source cluster. The target cluster manages chunk distribution internally through its balancer. This means that after replication, chunks may be distributed differently on the target cluster compared to the source cluster, which is expected behavior.
+For migrations between sharded clusters, {{pcsm.short}} prepares the target chunk layout before cloning data. For ranged shard keys, it uses source chunk boundaries to pre-split the target. Collections with a hashed shard key keep the initial layout created by MongoDB.
 
-Since the target cluster already has information about which collections are sharded, it handles sharding internally. {{pcsm.short}} does not interfere with the target cluster's sharding configuration or chunk distribution.
+The target cluster's balancer continues to manage chunk placement. This means chunk distribution may still differ between source and target after replication, which is expected behavior.
 
 ## Usage
 

diff --git a/mkdocs-base.yml b/mkdocs-base.yml
@@ -192,6 +192,7 @@ nav:
   - FAQ: faq.md
   - Release notes:
       - Release notes index: release-notes.md
+      - 0.10.0: release-notes/0.10.0.md
       - 0.9.0: release-notes/0.9.0.md
       - 0.8.1: release-notes/0.8.1.md
       - 0.8.0: release-notes/0.8.0.md

diff --git a/variables.yml b/variables.yml
@@ -2,9 +2,10 @@
 # See also mkdocs.yml plugins.with-pdf.cover_subtitle and output_path
 
 year: '2026'
-release: '0.9.0'
+release: '0.10.0'
 
 date:
+   v0_10_0: '2026-09-15'
    v0_9_0: '2026-06-03'
    v0_8_1: '2026-05-07'
    v0_8_0: '2026-04-06'