<!-- mobian-agent-page publisher="dailydev" canonical="https://daily.dev/posts/percona-clustersync-for-mongodb-goes-highly-available-active-standby-failover-i9pcaezq8" -->

---
title: Percona ClusterSync for MongoDB Goes Highly Available:...
description: Percona ClusterSync for MongoDB (PCSM) 1.0.0 introduces built-in active-standby high availability for the change-stream replication phase, eliminating the...
canonical: https://daily.dev/posts/percona-clustersync-for-mongodb-goes-highly-available-active-standby-failover-i9pcaezq8
twitter:card: summary_large_image
twitter:site: @dailydotdev
og:type: website
og:site_name: daily.dev
og:title: Percona ClusterSync for MongoDB Goes Highly Available: Active-Standby Failover | daily.dev
og:description: Percona ClusterSync for MongoDB (PCSM) 1.0.0 introduces built-in active-standby high availability for the change-stream replication phase, eliminating the...
og:url: https://daily.dev/posts/percona-clustersync-for-mongodb-goes-highly-available-active-standby-failover-i9pcaezq8
og:image: https://api.daily.dev/og/posts/i9PcAEzq8.png
og:image:alt: Percona ClusterSync for MongoDB Goes Highly Available: Active-Standby Failover
og:image:width: 1200
og:image:height: 630
og:locale: en
---

> ## Documentation Index
> Fetch the complete documentation index at: https://daily.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Percona ClusterSync for MongoDB Goes Highly Available: Active-Standby Failover

