Design, migrate, and run scalable, highly available databases on Google Cloud across relational and NoSQL services, and track your readiness for the Professional Cloud Database Engineer exam.
Prepare and test your skills
Prepare and test your skills
Configuration of in-region and cross-region replicas is the decision about where to place extra copies of database data to serve reads near users and survive failures. An in-region replica lives in a different zone of the same region as the primary data, while a cross-region replica lives in a different region. In Google Cloud, Cloud SQL (opens in a new tab), Bigtable (opens in a new tab), and Memorystore for Redis Cluster all support replicas, but they differ in whether replicas accept writes, how data is copied, and what happens during failover. Placement must also account for network latency, data transfer costs, and rules about where data is allowed to reside.
In-region replicas are copies that keep data in the same region while spreading it across zones to protect against a zonal outage. In Bigtable, an instance can contain only one cluster per zone, so a replicated instance in one region places clusters in different zones and keeps a separate, independent copy of the data in each zone. A Memorystore for Redis Cluster secondary cluster can also be placed in the same region as its primary cluster, and a Cloud SQL read replica in the same region can offload read work without sending traffic across regions. Because the copy stays nearby, replicas in the same region typically have lower replication latency than replicas in different regions.
In-region replicas also help isolate workloads so heavy reads do not slow down main serving traffic. In Bigtable, app profiles with single-cluster routing can send batch analytics reads to one cluster and application reads and writes to another cluster. This isolation has a capacity cost because an instance with more than one cluster often needs more nodes to handle the added work of replication. In Memorystore for Redis Cluster, scaling the capacity of the primary cluster automatically scales secondary clusters to match, while replica count can be scaled independently for each cluster to match local read demand.
Cross-region replicas are copies placed in different regions to bring reads closer to distant users and to provide a recovery target if an entire region becomes unavailable. In Memorystore for Redis Cluster, a primary cluster is a read-write cluster in a single region and a secondary cluster is a read-only cluster that replicates asynchronously from the primary and can serve reads without any switchover. In Cloud SQL, the replicated source is called the primary instance and the copies are called read replicas, and a replica can be promoted to a standalone instance if the original is corrupted. In Bigtable, every cluster is treated as a primary cluster that accepts both reads and writes, and access continues through a surviving cluster if one zone or region becomes unavailable.
Cross-region configurations have strict placement limits that affect disaster recovery planning. A Bigtable instance can use up to 8 Bigtable regions with only one cluster per zone, so an instance across 8 regions with 3 zones each can have up to 24 clusters. A Memorystore for Redis Cluster primary can have up to two secondary clusters in the same or different regions, and only new clusters can be added as secondaries with the same shard count and slot assignment as the primary. For recovery, Memorystore supports detach and switchover to make a secondary serve writes, including switchover during a primary outage after which the old primary becomes a secondary when it returns.
Exam tip: Bigtable clusters all accept reads and writes, while a Memorystore secondary cluster is read-only until it is detached or switched over to become writable.
Replication behavior controls what is copied, how the first copy is built, and how current replicas remain afterward. In Bigtable, creating a multi-cluster instance starts synchronization immediately, while adding a cluster to an existing instance first copies existing data from the original cluster zone to the new cluster zone and then synchronizes ongoing changes. Consistency between Bigtable clusters is eventual, so replication has some latency before all clusters converge.
Bigtable replicates all of the following types of changes between clusters:
In Memorystore for Redis Cluster, data flows from a replicator node in a primary cluster shard to follower nodes in the secondary cluster, where any primary or replica node in the primary shard can act as replicator and only primary nodes in the secondary act as followers. Most cluster settings synchronize automatically from primary to secondary, and the primary stays online while a secondary is created, although the primary may undergo a maintenance update for compatibility. In Cloud SQL for SQL Server, the first replica creation sets the primary instance to the full recovery model for all databases, creates a temporary disk to hold a full backup, and then deletes that disk while normal storage billing applies. If the model is switched to simple recovery during first replica creation, creation fails, databases added later join availability groups automatically through auto-seeding, and logins and server objects created after replica creation are not replicated.
Placement of replicas trades replication speed and read latency against network cost and control over where data resides. Region selection must weigh end-user latency, cross-regional transfer costs, service and machine-type availability, cost, sustainability, and regulatory requirements for data residency. Cross-region copies place data near remote readers and provide regional failover, but they add transfer charges and usually replicate more slowly than in-region copies.
| Placement | Replication and read latency | Cost impact | Resilience and residency |
|---|---|---|---|
| In-region replicas | Lower replication latency between zones; reads stay in same region | Avoids cross-region transfer charges, but replicated clusters may need more nodes and secondary nodes are billed like primary nodes | Survives zonal failure but not regional failure; data remains in one region |
| Cross-region replicas | Higher replication latency across regions, but lower read latency for users near replica region | Incurs networking charges for transfer between regions plus full secondary node and replica charges | Survives regional outage through promotion, switchover, or failover; data exists in multiple regions |
Choose in-region replicas when the priority is fast replica convergence, lower transfer cost, and protection against zone failure while keeping data in one region. Choose cross-region replicas when the priority is geographic load balancing for reads and disaster recovery from another region, accepting higher replication latency, inter-region charges, and the need to verify that storing copies in additional regions meets residency rules.
Scaling read capacity and load distribution is the practice of adding read-only copies of a primary database so read queries spread across more compute without overloading writes. In AlloyDB, read pool instances (opens in a new tab) provide this scale-out path by serving read traffic from asynchronous, read-only clones of the primary instance. Adding pools or nodes increases throughput and keeps data readable even when the primary is unreachable, while sizing, replication health, and failover handling keep performance and consistency within standards.
A read pool instance is a read-only clone of a database instance that increases read throughput and availability for the cluster. Data flows from the primary instance to each read pool through asynchronous streaming replication, and applications send read queries to the pools so the primary can focus on writes. A read pool continues to serve its last copied data when the primary becomes unreachable, which preserves read availability during an outage at the cost of serving slightly stale results.
Each read pool holds a full copy of the data and occupies the same amount of storage as the instance it replicates. A cluster supports up to 20 read pool instances, with each instance defined by its own unique manifest file. The number of nodes in a read pool determines its overall computing capacity, with support for up to 20 nodes per read pool instance in AlloyDB Omni. As an alternative for strongly consistent reads, the standby replica of a highly available instance can be configured as a synchronous read-only instance.
An AlloyDB for PostgreSQL cluster can start as a zonal instance or a highly available instance and then scale reads by adding read pool instances and, for geographic distribution, a secondary cluster. Read traffic flows from clients to the primary instance and to any read pools in the primary and secondary clusters, which lets a workload serve nearby users and survive a regional disruption. Creating a secondary cluster (opens in a new tab) copies settings such as point-in-time recovery and backup configuration from the primary cluster, but AlloyDB does not automatically copy read pools to the secondary cluster.
Read pools must be added separately to each cluster where extra read capacity is needed. On a secondary cluster, an operator selects the secondary cluster, chooses to add a read pool, and then sets the read pool instance ID, node count, and machine type. Later changes to the primary cluster configuration are not automatically applied to the secondary cluster, so the secondary cluster must be updated manually to stay aligned. This separation means geographic scale is explicit: the secondary cluster provides the remote copy, and its own read pools provide the remote read capacity.
Sizing decisions start before pools are created and consider four factors:
For online transaction processing (OLTP) workloads, transactions per second (TPS) is the primary sizing metric because input and output operations per second are less meaningful under AlloyDB multi-tier caching and disaggregated storage. Teams identify existing TPS, analyze critical queries, and benchmark with tools such as HammerDB or pgbench to choose primary and read pool machine sizes. The steady-state target is about 60-70% CPU utilization, which leaves headroom for spikes without operating system scheduling overhead.
Health of an AlloyDB Omni read pool is reported through two separate Kubernetes status conditions, Available and Streaming. The Available condition reports whether the read pool can serve queries, while the Streaming condition reports whether the read pool is connected to its database instance and actively receiving changes. After setup, inserts, updates, and deletions committed on the primary become readable on the read pool once replication streams them.
| Condition | True means | False can mean |
|---|---|---|
| Available | The read pool instance can serve read queries | The read pool cannot yet serve queries |
| Streaming | The read pool is connected to the database instance and actively streaming changes | The read pool is disconnected, such as when the primary is unreachable or after a switchover |
The split between these conditions matters because a pool can stay readable while it is no longer fresh. That separation lets operators tell the difference between a pool that cannot serve traffic and a pool that serves stale data during an outage.
Exam tip: Available true with Streaming false means the read pool still serves queries from its last copy while it is not receiving new changes — availability and freshness are tracked separately.
Sustaining performance means watching replication lag and resource use as read pools are added. Every additional pool adds replication work for the primary instance, so creating too many read pool instances can reduce primary performance. AlloyDB supports non-disruptive scaling with sub-second downtime for the primary and zero downtime for read pool nodes during scale operations, plus automatic memory management, adaptive autovacuum, and low replication lag. Resource utilization and replication lag therefore remain the signals for whether the current number of pools and nodes still meets performance standards.
Cross-data-center replication adds Write-Ahead Logging (WAL) sizing to the same tradeoff. The primary retains past WAL files so a lagging secondary can fetch segments it still needs for streaming replication. If lag exceeds retained WAL, the primary may remove a needed segment, the replication connection terminates, and downstream connections eventually fail. Operators set wal_keep_size and max_wal_size based on WAL generation rate, network characteristics, and expected lag between data centers, with defaults of 100 MB and 1504 MB and a requirement that maximum size stay higher than retained size.
A switchover or failover breaks the normal replication relationship for AlloyDB Omni read pools. The read pool does not automatically follow the new primary instance and stops replicating data. To resume replication, the read pool must be restarted through scaling in this order:
spec.nodeCount value from the read pool DBInstance object so it can be restored.spec.nodeCount to 0, which stops the existing pool members.spec.nodeCount back to the recorded value, which reconnects the pool to the current primary and resumes streaming.Only after the scale-down and scale-up sequence completes does data flow again from the current primary instance to the read pool instance.
Replica lifecycle management in Cloud SQL (opens in a new tab) covers how a primary instance and its read replicas are created, maintained, and converted to independent instances. The primary instance accepts all writes and streams changes to its replicas, while each read replica (opens in a new tab) stays read-only and serves queries, read requests, and analytics traffic. A central lifecycle action is promotion, which converts a replica into a standalone primary instance that accepts writes.
Promotion is the action that converts a read replica into a standalone primary instance that accepts writes and no longer replicates from its old source. Promotion is used when the original primary instance is in a region having an outage, when the original instance is corrupted, or when migrating data between regions. After promotion for Cloud SQL for SQL Server, existing replicas do not treat the promoted instance as their primary, so applications must reconnect and replication must be re-planned. To avoid a split-brain state where two primaries accept conflicting writes, the original primary instance must be made inaccessible before clients start using the new primary instance.
Disaster recovery with cross-region and cascading replicas uses distant copies that can take over when the primary region fails. Data flows from the primary instance to the replica instance as replication logs, so the distant replica stays nearly current and can be promoted if the primary region fails. A cascading hierarchy extends this model by placing read replicas under another read replica in the same or a different region, up to four levels including the primary instance. When the replica at the top of a cascading hierarchy is promoted, it becomes a primary instance and its cascading replicas continue to replicate from it, which reduces recovery time because replacement replicas are already in place.
Exam tip: A read replica cannot fail over during an outage — only a dedicated disaster recovery (DR) replica supports failover, so a read replica must be promoted to take over.
Lifecycle rules for Cloud SQL read replicas block several operations while a replica relationship exists. The rules protect the dependency where each replica depends on its primary instance for streamed changes. Maintenance also follows a fixed order across the lifecycle, where read replicas share the maintenance window, rescheduling, and deny maintenance period of the primary instance.
During maintenance, Cloud SQL updates all read replicas first before updating the primary instance, so replicas receive disruptive upgrades before the primary changes state.
Replication overhead on the primary instance is the extra work and storage required to record and send every change to its replicas. For Cloud SQL for MySQL, supporting replicas requires automated backups, point-in-time recovery, and binary logging, plus at least one backup after binary logging is enabled. Cloud SQL uses row-based replication with sync_binlog=1 and innodb_support_xa=true, so each write operation requires an additional disk fsync that reduces write performance. Storage overhead also grows because binary log storage is charged at the same rate as regular data, logs are truncated to the age of the oldest automated backup, and Cloud SQL retains the most recent seven automated backups plus all on-demand backups.
Overhead can be reduced by shifting replication work away from the primary instance. A cascading replica lets child replicas replicate from an intermediate replica instead of directly from the primary, so replication traffic flows from the primary to the intermediate replica and then to its children. Creation timing also matters because active long-running transactions can affect replica creation, so creation is recommended when the instance is under low traffic demands and after long-running transactions complete. For Cloud SQL for SQL Server, each replica creation invokes a full-recovery-model backup of databases on the primary instance, and new logins and server objects created after replica creation are not automatically replicated.
Cascading limits and promotion order control how large a replica hierarchy can grow and how its members become independent. A single primary instance supports up to 10 direct replicas, with replicas of those replicas allowed up to four levels including the primary instance. Sibling instances that replicate from the same parent sit at the same level, and a replica can officially have up to eight siblings. A leaf replica is a read replica at the last level that has no replicas of its own.
Promotion can occur at any level in the hierarchy, and the promoted replica retains its own cascading replica hierarchy beneath it. The one ordering exception involves an external server source, where a cascading replica that sits under an external server replica cannot be promoted directly. First, the external server replica must be promoted, and then the replica of that promoted instance can be promoted.
Last updated