An enterprise application utilizing Cloud SQL for PostgreSQL experienced data corruption due to an accidental table deletion at 14:15:00 UTC. Point-in-time recovery (PITR) via write-ahead logging is active on the instance `db-main`. You must restore the database to its exact state at 14:14:00 UTC into a new instance and cut over production traffic while retaining the original instance for post-mortem inspection.
In what order should you execute these operational recovery steps?
- 1Identify the target UTC timestamp (14:14:00 UTC) immediately preceding the table deletion.
- 2Run `gcloud sql instances clone db-main db-recovery --point-in-time="2026-07-30T14:14:00.000000Z"` to provision the restored instance.
- 3Execute validation queries on `db-recovery` to confirm table structure and data completeness.
- 4Update application connection strings and DNS entries to direct database traffic to `db-recovery`.
Cevap
The correct sequence of operations is: 1) Identify the target pre-corruption timestamp (14:14:00 UTC), 2) Clone the instance to `db-recovery` at that point in time using the `gcloud sql instances clone` command with the `--point-in-time` flag, 3) Perform data integrity validation on `db-recovery`, and 4) Update application connection parameters to redirect production traffic to `db-recovery`.
Point-in-Time Recovery (PITR) in Cloud SQL for PostgreSQL is performed by cloning the source instance into a new target instance using `gcloud sql instances clone` with the `--point-in-time` parameter. The workflow requires identifying the timestamp prior to corruption first, running the clone command second, validating data integrity on the new instance third, and updating application connection strings fourth.
Adım Adım Çözüm
Anahtar Kavram
Cloud SQL Point-in-Time Recovery (PITR) and Instance Cloning Workflow