**[Percona Blog](https://daily.dev/sources/percona)** · 6 min read · 0 upvotes · 0 comments

## Summary

Percona ClusterSync for MongoDB (PCSM) 1.0.0 introduces built-in active-standby high availability for the change-stream replication phase, eliminating the previous single point of failure. Multiple PCSM instances can now run against the same source and target clusters, coordinating through a MongoDB-backed lease on the target cluster. Lease-based election, term fencing, and checkpoint-based recovery make failover safe, with a hard-killed ACTIVE replaced within roughly the 10-second lease TTL. HA metrics and a Grafana dashboard are provided for monitoring. The initial clone phase is not yet resumable, and replication state from 0.9.0 is incompatible with 1.0.0, requiring a state reset before upgrading.

## Full article

daily.dev links to this article rather than hosting it. Read it at the original source: <https://www.percona.com/blog/percona-clustersync-for-mongodb-goes-highly-available-active-standby-failover>

## Questions this post answers

### What's new in Percona ClusterSync for MongoDB 1.0.0?

Version 1.0.0 adds built-in active-standby high availability for the change-stream replication phase, removing the prior single point of failure. Multiple instances can run against the same source and target, coordinating through a MongoDB-backed lease on the target cluster; exactly one is ACTIVE and replicates while others stay STANDBY and take over automatically when the lease expires.

_daily.dev surfaces release notes like this for teams planning MongoDB migration tooling upgrades._

### How does Percona ClusterSync for MongoDB prevent a stalled active instance from corrupting data during failover?

It uses term fencing: a monotonic fencing token increments on every election and is stamped into every checkpoint write. If a stalled or zombie ACTIVE wakes up and tries to write with a stale term, the target rejects the write, causing that instance to self-demote to STANDBY, so the new ACTIVE's state is never corrupted.

_Engineers designing failover-safe replication follow distributed-systems patterns like this via daily.dev._

### Is replication state compatible between Percona ClusterSync for MongoDB 0.9.0 and 1.0.0?

No, replication state from 0.9.0 is not compatible with 1.0.0. Operators must run pcsm reset against the target before starting replication with the new version, since the upgrade introduces incompatible HA coordination state such as the lease and member documents.

_Teams upgrading database migration tools track breaking changes like this through daily.dev._

## Similar posts on daily.dev

- [Migrating from MongoDB 6.0 to 8.0: How Percona ClusterSync Handles Cross-Version Replication](https://daily.dev/posts/migrating-from-mongodb-6-0-to-8-0-how-percona-clustersync-handles-cross-version-replication-xy8u0qodj) · Percona Blog · 1 upvotes · 1 comments
- [Percona Operator for MongoDB 1.23.0: ClusterSync Migration, Vector Search, and PVC Snapshot Backups](https://daily.dev/posts/percona-operator-for-mongodb-1-23-0-clustersync-migration-vector-search-and-pvc-snapshot-backups-x0aki6ink) · Percona Blog · 0 upvotes · 0 comments
- [How We Built an Automated, Production-Ready Sharded MongoDB Infrastructure](https://daily.dev/posts/how-we-built-an-automated-production-ready-sharded-mongodb-infrastructure-n1vi9g1lo) · Trendyol Tech · 1 upvotes · 0 comments
- [Multi-Cluster databases on Kubernetes: Architecture and deployment](https://daily.dev/posts/multi-cluster-databases-on-kubernetes-architecture-and-deployment-yats0aq1j) · CNCF · 1 upvotes · 0 comments
- [When failover isn’t safe: Building high-availability PostgreSQL on Kubernetes](https://daily.dev/posts/when-failover-isn-t-safe-building-high-availability-postgresql-on-kubernetes-nljmhojvb) · Datadog · 4 upvotes · 1 comments

---

Tags: [#database](https://daily.dev/tags/database), [#mongodb](https://daily.dev/tags/mongodb), [#distributed-systems](https://daily.dev/tags/distributed-systems)

[View this post on daily.dev](https://daily.dev/posts/percona-clustersync-for-mongodb-goes-highly-available-active-standby-failover-i9pcaezq8)

```json
{"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]}
{"@context":"https://schema.org","@type":"TechArticle","headline":"Percona ClusterSync for MongoDB Goes Highly Available: Active-Standby Failover","url":"https://daily.dev/posts/percona-clustersync-for-mongodb-goes-highly-available-active-standby-failover-i9pcaezq8","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/percona-clustersync-for-mongodb-goes-highly-available-active-standby-failover-i9pcaezq8"},"datePublished":"2026-09-30T17:39:42.788Z","dateModified":"2026-09-30T17:40:05.886Z","description":"Percona ClusterSync for MongoDB (PCSM) 1.0.0 introduces built-in active-standby high availability for the change-stream replication phase, eliminating the...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/f6500658469453d3a17719ae31af8184?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/f6500658469453d3a17719ae31af8184?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Percona Blog","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Percona Blog","logo":"https://media.daily.dev/image/upload/s--Lb3XkBh3--/f_auto,q_auto/v1780213412/logos/percona?_a=BAMAMiWQ0","url":"https://daily.dev/sources/percona"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/percona-clustersync-for-mongodb-goes-highly-available-active-standby-failover-i9pcaezq8","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"database,mongodb,distributed-systems","timeRequired":"PT6M"}
{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Percona Blog","item":"https://daily.dev/sources/percona"},{"@type":"ListItem","position":3,"name":"Percona ClusterSync for MongoDB Goes Highly Available: Active-Standby Failover"}]}
{"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/percona-clustersync-for-mongodb-goes-highly-available-active-standby-failover-i9pcaezq8#faq","mainEntity":[{"@type":"Question","name":"What's new in Percona ClusterSync for MongoDB 1.0.0?","acceptedAnswer":{"@type":"Answer","text":"Version 1.0.0 adds built-in active-standby high availability for the change-stream replication phase, removing the prior single point of failure. Multiple instances can run against the same source and target, coordinating through a MongoDB-backed lease on the target cluster; exactly one is ACTIVE and replicates while others stay STANDBY and take over automatically when the lease expires. daily.dev surfaces release notes like this for teams planning MongoDB migration tooling upgrades."}},{"@type":"Question","name":"How does Percona ClusterSync for MongoDB prevent a stalled active instance from corrupting data during failover?","acceptedAnswer":{"@type":"Answer","text":"It uses term fencing: a monotonic fencing token increments on every election and is stamped into every checkpoint write. If a stalled or zombie ACTIVE wakes up and tries to write with a stale term, the target rejects the write, causing that instance to self-demote to STANDBY, so the new ACTIVE's state is never corrupted. Engineers designing failover-safe replication follow distributed-systems patterns like this via daily.dev."}},{"@type":"Question","name":"Is replication state compatible between Percona ClusterSync for MongoDB 0.9.0 and 1.0.0?","acceptedAnswer":{"@type":"Answer","text":"No, replication state from 0.9.0 is not compatible with 1.0.0. Operators must run pcsm reset against the target before starting replication with the new version, since the upgrade introduces incompatible HA coordination state such as the lease and member documents. Teams upgrading database migration tools track breaking changes like this through daily.dev."}}]}
```

