Explanation:
To minimize data loss in a scenario where a Cloud SQL for MySQL database has suffered massive data corruption due to an application error, the best approach is to perform a point-in-time recovery (PITR). This method allows you to restore the database to a specific point in time before the corruption occurred, leveraging the binary logs that were enabled. Option C is the correct choice because PITR is designed for such scenarios, ensuring minimal data loss by restoring the database to a state just before the corruption. Option A suggests using the last automated backup, which might not include all transactions up to the point of corruption, leading to more data loss. Option B is not practical for minimizing data loss as it involves reloading data from CSV files, which would not include any transactions after the initialization. Option D suggests failing over to the HA instance, but this would not help recover from data corruption as the HA instance would also reflect the corrupted state due to replication.
Ultimate access to all questions.
No comments yet.
How can you minimize data loss in a Cloud SQL for MySQL database with high availability (HA) and binary logging enabled after a critical application update caused significant data corruption?
A
Open the Google Cloud Console, navigate to SQL > Backups, and select the last version of the automated backup before the corruption.
B
Reload the Cloud SQL for MySQL database using the LOAD DATA command to load data from CSV files that were used to initialize the instance.
C
Perform a point-in-time recovery of your Cloud SQL for MySQL database, selecting a date and time before the data was corrupted.
D
Fail over to the Cloud SQL for MySQL HA instance. Use that instance to recover the transactions that occurred before the corruption.