yes A is correct, whe creating ne cloud sql instance there is an option
"Multiple zones (Highly available)
Automatic failover to another zone within your selected region. Recommended for production instances. Increases cost."
A (failover replicas) as this is an old question:
In a legacy HA configuration, a Cloud SQL for MySQL instance uses a failover replica to add high availability to the instance. This functionality isn't available in Google Cloud console.
The new configuration doesn't use failover replicas. Instead, it uses Google's regional persistent disks, which synchronously replicate data at the block-level between two zones in a region.
https://cloud.google.com/sql/docs/mysql/configure-legacy-ha
Option A is good fro leagacy soultion
Note: Cloud SQL plans to discontinue support for legacy HA instances in the future and will soon be announcing a date to do so. Currently, legacy HA instances are still covered by the Cloud SQL SLA. We recommend you upgrade your existing legacy HA instances to regional persistent disk HA instances and create new instances using regional persistent disk HA as soon as possible
Option C makes more sense in this regrard
A - Although it is legacy and will be deprecated. The correct answer is not an option--
"The legacy configuration for high availability used a failover replica instance. The new configuration does not use a failover replica. Instead, it uses Google's regional persistent disks, which synchronously replicate data at the block level between two zones in a region."
Failover Replica: By creating a failover replica in another zone within the same region, you establish a high-availability configuration. The failover replica is kept in sync with the primary instance, and it can quickly take over in case of a failure of the primary instance.
Same Region: Placing the failover replica in the same region ensures minimal latency and data consistency. In the event of a zone failure, the failover can happen within the same region, reducing potential downtime.
Zone Resilience: Google Cloud's regional design ensures that zones within a region are independent of each other, which adds resilience to zone failures.
Automatic Failover: In case of a primary instance failure, Cloud SQL will automatically promote the failover replica to become the new primary instance, minimizing downtime.
Cross-region read replicas
Cross-region replication lets you create a read replica in a different region from the primary instance. You create a cross-region read replica the same way as you create an in-region replica.
Cross-region replicas:
Improve read performance by making replicas available closer to your application's region.
Provide additional disaster recovery capability to guard against a regional failure.
Let you migrate data from one region to another.
https://cloud.google.com/sql/docs/mysql/replication#cross-region-read-replicas:~:text=memory%20(OOM)%20events.-,Cross%2Dregion%20read%20replicas,Let%20you%20migrate%20data%20from%20one%20region%20to%20another.,-See%20Promoting%20replicas
The legacy process for adding high availability to MySQL instances uses a failover replica. The legacy functionality isn't available in the Google Cloud console. See Legacy configuration: Creating a new instance configured for high availability or Legacy configuration: Configuring an existing instance for high availability.
The correct answer is most probably B as this his scenario has an update(As of July 2023). Failover replicas are not available anymore. Same region different zone read replicas are used in case of a failover or if primary zone is not available
The answer is B, the failover replica is a legacy feature.
See here: https://cloud.google.com/sql/docs/mysql/high-availability#legacy_mysql_high_availability_option
read replica (B) and external read replica (C) doesn't make sense here, since we potentially need all the functionalities. Using Cloud SQL in a region combined with Cloud Storage backup may not be the best choice (D) thinking about compliance reasons starting from what has been asked, it seems also "too much" compared with A that fullfills the request with simpler actions. Also, compliance is required at the regional level, so then A fits.
Answer A, key words to remember, High Scale use extra read replica. High availablity use extra failure replica. Both should be in different zone but in same region.
Answer is B: https://cloud.google.com/sql/docs/mysql/replication#read-replicas
'As a best practice, put read replicas in a different zone than the primary instance when you use HA on your primary instance'
A is the answer.
https://cloud.google.com/sql/docs/mysql/high-availability#HA-configuration
The HA configuration provides data redundancy. A Cloud SQL instance configured for HA is also called a regional instance and has a primary and secondary zone within the configured region. Within a regional instance, the configuration is made up of a primary instance and a standby instance. Through synchronous replication to each zone's persistent disk, all writes made to the primary instance are replicated to disks in both zones before a transaction is reported as committed. In the event of an instance or zone failure, the standby instance becomes the new primary instance. Users are then rerouted to the new primary instance. This process is called a failover.
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.
madhu1171
Highly Voted 4 years, 7 months agotycho
2 years, 10 months ago[Removed]
Highly Voted 4 years, 7 months agomothkuri
Most Recent 8 months agoMaxNRG
10 months, 2 weeks agopss111423
11 months, 1 week agoemmylou
11 months, 2 weeks agobarnac1es
1 year, 1 month agosamstar4180
1 year, 2 months agowan2three
1 year, 3 months agoMoeHaydar
1 year, 3 months agoKK0202
1 year, 3 months agoMBRSDG
1 year, 5 months agoforepick
1 year, 4 months agovaga1
1 year, 5 months agowjtb
1 year, 7 months agomusumusu
1 year, 8 months agodesertlotus1211
1 year, 9 months agodesertlotus1211
1 year, 9 months agozellck
1 year, 11 months ago