High Availability (HA) makes sure a database stays up even if part of the system fails. In Google Cloud, services like Cloud SQL and AlloyDB do this by creating regional instances. These spread the database across multiple zones within a region, which is key for keeping applications running if a single data center has a problem.
A typical HA setup for Cloud SQL uses a primary instance and a standby instance placed in different zones. They stay in sync using synchronous replication. This means when data is written to the primary, it is immediately copied to the standby's disk. This setup prevents data loss if the primary instance's zone goes down.
The system constantly checks the health of the primary instance. If it detects the primary is unresponsive for about a minute, it triggers an automatic failover. The standby instance then becomes the new primary and takes over the same IP address. This switch happens quickly so applications experience little downtime.
You can add more protection by creating read replicas in a third zone. While the standby instance is only for failover and cannot be used for reading data, read replicas can handle read traffic. This offloads work from the primary and provides another copy of your data. Having components in three different zones means your data is still available even if one entire zone fails.
For the highest level of protection, you can use multi-regional resources. This guards against the loss of an entire cloud region. These setups often involve a trade-off: synchronous replication gives strong consistency but can add latency, while asynchronous replication can be faster but might risk minor data loss. Regularly testing your failover process is a crucial part of a good disaster recovery plan.
Google Cloud uses regional and multi-regional setups to protect data. Cloud Bigtable uses a multi-cluster design where data is automatically copied between clusters in different zones. If one cluster fails, traffic can failover to another cluster in the same instance without interruption.
For a production Bigtable instance, you should create at least two clusters in separate zones. You control how applications talk to these clusters using app profiles. These profiles manage traffic routing, allowing you to balance load across clusters or direct all traffic to a specific one for maintenance.
For relational databases like Cloud SQL, the basic HA setup is within one region. To improve global performance and prepare for a major disaster, you can create cross-region read replicas. These keep a copy of your data in another region. If your primary region fails, you can promote a read replica to become the new primary instance, enabling recovery.
Some Google Cloud database services have multi-region support built-in. Cloud Spanner and Firestore are designed this way to offer very high availability. Spanner uses replicas across regions and a special witness replica to manage consistency. Firestore can survive a whole region going offline without losing data. These services are best for global apps that need fast access and strict data recovery promises.
To direct users to the healthiest database location, you can use an HTTPS Load Balancer. It distributes requests across regions. This works well with storage like Cloud Storage dual-region buckets, which keep data in two locations. Features like turbo replication make sure data syncs across regions quickly. Using smart load balancing with cross-region replication creates a strong system that keeps services running for users everywhere.
Cloud Spanner can be set up across multiple geographic regions to achieve extremely high availability, up to 99.999%. This means your service is very unlikely to go down, even if an entire cloud region fails. Designing these solutions is critical for meeting strict business targets for Recovery Time Objective (RTO), how fast you recover, and Recovery Point Objective (RPO), how much data you can afford to lose.
Spanner uses different kinds of replicas to make this work. Read-write replicas store the full data and vote to approve transactions. Read-only replicas provide fast local access for reading data but don't vote. A witness replica is a lightweight component that helps achieve a voting majority without storing a full data copy, which saves cost and resources.
For a write to be accepted, a majority of the voting replicas must agree. This voting system guarantees external consistency, so the database behaves as if it were a single system even though it's globally distributed. This process also provides a zero RPO, meaning no committed data is lost during a regional outage.
You select between dual-region and multi-region instance configurations based on your needs. Dual-region configurations are good for keeping data within one country, often for legal reasons. Multi-region configurations spread data farther apart, which can lower read latency for users around the world. Both offer the same high level of availability.
Every Spanner instance has a leader region that handles all write operations. You can manually move the leader region to be closer to where most of your users are, which reduces application delay. While Google handles automatic failovers, you can also start a manual failover for a faster RTO, sometimes completing in under a minute. This lets you balance performance and reliability based on current conditions.
Fascinated by the world of cloud databases? Explore the methods for structuring, scaling, and securing database solutions on Google Cloud as you gear up for the Professional Cloud Database Engineer exam!
Prepare and test your skills
Prepare and test your skills
Automatic failover is triggered when the system detects that the primary instance has been unresponsive for about a minute. The standby instance in a separate zone then becomes the new primary instance and takes over the same IP address to ensure applications experience little downtime.
Read-write replicas store full data copies and vote to approve transactions, whereas read-only replicas provide fast local access for reading data without voting. Witness replicas do not store a full copy of the data but provide a lightweight component to help achieve a voting majority while saving costs and resources.
App profiles control how application traffic is routed to Bigtable clusters located across different zones in the same instance. They allow applications to balance workloads across multiple clusters or direct traffic to a specific cluster during maintenance, enabling failover without service interruption.
Dual-region configurations keep data within a single country to meet legal requirements, whereas multi-region configurations distribute data across wider geographic areas to lower read latency for global users. Both configuration types provide the same high level of availability.
StudyCerts
StudyCerts