Memory hook: Replica for continuity; backup for history.
Must remember
- RPO defines acceptable data loss; RTO defines acceptable recovery time. Map both to actual failover, restoration, DNS, application reconnection and validation steps.
- Cloud SQL regional HA uses a standby for failover; a read replica serves reads and has different promotion/replication behavior. Cross-region replicas support regional recovery but can lag.
- Spanner placement and quorum, AlloyDB HA/read pools, Bigtable replication and Firestore location choices have different consistency and failover semantics. Test the chosen service rather than assuming every replica behaves alike.
- Backups, transaction logs/PITR and exports solve different needs. Replication can copy accidental deletion; recoverability requires retained history and restore permissions.
- Automate provisioning through reviewed infrastructure code, include backup policy and monitoring, and protect production deletion paths. Schedule maintenance windows and rehearse compatible upgrades.
- Test zone loss, regional loss, credential/key availability and restoration to a clean environment. Measure data correctness and application health after recovery, not merely resource creation.
Review details
In Cloud SQL regional HA, committed writes are synchronously protected across the primary/standby zones, and the standby serves failover rather than ordinary read scaling. Read replicas use different replication/promotion semantics and can return stale data. Test client reconnection after failover rather than assuming existing TCP sessions survive.
For Bigtable, single-cluster routing versus multi-cluster routing changes availability/consistency behavior; app profiles matter. For Spanner, replica placement and quorum drive availability/latency. A Firestore location is a deployment choice with service-specific replication behavior. Record the chosen service's actual guarantees rather than assuming all “replicas” are identical.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Accidental DELETE propagated to replicas | Restore using retained backups/PITR to a safe target. |
| Read load is exhausting a primary | A compatible read replica/read pool, accounting for lag and consistency needs. |
Traps
- A standby is not necessarily a query-serving read endpoint.
- A stated SLA is not a tested end-to-end application RTO.
Active recall
1. What does asynchronous replication imply for RPO?
Recent writes can be missing at the replica during failure.
2. Why test reconnect logic?
Database failover can interrupt existing sessions even when the service recovers.
3. When is an export useful?
Portable logical data transfer or an additional recovery workflow, with its own consistency and restore limitations.
4. What must a recovery exercise verify?
Data integrity, permissions, dependencies and achieved RPO/RTO.
5. Why retain independent backups?
To recover from corruption or deletion that healthy replicas also contain.