<!-- mobian-agent-page publisher="dailydev" canonical="https://daily.dev/posts/multi-cluster-databases-on-kubernetes-architecture-and-deployment-yats0aq1j" -->

---
title: Multi-Cluster databases on Kubernetes: Architecture and...
description: Running a MongoDB replica set across multiple Kubernetes clusters provides resilience against regional failures, corrupted control planes, and network...
canonical: https://daily.dev/posts/multi-cluster-databases-on-kubernetes-architecture-and-deployment-yats0aq1j
twitter:card: summary_large_image
twitter:site: @dailydotdev
og:type: website
og:site_name: daily.dev
og:title: Multi-Cluster databases on Kubernetes: Architecture and deployment | daily.dev
og:description: Running a MongoDB replica set across multiple Kubernetes clusters provides resilience against regional failures, corrupted control planes, and network...
og:url: https://daily.dev/posts/multi-cluster-databases-on-kubernetes-architecture-and-deployment-yats0aq1j
og:image: https://api.daily.dev/og/posts/yatS0Aq1J.png
og:image:alt: Multi-Cluster databases on Kubernetes: Architecture and deployment
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.

# Multi-Cluster databases on Kubernetes: Architecture and deployment

**[CNCF](https://daily.dev/sources/cncf)** · 9 min read · 1 upvotes · 0 comments

## Summary

Running a MongoDB replica set across multiple Kubernetes clusters provides resilience against regional failures, corrupted control planes, and network partitions. The post explains a two-role architecture (Main Site and Replica Site) using the Percona Operator for MongoDB, where the Main Site manages TLS and credentials while Replica Sites run in unmanaged mode. Cross-cluster node discovery is enabled via the Kubernetes Multi-Cluster Services (MCS) API with ServiceExport/ServiceImport resources and a shared svc.clusterset.local DNS zone. To avoid split-brain during a network partition, the recommended topology is the 2+2+1 pattern: two nodes in each of two clusters plus a tiebreaker node in a third location, giving any surviving side a strict majority of 3 out of 5 votes. Failover is automatic via MongoDB's built-in election protocol, typically completing within 12 seconds, though retryable writes are advised to handle the brief window without a Primary. After failover the cluster enters a degraded state with zero fault-tolerance margin until the failed region is restored.

## Full article

daily.dev links to this article rather than hosting it. Read it at the original source: <https://www.cncf.io/blog/2026/07/22/multi-cluster-databases-on-kubernetes-architecture-and-deployment>

## Questions this post answers

### How many voting members do I need to survive a network partition in a multi-region MongoDB replica set?

An odd number of voting members spread across at least three locations is needed, commonly the 2+2+1 pattern: two nodes in a main site, two in a replica site, and one additional voting member in a third location. With five total votes, one side can still reach the majority of three votes to elect a Primary even if the network between the two main sites is severed.

_Anyone architecting resilient databases on Kubernetes can track patterns like this through daily.dev._

### How do I connect MongoDB nodes running in separate Kubernetes clusters into one replica set?

Use the Kubernetes Multi-Cluster Services API (MCS API) to let nodes in different clusters discover each other over a shared DNS zone such as svc.clusterset.local. Setting multiCluster.enabled: true in the Percona Operator for MongoDB's cr.yaml creates ServiceExport and ServiceImport resources, but the MCS API itself requires a separate implementation like Submariner, Cilium ClusterMesh, or a managed provider solution such as GKE's native MCS.

_Engineers wiring up cross-cluster database replication follow setups like this on daily.dev._

### What is the difference between Main Site and Replica Site roles in the Percona Operator for MongoDB multi-cluster setup?

The Main Site is the primary cluster fully managed by the Operator, holding the Primary node and handling provisioning of TLS certificates, user credentials, and replica set configuration. The Replica Site runs its operator in unmanaged mode, so it does not generate credentials or initialize a new replica set; instead, TLS secrets and credentials are copied from the Main Site so its nodes can join the existing replica set without split-brain conflicts.

_Teams designing multi-cluster failover strategies can follow operator patterns like this on daily.dev._

## Similar posts on daily.dev

- [DocumentDB on Kubernetes: Resilient, Highly Available Databases with Automatic Failover](https://daily.dev/posts/documentdb-on-kubernetes-resilient-highly-available-databases-with-automatic-failover-tisl7b5gv) · ITNEXT · 0 upvotes · 0 comments
- [Multi-Cluster Kubernetes Explained](https://daily.dev/posts/multi-cluster-kubernetes-explained-xic98yci5) · cilium · 5 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

---

Tags: [#kubernetes](https://daily.dev/tags/kubernetes), [#mongodb](https://daily.dev/tags/mongodb)

[View this post on daily.dev](https://daily.dev/posts/multi-cluster-databases-on-kubernetes-architecture-and-deployment-yats0aq1j)

```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":"Multi-Cluster databases on Kubernetes: Architecture and deployment","url":"https://daily.dev/posts/multi-cluster-databases-on-kubernetes-architecture-and-deployment-yats0aq1j","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/multi-cluster-databases-on-kubernetes-architecture-and-deployment-yats0aq1j"},"datePublished":"2026-07-22T11:43:22.244Z","dateModified":"2026-09-14T06:52:33.659Z","description":"Running a MongoDB replica set across multiple Kubernetes clusters provides resilience against regional failures, corrupted control planes, and network...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/1c4b0093425954ff8e309bd379cf8ae7?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/1c4b0093425954ff8e309bd379cf8ae7?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"CNCF","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":"CNCF","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/55536a03390741eebd96d2f9b74d2d8d","url":"https://daily.dev/sources/cncf"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/multi-cluster-databases-on-kubernetes-architecture-and-deployment-yats0aq1j","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":1},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"kubernetes,mongodb","timeRequired":"PT9M"}
{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"CNCF","item":"https://daily.dev/sources/cncf"},{"@type":"ListItem","position":3,"name":"Multi-Cluster databases on Kubernetes: Architecture and deployment"}]}
{"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/multi-cluster-databases-on-kubernetes-architecture-and-deployment-yats0aq1j#faq","mainEntity":[{"@type":"Question","name":"How many voting members do I need to survive a network partition in a multi-region MongoDB replica set?","acceptedAnswer":{"@type":"Answer","text":"An odd number of voting members spread across at least three locations is needed, commonly the 2+2+1 pattern: two nodes in a main site, two in a replica site, and one additional voting member in a third location. With five total votes, one side can still reach the majority of three votes to elect a Primary even if the network between the two main sites is severed. Anyone architecting resilient databases on Kubernetes can track patterns like this through daily.dev."}},{"@type":"Question","name":"How do I connect MongoDB nodes running in separate Kubernetes clusters into one replica set?","acceptedAnswer":{"@type":"Answer","text":"Use the Kubernetes Multi-Cluster Services API (MCS API) to let nodes in different clusters discover each other over a shared DNS zone such as svc.clusterset.local. Setting multiCluster.enabled: true in the Percona Operator for MongoDB's cr.yaml creates ServiceExport and ServiceImport resources, but the MCS API itself requires a separate implementation like Submariner, Cilium ClusterMesh, or a managed provider solution such as GKE's native MCS. Engineers wiring up cross-cluster database replication follow setups like this on daily.dev."}},{"@type":"Question","name":"What is the difference between Main Site and Replica Site roles in the Percona Operator for MongoDB multi-cluster setup?","acceptedAnswer":{"@type":"Answer","text":"The Main Site is the primary cluster fully managed by the Operator, holding the Primary node and handling provisioning of TLS certificates, user credentials, and replica set configuration. The Replica Site runs its operator in unmanaged mode, so it does not generate credentials or initialize a new replica set; instead, TLS secrets and credentials are copied from the Main Site so its nodes can join the existing replica set without split-brain conflicts. Teams designing multi-cluster failover strategies can follow operator patterns like this on daily.dev."}}]}
```

