Prepare and test your skills
Prepare and test your skills
Replication modes control how much data a failover can lose and how much delay applications pay during normal writes. Synchronous replication (opens in a new tab) waits for the standby to confirm each write before the transaction completes, while asynchronous replication lets the primary complete writes and sends data in the background. The choice sets consistency, Recovery Point Objective (RPO), Recovery Time Objective (RTO), and whether zonal or regional failover stays fast and safe.
Synchronous replication copies each transaction to a standby before the primary reports success, which gives strong consistency and zero data loss during normal operation. PostgreSQL write-ahead log (WAL) streaming in synchronous mode offers RPO=0 during normal operation and typical failovers because the standby already holds every committed write. The cost is higher transaction latency, since every commit waits for confirmation across the network boundary between the primary and the standby. Synchronous replication also does not protect against a double fault where all standbys are lost or unreachable and the primary then restarts.
Synchronous replication fits short distances, such as two zones in the same region where network delay stays low. In the SQL Server pattern, data flows from the primary node to the secondary node in a separate zone of the same region using synchronous replication. An Always On availability group with synchronous replication in that topology achieves low RPO with near-zero data loss for zonal failure. Choose synchronous replication when the application needs strong consistency and can accept slower commits.
Asynchronous Replication is block storage replication for cross-region active-passive disaster recovery (DR). Data flows from a primary disk attached to a running workload in the primary region to a secondary disk in the secondary region, and the two regions form a region pair. Because the primary does not wait for the secondary to acknowledge, write latency stays low and the workload avoids long-distance confirmation. The tradeoff is eventual consistency: the secondary disk can lag, so failover can lose recent writes and RPO is greater than zero.
Asynchronous Replication provides low RPO and low RTO, and it reduces RTO when the database experiences a regional failure. Replication is managed at the infrastructure level, so Compute Engine disks replicate without changing application code. After failover, the secondary disk becomes the acting primary disk and the secondary region becomes the acting primary region. Failback then starts replication from the acting primary disk to a new secondary disk in the original primary region.
A consistency group is a resource policy that aligns replication or cloning across multiple disks to a common point in time. The consistency group ensures that all primary disks hold replication data from a common point in time for DR, and that all clones made from secondary disks hold data from a common point in time for DR drills. A single consistency group can be used for replication or cloning, but not both at the same time. This shared point in time matters because a multi-disk workload is only recoverable when all disks restart from the same moment.
Primary disks must be added to the consistency group before replication starts if their replication periods are to stay aligned. Secondary disks can be added to a consistency group at any time for aligned cloning. If replication is stopped on a primary disk and restarted later, a new secondary disk must be created to restart replication. Failover moves the whole disk set together in a fixed order:
Only after replication is stopped and the secondary disks are attached do the secondary disks become the workload's primary disks. The operator remains responsible for identifying the outage, validating the workload, restarting the application, and repointing network addresses, because Asynchronous Replication does not offer outage monitoring.
Choosing a replication mode means matching distance, latency budget, and consistency needs to zonal versus regional protection. The Standard Availability Architecture focuses on backup and recovery options, while the Enhanced Availability Architecture focuses on high-availability options with zonal replication. The combined SQL Server reference pattern uses both modes: data flows synchronously from the primary node to the in-region secondary node, then asynchronously from the primary node to the DR node in a remote region. Client traffic flows from the application layer to the primary and secondary nodes through an internal load balancer or a distributed network name (DNN) listener with a Domain Name System (DNS) server.
| Mode | Consistency | Latency and RPO tradeoff | Choose when |
|---|---|---|---|
| Synchronous replication | Strong, RPO=0 in normal operation and typical failovers | Adds transaction latency; vulnerable to double-fault loss if all standbys are unreachable before a primary restart | Zonal failover in the same region needs near-zero data loss and can tolerate slower commits |
| Asynchronous replication | Eventual, secondary may lag | Low write latency with low RPO and low RTO; some recent data can be lost on regional failover | Regional DR needs fast writes and fast restart without long-distance waits |
Exam tip: Use only asynchronous replication for DR and remote region replication; synchronous replication reduces RPO for regional recovery but adds transaction latency that does not scale across regions.
Designing storage persistence for regional disaster recovery means keeping continuously updated copies of data in separate locations so applications can fail over with minimal loss and downtime. RPO measures how much data can be lost, while RTO measures how quickly service is restored. A regional strategy combines multi-region object storage, synchronous replication inside a region for zonal failures, and asynchronous replication between regions for full regional outages.
Cloud Storage (opens in a new tab) dual-region and multi-region buckets store object data in multiple regions to support failover during a large-scale outage. If one region becomes unavailable, a processing job can rerun in another region where the same data is already available. This approach separates storage durability from compute location, so the pipeline depends on the replicated bucket rather than on disks in the failed region. Choose dual-region or multi-region classes when downstream jobs in Dataflow or other services must restart elsewhere without waiting for a restore.
Disk replication for disaster recovery keeps a continuously updated copy of disk data in another zone or region to protect business-critical workloads from infrastructure failure. Data flows from the primary disk to the replica location, and failover moves the workload to the replica when the primary location fails. Replication depends on the infrastructure remaining intact and does not replace backups.
| Replication mode | Scope | How it works |
|---|---|---|
| Synchronous replication with Regional Persistent Disk or Hyperdisk Balanced High Availability | Two zones in the same region | Writes data to both zones simultaneously, so zonal failover continues with an RPO of zero and very low RTO |
| Asynchronous replication with Asynchronous Replication | Two different regions | Copies data between regions with a short delay, offering low RPO and low RTO for failover to a secondary region |
Asynchronous Replication works with consistency groups to manage application failover and failback between regions and to perform disaster recovery testing. Replication protects against zone or region loss, but it does not protect against problems that are copied to the replica:
Database replication for regional recovery trades lower RPO for higher transaction latency. Synchronous replication can reduce RPO for regional recovery, including PostgreSQL WAL streaming in synchronous mode that offers zero data loss (RPO=0) during normal operation or typical failovers. However, synchronous replication forces each transaction to wait for the standby, which adds latency, so only asynchronous replication is recommended for DR and remote region replication. Synchronous WAL streaming also does not protect against a double fault where all standbys are lost or unreachable and then the primary restarts.
Pair replication choices with backup and high-availability architectures. The Standard Availability Architecture covers backup and recovery options, while the Enhanced Availability Architecture covers high-availability options. Cross-data-center replication then extends protection from zonal and instance failures to regional failures and reduces RTO when the database experiences a regional failure.
Exam tip: Use only asynchronous replication for DR to a remote region, even though synchronous replication gives a lower RPO, because synchronous replication adds transaction latency.
Geographic redundancy for streaming pipelines runs parallel copies of the same processing in two regions so one region can continue if the other fails. The end-to-end flow keeps sources, compute, and sinks available in both regions. For latency-sensitive streaming with no data loss, run duplicate pipelines in parallel that consume the same data, which has the highest cost because resources are duplicated.
For latency-sensitive streaming with some potential data loss, keep the streaming source available in multiple regions with two independent Pub/Sub subscriptions for the same topic. Then start a replacement pipeline in another region that consumes and replays the backup subscription from an appropriate time.
Database high availability and failover places primary, standby, and replica nodes so service continues when a zone or region fails. A high-availability architecture places a primary node and a failover node in different zones of the same region, and places a DR node or read replica in a remote region. Data flows from the primary node to the in-region standby synchronously for zero data loss, and from the primary node to the remote DR node asynchronously to avoid high cross-region latency.
Synchronous replication requires the primary database to wait until the standby confirms receipt before acknowledging a write to the application. Data flows from the primary node in one zone to the secondary node in another zone of the same region, which keeps RPO at near-zero or zero because no committed writes are lost. The tradeoff is higher write latency, so synchronous replication is best within a region where network distance is short.
Asynchronous replication lets the primary database acknowledge writes as soon as they commit locally, and data then flows from the primary region to the replica region in the background. Asynchronous replication protects against regional failure with lower write latency, but it creates a non-zero RPO because recent writes may not have reached the replica when the primary fails. Choose asynchronous replication for a DR region and design the application to tolerate loss of recent writes.
| Replication mode | RPO | Latency impact | Best use |
|---|---|---|---|
| Synchronous | Near-zero or zero data loss | Higher write latency | Primary to secondary in separate zones of the same region |
| Asynchronous | Non-zero, recent writes can be lost | Low write latency | Primary region to DR replica in a remote region |
Exam tip: Use synchronous replication for zonal high availability with zero RPO, and use only asynchronous replication for remote-region disaster recovery because synchronous cross-region writes add too much latency.
Always On availability group (opens in a new tab) is the SQL Server enterprise feature for high availability (HA) and disaster recovery that replicates databases between primary and secondary replicas. In the Google Cloud reference pattern, the primary and secondary Compute Engine (opens in a new tab) nodes run in separate zones of one region, while the DR node runs in a geographically remote region. Data flows synchronously from the primary node to the in-region secondary node, and asynchronously from the primary node to the remote DR node.
Client traffic flows from the application layer to the database nodes through an availability group listener or an internal load balancer. The availability group listener is a virtual network name (VNN) that routes clients to the current primary replica, so the client connection string does not need to change after failover. The deployment depends on Windows Server Failover Clustering (WSFC) for cluster membership, Active Directory Domain Services and Domain Name System (DNS) for identity and name resolution, and a quorum witness such as a server message block (SMB) file share to decide which nodes stay active during a failure.
Cloud SQL is the Google Cloud managed database service with built-in backup, replication, and failover features. For MySQL, Cloud SQL supports asynchronous mode, where the primary acknowledges writes immediately with an RPO close to zero but not zero, and semisynchronous mode, where the primary waits until a configurable number of replicas acknowledge receipt for an effectively zero RPO. For PostgreSQL WAL streaming, synchronous mode offers RPO=0 during normal operation and typical failovers, but it does not protect against a double fault where all standbys are lost or unreachable and then the primary restarts.
Place the primary and failover instances in different zones to survive a zonal outage, and use asynchronous replication between zones when semisynchronous commits would add too much latency. When zero RPO is required within a single region without cross-zone database latency, use Hyperdisk Balanced High Availability to synchronously replicate the disk across two zones in the same region. Integrate Hyperdisk-based deployments with Stateful Managed Instance Groups so the control plane can detect unhealthy instances and automate recovery actions.
A read replica is a standby copy that serves read traffic and stays ready to become the new primary if the original primary fails. During regional failover, the secondary cluster is promoted from read replica to primary so it can accept database writes and serve production traffic. Traffic then flows from clients to the new primary region because Cloud DNS (opens in a new tab) redirects requests automatically based on health checks and failover policies.
Automated failover depends on health checks to minimize RTO, which is how quickly the database becomes operational again. The failover sequence runs in order:
The failover instance can sit in the same zone as the primary, in a different zone of the same region, or in a different region. Choose different zones for zonal protection and a different region for regional protection, since only a remote replica protects the workload when the entire primary region fails.
Storage-level replication copies block data independently of the database engine for disaster recovery. Persistent Disk Asynchronous Replication (opens in a new tab) copies data from a primary disk in the primary region to a secondary disk in the secondary region, and consistency groups ensure the disks share a common point in time for recovery. In Kubernetes environments, PersistentVolumes objects in both clusters link to these disks, and applications use the same Persistent Volume Claims (PVCs) in both clusters so the secondary cluster can mount the replicated data.
Database-level backups add protection against accidental deletion, ransomware, and natural disasters that replication alone does not cover. Managed options include Cloud SQL automated backups and asynchronous cross-region replicas, while self-hosted options include mysqldump, mysqlpump, MySQL Enterprise Backup, and operators such as CloudNativePG with scheduled backups to Cloud Storage (opens in a new tab). Store logical backups in durable secondary storage such as Cloud Storage, Filestore, or Google Cloud NetApp Volumes, and use Hyperdisk instant snapshots when fast point-in-time recovery within a zone is the priority.
Synchronous replication waits for the standby to confirm each write before the transaction completes, giving strong consistency and a Recovery Point Objective (RPO) of zero during normal operation with higher transaction latency. Asynchronous replication lets the primary complete writes without waiting and sends data in the background, giving low write latency with low RPO and low Recovery Time Objective (RTO) but eventual consistency where failover can lose recent writes. Choose synchronous replication for zonal failover within the same region and only asynchronous replication for disaster recovery (DR) to a remote region.
Use a consistency group when a multi-disk workload must fail over or be cloned from a common point in time so all disks restart from the same moment. A single consistency group can be used for replication or cloning, but not both at the same time, and primary disks must be added to the consistency group before replication starts to keep replication periods aligned. Failover moves the whole disk set together by stopping consistency group replication, creating virtual machines (VMs) in the secondary region if needed, and attaching the secondary disks to those VMs.
An Always On availability group replicates SQL Server databases with synchronous replication from the primary node to the secondary node in separate zones of the same region for near-zero data loss during zonal failure, and with asynchronous replication from the primary node to the disaster recovery (DR) node in a remote region to avoid high cross-region latency. Client traffic flows from the application layer to the database nodes through an availability group listener or an internal load balancer, so clients route to the current primary replica without changing the connection string after failover.
Last updated