An enterprise runs an online transaction processing (OLTP) database on Cloud SQL in us-central1. The engineering team is designing a disaster recovery (DR) and global read-scaling architecture for downstream analytics and regional services located in europe-west1. The architecture must satisfy the following criteria: Disaster Recovery: Provide a cross-region failover target to maintain low Recovery Point Objective (RPO) and Recovery Time Objective (RTO). Network Cost & Latency: Minimize inter-region network egress costs and read latency for analytical clients located in Europe. Replication Performance: Prevent high replication lag caused by heavy bulk update batches executed on the primary instance. Which strategy should the data engineering team implement?

Deploy a cross-region read replica in `europe-west1`, direct European analytical read queries to this replica, and resize the replica's compute resources to match the primary while breaking bulk transactional updates into smaller batches.: ### What Cloud SQL Cross-Region Replication Is **Cloud SQL cross-region read replicas** enable asynchronous replication of relational data across distinct Google Cloud regions. This architecture serves a dual purpose: localizing read traffic to geographically distributed clients and serving as a warm standby failover target for **disaster recovery (DR)**. ### How It Meets the Requirements - **Disaster Recovery (DR)**: Placing an asynchronous replica in `europe-west1` establishes an independent regional copy that can be promoted to a standalone primary database in the event of a regional outage in `us-central1`, achieving stringent **RTO** and **RPO** objectives. - **Network Egress and Latency**: Routing European analytical queries locally to the `europe-west1` replica eliminates repetitive inter-region **network egress** charges from `us-central1` to Europe and drastically reduces read latency for European users. - **Replication Performance**: Replication lag occurs when the replica's SQL thread cannot keep up with incoming transactions. Sizing the replica's compute resources (vCPU, memory, IOPS) adequately and breaking large row updates into smaller batches prevents massive write backlogs on the replica. ### Key Advantages - **Regional Data Locality**: Serves read requests closer to users, improving application responsiveness. - **Cost Efficiency**: Incurs one-time cross-region egress for replication rather than recurring egress fees per user query. - **Operational Resilience**: Provides a clear, native promotion path for regional disaster recovery. - **Lag Mitigation**: Prevents single massive DML operations from stalling the replication stream. ### Why This Is Optimal Locating a properly sized read replica in the destination region balances disaster recovery readiness with localized query performance while explicitly addressing the root causes of replication lag.

Cloud Sql Cross Region Replication Dr Optimization | professional-cloud-data-engineer

Cloud Sql Cross Region Replication Dr Optimization

Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.

An enterprise runs an online transaction processing (OLTP) database on Cloud SQL in us-central1. The engineering team is designing a disaster recovery (DR) and global read-scaling architecture for downstream analytics and regional services located in europe-west1.

The architecture must satisfy the following criteria:

Disaster Recovery: Provide a cross-region failover target to maintain low Recovery Point Objective (RPO) and Recovery Time Objective (RTO).
Network Cost & Latency: Minimize inter-region network egress costs and read latency for analytical clients located in Europe.
Replication Performance: Prevent high replication lag caused by heavy bulk update batches executed on the primary instance.

Which strategy should the data engineering team implement?

Keep all database instances solely in us-central1 with High Availability (HA) enabled across two zones, and configure European analytical clients to query the standby instance directly over Cloud Interconnect.

Deploy a cross-region read replica in europe-west1, direct European analytical read queries to this replica, and resize the replica's compute resources to match the primary while breaking bulk transactional updates into smaller batches.

Configure automated hourly Cloud SQL export dumps to a multi-region Cloud Storage bucket in Europe, and restore the bucket dump to a new Cloud SQL instance whenever European analytics runs.

Deploy a minimal shared-core read replica in europe-west1 and route both write transactions and heavy analytical read queries through a single Cloud SQL Auth Proxy located in us-central1.

Professional Cloud Data Engineer

Cloud Sql Cross Region Replication Dr Optimization

Related questions