Exam Professional Cloud Database Engineer topic 1 question 25 discussion

C. The question specifically mentions binary logging and the binary logs are used by point-in-time recovery. D doesn’t buy you anything since the corrupt data would also be on the HA replica you fail over to. B looks like a lot of work and if the Cloud SQL instance were instantiated a while ago, option B could take a long time. A would work but the backup could have been taken a while before the corruption began. In which case restoring using that backup would wipe all the good data up to the point of corruption. The question asks for minimal data loss and the only way to ensure that is to restore to a point-in-time just before the corruption began.

Point in time recovery helps us to go back exactly a minute before corruption. This will leave us with most of the data before the corruption

unrelated but this was also a question from PCA. and the same answer C

C. Perform a point-in-time recovery of your Cloud SQL for MySQL database, selecting a date and time before the data was corrupted. Performing a point-in-time recovery is the best option to minimize data loss in case of data corruption. Point-in-time recovery restores the database to a specific point in time before the data was corrupted, by replaying the binary logs that were generated since the selected time. This option is available when binary logging is enabled on Cloud SQL for MySQL with high availability. Option A, restoring from an automated backup, can lead to data loss because it might not contain all the changes made to the database after the backup was taken. Option B, reloading the database from CSV files, can be time-consuming and may lead to data loss if the files used for initialization are not up to date. Option D, failing over to the Cloud SQL for MySQL HA instance, may not help in this scenario as the data corruption is replicated to the HA instance, and it is intended to be used for high availability and not for disaster recovery.

A. Originally I thought it was C, but after reading mysql best practices as well as Kloudgeek link carefully I changed my answer. In Cloud SQL best-practice: https://cloud.google.com/sql/docs/mysql/best-practices "A point-in-time recovery always creates a new instance; you cannot perform a point-in-time recovery to an existing instance." Kloudgeek's link (why gcloud command use clone?): https://cloud.google.com/sql/docs/mysql/backup-recovery/pitr#perform-pitr-binlog "gcloud sql instances clone instance1 \ instance1-clone \ --bin-log-file-name=mysql-bin.0000031 \ --bin-log-position=107" It seems to me that the question does not expect Cloud SQL instance switched just because of data corruption.

C: Perform a point-in-time recovery of your Cloud SQL for MySQL database, selecting a date and time ***** before the data was corrupted.

C is correct answer

Binary logging --> Point in Recovery

Since it is retaining transaction log, point in time recovery is enabled and that would be the best option

Correct Answer C: Binary Logging enabled, with that you can identify the point of time the data was good and recover from that point time. https://cloud.google.com/sql/docs/mysql/backup-recovery/pitr#perform_the_point-in-time_recovery_using_binary_log_positions