Infrastructure requirements for asynchronous replication and failover between two sites under Option 2 (Active/Passive): the inter-DC link, preferred replication mechanism, fallback path, traffic switch, and the infrastructure prerequisites checklist to confirm before this design can be finalized.
Inter-DC link
Sized for asynchronous replication, not the tight sub-50ms RTT/jitter budget Option 1’s live clustering needs. Actual round-trip time and bandwidth on the replication link specifically (separate from the general inter-DC network link) still need to be measured and confirmed.
Preferred replication mechanism
Platform-native, storage/hypervisor-layer asynchronous replication (snapshot-based, with an orchestrated promotion/failover step) is the recommended default, rather than database-native replication configured per engine. This keeps the DR mechanism at the infrastructure layer, so it works the same way for every stateful component instead of needing separate replication configuration per database engine. It replicates in-cluster persistent volumes, database volumes, and object storage (recordings/media) as one or more consistency groups. Confirm with the infrastructure team whether this capability is available on the platform in use, and at what interval (see the prerequisites checklist below); where it isn’t, database-native replication configured per engine is the fallback, at the cost of separate configuration and monitoring per engine instead of one platform-level mechanism.
Two things this depends on, not assumes:
-
Replication interval must support an RPO in the range of about a minute to a few minutes, not just an hourly or daily snapshot cadence. Some platforms offer a faster near-continuous replication tier (commonly quoted around one minute) as a separate capability from their standard scheduled snapshot replication; confirm which one is actually configured.
-
Object/recording storage needs its own replication path confirmed and provisioned separately from block/VM-level storage, since it typically uses a different mechanism (for example, bucket-level replication rather than volume-level). Don’t assume it’s covered by the same policy as the database/config tier, confirm it explicitly as part of the prerequisites checklist below.
A synchronous, stretched-storage variant of the same platform capability may also exist and would tighten RPO further, but it generally needs very low inter-DC latency to qualify, close to the range associated with Option 1’s live clustering, not Option 2’s. If the inter-DC link qualifies, it’s worth evaluating either way: as a way to tighten Option 2’s RPO while keeping Option 2’s simpler, manual/orchestrated failover and no witness node, or as a step toward Option 1 if automatic, near-instant failover is also wanted. Synchronous storage replication alone doesn’t provide the application/cluster-level quorum (the witness node) that Option 1’s automatic failover depends on, so which path makes sense depends on whether automatic failover is actually needed, not just on replication speed.
Fallback mechanism
Where platform-native replication isn’t available or confirmed, backup-restore-strategy covers rebuilding the passive site from per-component backups (pgBackRest, Percona Backup for MongoDB, MinIO bucket replication) instead of a storage promotion. This changes the RTO shape materially: expect hours, not the 7-to-15-minute figure quoted for storage-replication failover, since it’s a rebuild (redeploy, restore each database, restart services) rather than a volume simply becoming writable. It also means the passive site’s cluster and namespace need to already be standing, or a documented process for standing them up as part of the failover sequence, either way this needs deciding, not assuming.
Traffic switch
A DNS/GSLB mechanism (or equivalent) redirects inbound traffic to the promoted site’s own load balancer once it’s promoted and started, the last step of the detect/promote/start/switch sequence.
No witness node, no live cross-site cluster
Unlike Option 1, there’s no continuous quorum to arbitrate, so failover is a sequence (manual runbook or orchestrated automation), not an automatic election.
Infrastructure prerequisites checklist
Confirm the following with the infrastructure team before this replication design can be finalised and tested:
Replication capability - Does the storage platform underneath the cluster support asynchronous, near-continuous replication (commonly available down to around a minute) of volumes between sites as a site-to-site feature, not just local multi-node redundancy within one site? - What replication interval is actually configured: continuous/near-continuous, or a fixed schedule (hourly, daily, etc.)? This sets the real RPO floor. - What is the measured round-trip time and available bandwidth on the storage replication link specifically, separate from the general inter-DC network link.
Consistency across volumes - Can the platform group multiple volumes belonging to one application into a single consistency group, so the replica is never left mid-transaction across volumes (e.g. a database’s data files and its transaction log together)? - The data in scope for replication is: in-cluster persistent volumes, database volumes (in-cluster or platform-managed), and object storage backing recordings/media. Confirm the platform’s replication capability for each of these separately, since object storage commonly replicates via a different mechanism than block/VM storage.
Failover mechanics - Is there a platform capability to promote the replica to writable and detect/trigger this automatically, or is promotion a manual action by the infrastructure team? This is the biggest single input to whether the target RTO is realistic. - How does the platform prevent the original site from becoming writable again if it comes back online after the passive site has already been promoted (split-brain/fencing)? - Which storage driver is actually provisioning storage today, and does it expose failover-awareness to the orchestration layer?
Failback - After the original site is restored, does resynchronisation happen incrementally (delta resync) or does it require a full reseed/re-copy? Determines how long the estate stays exposed as single-site after a real failover.
Ownership and testing - Who executes promotion/failback day to day: the infrastructure team, or is any part of it dependent on the storage platform vendor’s own support? - Can this be tested non-disruptively, a real DR test rather than a design review, before go-live, and how often can it realistically be re-tested?