An online retail platform experiences a catastrophic regional failure in its primary region (us-central1). The application architecture consists of an active Managed Instance Group (MIG) and Cloud SQL primary in us-central1, with a scaled-down warm standby MIG and a cross-region Cloud SQL read replica in us-east4. Place the operational disaster recovery failover steps in the correct order to restore full production traffic in us-east4 with minimal data inconsistency.
- 1Promote the cross-region Cloud SQL read replica in us-east4 to a standalone primary database instance.
- 2Update application configuration settings in us-east4 to reference the connection endpoint of the newly promoted database instance.
- 3Scale up the warm standby Managed Instance Group (MIG) in us-east4 to full production capacity.
- 4Update Cloud DNS routing policies to direct production domain traffic to the us-east4 External HTTP(S) Load Balancer.
Cevap
The correct operational sequence is: 1) Promote the cross-region Cloud SQL read replica in us-east4 to a standalone primary database instance, 2) Update application configuration settings in us-east4 to reference the connection endpoint of the newly promoted database instance, 3) Scale up the warm standby Managed Instance Group (MIG) in us-east4 to full production capacity, and 4) Update Cloud DNS routing policies to direct production domain traffic to the us-east4 External HTTP(S) Load Balancer.
Executing disaster recovery requires prioritizing data write availability first, followed by application binding, compute scaling, and finally DNS traffic cutover. Promoting the database replica ensures a writable backend. Rebinding application instances ensures writes hit the new primary database. Scaling up the compute tier ensures sufficient capacity. Switching Cloud DNS last prevents sending live user requests to an unready or under-provisioned environment.
Adım Adım Çözüm
Anahtar Kavram
Disaster Recovery Failover Sequencing