An application engineer accidentally deleted critical database tables in a production Cloud SQL for MySQL instance named `prod-db`. You need to perform a Point-in-Time Recovery (PITR) to restore the database to its state exactly 30 minutes prior to the deletion into a new instance named `prod-db-restored`, verify the data, and switch application traffic. In what order should you execute these operational recovery steps?
- 1Identify the precise timestamp immediately preceding the accidental table drop from Cloud Audit Logs.
- 2Run the `gcloud sql instances clone` command specifying `prod-db` as the source, `prod-db-restored` as the target, and the `--point-in-time` parameter set to the identified timestamp.
- 3Connect to `prod-db-restored` and validate that the missing tables and records have been successfully recovered.
- 4Update application database configuration settings or connection strings to point to the IP address or instance connection name of `prod-db-restored`.
Answer
The correct operational sequence is: first, identify the target timestamp from Cloud Audit Logs; second, execute `gcloud sql instances clone` with the `--point-in-time` parameter; third, connect to the new instance to validate recovered data; and fourth, update application database connection configurations to point to the restored instance.
The correct recovery procedure starts by identifying the exact timestamp of the event using Cloud Audit Logs. Next, `gcloud sql instances clone` is executed with the `--point-in-time` flag to create a new instance initialized to that timestamp. Once the instance is provisions, data integrity is verified. Finally, application configurations are updated to point to the newly restored instance.
Step-by-Step Solution
Key Concept
Cloud SQL Point-in-Time Recovery (PITR) using gcloud instances clone