Skip to content

Commit 8886eda

Browse files
Update 0.8.0.md
1 parent aa4be7c commit 8886eda

File tree

1 file changed

+5
-3
lines changed

1 file changed

+5
-3
lines changed

docs/release-notes/0.8.0.md

Lines changed: 5 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -10,7 +10,7 @@ With 3× to 18× faster processing speeds compared to previous versions, PCSM 0.
1010

1111
### Document-level parallel replication
1212

13-
PCSM now introduces document-level parallel replication, significantly improving replication performance under heavy workloads. Previously, change stream events were applied sequentially in a single stream, which caused replication lag to grow indefinitely when write throughput lagged behind read throughput. DML events are distributed among multiple workers based on the hashing of document keys. This approach allows for concurrent processing while maintaining the order of operations for each document.
13+
{{ pcsm.full_name }} now introduces document-level parallel replication, significantly improving replication performance under heavy workloads. Previously, change stream events were applied sequentially in a single stream, which caused replication lag to grow indefinitely when write throughput lagged behind read throughput. DML events are distributed among multiple workers based on the hashing of document keys. This approach allows for concurrent processing while maintaining the order of operations for each document.
1414

1515
To ensure data consistency, {{pcsm.short}} maintains ordering for DDL operations using a write barrier. When a DDL event is encountered, all workers flush their pending operations before the DDL is applied, ensuring correct execution order.
1616

@@ -24,7 +24,7 @@ For more information, see our [documentation](https://docs.percona.com/percona-c
2424

2525
### Async bulk write pipeline
2626

27-
PCSM now improves replication throughput by allowing bulks to be pre‑populated while writes are in progress. Previously, event processing would stall until each bulk write was completed, resulting in filled queues and slowed synchronization. With parallel bulk preparation, replication can continue seamlessly. This improvement reduces idle time and provides faster, more efficient performance under heavy workloads.
27+
{{ pcsm.full_name }} now improves replication throughput by allowing bulks to be pre‑populated while writes are in progress. Previously, event processing would stall until each bulk write was completed, resulting in filled queues and slowed synchronization. With parallel bulk preparation, replication can continue seamlessly. This improvement reduces idle time and provides faster, more efficient performance under heavy workloads.
2828

2929
For more information, see our [documentation](https://docs.percona.com/percona-clustersync-for-mongodb/install/parameters.html#environment-variables).
3030

@@ -63,4 +63,6 @@ For more information, see our [documentation](https://docs.percona.com/percona-c
6363

6464
* [PCSM-257](https://perconadev.atlassian.net/browse/PCSM-257): Fixed an issue where PCSM attempted to recreate a view after encountering transient errors, such as primary stepdowns. In MongoDB 6.0, the view was already created before the error occurred, resulting in a `NamespaceExists` error during the retry. PCSM now correctly handles this situation, preventing replication failures.
6565

66-
* [PCSM-294](https://perconadev.atlassian.net/browse/PCSM-294): Fixed an issue in **Percona ClusterSync for MongoDB (PCSM)** where the service crashed during the change replication phase when handling complex document updates, resulting in **BufBuilder memory exhaustion** and **invalid `$slice` argument errors**. This problem, first observed in customer migrations from **Atlas** to **EKS environments**, has been resolved by improving memory management and validation logic, ensuring stable replication of complex document changes.
66+
* [PCSM-294](https://perconadev.atlassian.net/browse/PCSM-294): Fixed an issue in {{ pcsm.full_name }} that caused crashes during the change replication phase when processing complex document updates, leading to **BufBuilder memory exhaustion** and invalid $`slice` **argument errors**. First observed in customer migrations from **Atlas** to **EKS environments**, this problem has been addressed by enhancing memory management and refining $slice validation, ensuring reliable replication of complex document changes.
67+
68+

0 commit comments

Comments
 (0)