You are designing a system that requires an ACID-compliant database. You must ensure that the system requires minimal human intervention in case of a failure. What should you do?
A.
Configure a Cloud SQL for MySQL instance with point-in-time recovery enabled.
B.
Configure a Cloud SQL for PostgreSQL instance with high availability enabled.
C.
Configure a Bigtable instance with more than one cluster.
D.
Configure a BigQuery table with a multi-region configuration.
We exclude [C[ as non ACID and [D] for being invalid (location is configured on Dataset level, not Table).
Then, let's focus on "minimal human intervention in case of a failure" requirement in order to eliminate one answer among [A] and [B].
Basically, we have to compare point-in-time recovery with high availability. It doesn't matter whether it's about MySQL or PostgreSQL since both databases support those features.
- Point-in-time recovery logs are created automatically, but restoring an instance in case of failure requires manual steps (described here: https://cloud.google.com/sql/docs/mysql/backup-recovery/pitr#perform-pitr)
- High availability, in case of failure requires no human intervention: "If an HA-configured instance becomes unresponsive, Cloud SQL automatically switches to serving data from the standby instance." (from https://cloud.google.com/sql/docs/postgres/high-availability#failover-overview)
So answer [B] wins.
The best option to meet the ACID compliance and minimal human intervention requirements is to configure a Cloud SQL for PostgreSQL instance with high availability enabled.
Key reasons:
Cloud SQL for PostgreSQL provides full ACID compliance, unlike Bigtable which provides only atomicity and consistency guarantees.
Enabling high availability removes the need for manual failover as Cloud SQL will automatically failover to a standby replica if the leader instance goes down.
Point-in-time recovery in MySQL requires manual intervention to restore data if needed.
BigQuery does not provide transactional guarantees required for an ACID database.
Therefore, a Cloud SQL for PostgreSQL instance with high availability meets the ACID and minimal intervention requirements best. The automatic failover will ensure availability and uptime without administrative effort.
I vote for D - BigQuery with multi region configuration.
According to https://cloud.google.com/bigquery/docs/introduction , BigQuery support ACID and automatically replicated for high availability.
"""BigQuery stores data using a columnar storage format that is optimized for analytical queries. BigQuery presents data in tables, rows, and columns and provides full support for database transaction semantics (ACID). BigQuery storage is automatically replicated across multiple locations to provide high availability."""
Answer B,
ACID -compliant database are Spanner and CloudSQL
Option A could be the answer if they setup a secondary or failure replicas and auto maintenance window that could trigger in non business hours.
Option B, does not explain about extra replica but in postgresql Highavailablity option means the same extra replicas instances are available for emergency.
B is the answer.
https://cloud.google.com/sql/docs/postgres/high-availability#HA-configuration
The purpose of an HA configuration is to reduce downtime when a zone or instance becomes unavailable. This might happen during a zonal outage, or when an instance runs out of memory. With HA, your data continues to be available to client applications.
A voting comment increases the vote count for the chosen answer by one.
Upvoting a comment with a selected answer will also increase the vote count towards that answer by one.
So if you see a comment that you already agree with, you can upvote it instead of posting a new comment.
NicolasN
Highly Voted 2 years agosquishy_fishy
1 year, 1 month agoMcloudgirl
2 years agoedre
Most Recent 4 months, 1 week agoMaxNRG
11 months, 1 week ago[Removed]
1 year, 3 months agovamgcp
1 year, 4 months agomusumusu
1 year, 9 months agoAzureDP900
1 year, 11 months agozellck
1 year, 12 months agosamirzubair
2 years agoJohn_Pongthorn
2 years, 2 months agoTNT87
2 years, 2 months agoRemi2021
2 years, 2 months agoAWSandeep
2 years, 2 months agoducc
2 years, 2 months ago