This page describes how to use point-in-time recovery (PITR) to restore your primary Cloud SQL instance.
To learn more about PITR, see Point-in-time recovery (PITR) .
By default, PITR is enabled when you create a Cloud SQL Enterprise Plus edition instance, regardless of whether you create the instance by using the Google Cloud console, gcloud CLI , Terraform, or the Cloud SQL Admin API.
If you create a Cloud SQL Enterprise edition instance in the Google Cloud console, then PITR is enabled by default. Otherwise, if you create the instance by using the gcloud CLI , Terraform, or the Cloud SQL Admin API, then you must manually enable PITR.
Log storage for PITR
Cloud SQL uses binary logs for PITR.On August 11, 2023, we launched storing transaction logs for PITR in Cloud Storage . Since this launch, the following conditions apply:
- All Cloud SQL Enterprise Plus edition instances store their binary logs used for PITR in Cloud Storage. Only Cloud SQL Enterprise Plus edition instances that you upgraded from Cloud SQL Enterprise edition before April 1, 2024 and had PITR enabled before August 11, 2023 continue to store their logs for PITR on disk .
-
Cloud SQL Enterprise edition instances created with PITR enabled before August 11, 2023 continue to store their logs for PITR on disk .
-
If you upgrade a Cloud SQL Enterprise edition instance after April 1, 2024 that stores transaction logs for PITR on disk to Cloud SQL Enterprise Plus edition, then the upgrade process switches the storage location of the transaction logs used for PITR to Cloud Storage for you. For more information, see Upgrade an instance to Cloud SQL Enterprise Plus edition by using in-place upgrade .
-
All Cloud SQL Enterprise edition instances that you create with PITR enabled after August 11, 2023 store logs used for PITR in Cloud Storage.
For more information about how to check the storage location of the transaction logs used for PITR, see Check the storage location of transaction logs used for PITR .
For instances that store binary logs only on disk, you can switch the storage location of the transaction logs used for PITR from disk to Cloud Storage by using gcloud CLI or the Cloud SQL Admin API. For more information, see Switch transaction log storage to Cloud Storage .
Log retention period
Cloud SQL retains transaction logs in Cloud Storage for up to the
value set in the transactionLogRetentionDays
PITR configuration setting.
This value can range from 1 to 35 days for Cloud SQL Enterprise Plus edition
and 1 to 7 days for Cloud SQL Enterprise edition. If a value for this parameter isn't set,
then the default transaction log retention period is 14 days for Cloud SQL Enterprise Plus edition
instances and 7 days for Cloud SQL Enterprise edition instances. For more information on how
to set the transaction log retention days,
see Set transaction log retention
.
Although an instance stores the binary logs used for
PITR in Cloud Storage, the instance also keeps a smaller number of
duplicate binary logs on disk to allow for replication of the
logs to Cloud Storage. By default, when you create an instance with PITR enabled,
the instance stores its binary logs for PITR
in Cloud Storage. Cloud SQL also sets the value of
the expire_logs_days
and binlog_expire_logs_seconds
flags to the equivalent of one day automatically. This translates to one day of logs on disk.
For binary logs used for PITR that are stored on disk , Cloud SQL retains the logs for the minimum value set for one of the following configurations:
- The
transactionLogRetentionDays
backup configuration setting -
The
expire_logs_days
or thebinlog_expire_logs_seconds
flagModifying the values of these flags can affect the behavior of PITR recovery and how many days worth of logs are stored on disk. We don't recommend that you configure the value of either of these flags to
0
. For more information about these flags, see Configure database flags .
For customer-managed encryption key (CMEK)-enabled instances
,
binary logs are encrypted using the latest version of the
CMEK. To perform a restore, all versions of the key that were the latest versions for the
number of days that you configured for the retained-transaction-log-days
parameter must be available.
Logs and disk usage
Logs are generated regularly and use storage space. The binary
logs are deleted automatically with their associated automatic backup, which
happens after the value that's set for transactionLogRetentionDays
is met.
To find out how much disk is being used by the binary logs,
check the bytes_used_by_data_type
metric for the instance. The value for the binlog
data type returns
the size of the binlogs on the disk. For instances that store transaction logs
used for PITR on disk,
Cloud SQL purges data from the disk daily to meet the transactionLogRetentionDays
PITR setting,
as described in Automatic backup and transaction log retention
.
However, if you set the expire_logs_days
flag
to a value that's lower than transaction log retention days,
then Cloud SQL can purge the binary logs sooner.
If the size of your binary logs is causing an issue for your instance:
- Check whether your instance is storing logs on disk . You can switch the storage location of the logs used for PITR from disk to Cloud Storage without downtime by using gcloud CLI or the Cloud SQL Admin API. If you are using Cloud SQL Enterprise edition, then you can also upgrade to Cloud SQL Enterprise Plus edition to switch the storage location of your PITR logs.
-
You can increase the instance storage size. However, the binary log size increase in disk usage might be temporary.
-
We recommend enabling automatic storage increase to avoid unexpected storage issues.
-
If you want to delete logs and recover storage space on disk, then you can deactivate PITR without re-enabling it. However, decreasing the storage used doesn't shrink the size of the disk provisioned for the instance.
-
Logs are purged once daily, not continuously. Setting log retention to two days means that at least two days of logs, and at most three days of logs, are retained. We recommend setting the number of backups to one more than the days of log retention.
For example, if you specify
7
for the value of thetransactionLogRetentionDays
parameter, then for thebackupRetentionSettings
parameter, set the number ofretainedBackups
to8
.
For more information about PITR, see Point-in-time recovery (PITR) .
After you complete the switch of the storage location of transaction logs to Cloud Storage,
you can free up disk space by reducing the values of the expire_logs_days
and binlog_expire_logs_seconds
flags. To check the status of the switch, see Check the storage location of transaction logs used for PITR
.
Freeing disk space can help you save on disk usage
costs in Cloud SQL. However, if you want additional logs to be available
on disk— for example, to browse the binary logs
with
the mysqlbinlog
utility—
then increase the values of these flags. Cloud SQL retains
binary logs on disk for the minimum of the transaction log
retention days or the values set for the flags.
Enable PITR
When you create a new instance in the Google Cloud console, both Automated backups and Enable point-in-time recovery are automatically enabled.The following procedure enables PITR on an existing primary instance.
Console
-
In the Google Cloud console, go to the Cloud SQL Instances page.
- Open the more actions menu
for the instance you want to enable PITR on and click Edit .
- Under Customize your instance , expand the Data Protection section.
- Select the Enable point-in-time recovery checkbox.
- In the Days of logs field, enter the number of days to retain logs, from 1-35 for Cloud SQL Enterprise Plus edition, or 1-7 for Cloud SQL Enterprise edition.
- Click Save .
gcloud
- Display the instance overview:
gcloud sql instances describe INSTANCE_NAME
- If you see
enabled: false
in thebackupConfiguration
section, enable scheduled backups:gcloud sql instances patch INSTANCE_NAME \ --backup-start-time= HH:MM
Specify the
backup-start-time
parameter using 24-hour time in UTC±00 time zone. - Enable PITR:
gcloud sql instances patch INSTANCE_NAME \ --enable-bin-log
If you're enabling PITR on a primary instance, you can also configure the number of days for which you want to retain transaction logs by adding the following parameter:
--retained-transaction-log-days= RETAINED_TRANSACTION_LOG_DAYS
- Confirm your change:
gcloud sql instances describe INSTANCE_NAME
In the
backupConfiguration
section, you seebinaryLogEnabled: true
if the change was successful.
Terraform
To enable PITR, use a Terraform resource .
Apply the changes
To apply your Terraform configuration in a Google Cloud project, complete the steps in the following sections.
Prepare Cloud Shell
- Launch Cloud Shell .
-
Set the default Google Cloud project where you want to apply your Terraform configurations.
You only need to run this command once per project, and you can run it in any directory.
export GOOGLE_CLOUD_PROJECT= PROJECT_ID
Environment variables are overridden if you set explicit values in the Terraform configuration file.
Prepare the directory
Each Terraform configuration file must have its own directory (also called a root module ).
- In Cloud Shell
, create a directory and a new
file within that directory. The filename must have the
.tf
extension—for examplemain.tf
. In this tutorial, the file is referred to asmain.tf
.mkdir DIRECTORY && cd DIRECTORY && touch main.tf
-
If you are following a tutorial, you can copy the sample code in each section or step.
Copy the sample code into the newly created
main.tf
.Optionally, copy the code from GitHub. This is recommended when the Terraform snippet is part of an end-to-end solution.
- Review and modify the sample parameters to apply to your environment.
- Save your changes.
- Initialize Terraform. You only need to do this once per directory.
terraform init
Optionally, to use the latest Google provider version, include the
-upgrade
option:terraform init -upgrade
Apply the changes
- Review the configuration and verify that the resources that Terraform is going to create or
update match your expectations:
terraform plan
Make corrections to the configuration as necessary.
- Apply the Terraform configuration by running the following command and entering
yes
at the prompt:terraform apply
Wait until Terraform displays the "Apply complete!" message.
- Open your Google Cloud project to view the results. In the Google Cloud console, navigate to your resources in the UI to make sure that Terraform has created or updated them.
Delete the changes
To delete your changes, do the following:
- To disable deletion protection, in your Terraform configuration file set the
deletion_protection
argument tofalse
.deletion_protection = "false"
- Apply the updated Terraform configuration by running the following command and
entering
yes
at the prompt:terraform apply
-
Remove resources previously applied with your Terraform configuration by running the following command and entering
yes
at the prompt:terraform destroy
REST v1
Before using any of the request data, make the following replacements:
- PROJECT_ID : the ID or project number of the Google Cloud project that contains the instance
- INSTANCE_NAME : the name of the primary or read replica instance that you're configuring for high availability
- START_TIME : the time (in hours and minutes)
HTTP method and URL:
PATCH https://sqladmin.googleapis.com/v1/projects/ PROJECT_ID /instances/ INSTANCE_NAME
Request JSON body:
{ "settings": { "backupConfiguration": { "startTime": " START_TIME ", "enabled": true, "binaryLogEnabled": true } } }
To send your request, expand one of these options:
You should receive a JSON response similar to the following:
REST v1beta4
Before using any of the request data, make the following replacements:
- PROJECT_ID : the ID or project number of the Google Cloud project that contains the instance
- INSTANCE_NAME : the name of the primary or read replica instance that you're configuring for high availability
- START_TIME : the time (in hours and minutes)
HTTP method and URL:
PATCH https://sqladmin.googleapis.com/v1beta4/projects/ PROJECT_ID /instances/ INSTANCE_NAME
Request JSON body:
{ "settings": { "backupConfiguration": { "startTime": " START_TIME ", "enabled": true, "binaryLogEnabled": true } } }
To send your request, expand one of these options:
You should receive a JSON response similar to the following:
Perform PITR by a using timestamp
Using a timestamp is the recommended approach for performing
PITR.
Cloud SQL uses the mysqlbinlog
utility to restore
instances up to a specific time. For more information about the mysqlbinlog
utility, see the MySQL reference documentation
.
To complete the following task, you must have the following:
- Binary logging and backups enabled for the instance, with continuous binary logs since the last backup before the event from which you want to recover. For more information, see Enable binary logging .
- A timestamp to define the recovery point. The events that occur at and after this timestamp aren't reflected in the new instance.
Console
-
In the Google Cloud console, go to the Cloud SQL Instances page.
- Open the more actions menu
for the instance you want to recover and click Create clone .
- Optionally, on the Create a clone page, update the ID of the new clone.
- Select Clone from an earlier point in time .
- Enter a PITR time.
- Click Create clone .
gcloud
Create a clone using PITR.
Replace the following:
- SOURCE_INSTANCE_NAME - Name of the instance you're restoring from.
- NEW_INSTANCE_NAME - Name for the clone.
- TIMESTAMP - UTC timezone for the source instance in RFC 3339 format. For example, 2012-11-15T16:19:00.094Z.
gcloud sql instances clone SOURCE_INSTANCE_NAME \ NEW_INSTANCE_NAME \ --point-in-time ' TIMESTAMP '
REST v1
Before using any of the request data, make the following replacements:
- project-id : The project ID
- target-instance-id : The target instance ID
- source-instance-id : The source instance ID
- restore-timestamp The point-in-time to restore up to
HTTP method and URL:
POST https://sqladmin.googleapis.com/v1/projects/ project-id /instances/ source-instance-id /clone
Request JSON body:
{ "cloneContext": { "kind": "sql#cloneContext", "destinationInstanceName": " target-instance-id ", "pointInTime": " restore-timestamp " } }
To send your request, expand one of these options:
You should receive a JSON response similar to the following:
REST v1beta4
Before using any of the request data, make the following replacements:
- project-id : The project ID
- target-instance-id : The target instance ID
- source-instance-id : The source instance ID
- restore-timestamp The point-in-time to restore up to
HTTP method and URL:
POST https://sqladmin.googleapis.com/sql/v1beta4/projects/ project-id /instances/ source-instance-id /clone
Request JSON body:
{ "cloneContext": { "kind": "sql#cloneContext", "destinationInstanceName": " target-instance-id ", "pointInTime": " restore-timestamp " } }
To send your request, expand one of these options:
You should receive a JSON response similar to the following:
Deactivate PITR
Console
-
In the Google Cloud console, go to the Cloud SQL Instances page.
- Open the more actions menu
for the instance you want to deactivate and select Edit .
- Under Customize your instance , expand the Data Protection section.
- Clear Enable point-in-time recovery .
- Click Save .
gcloud
- Deactivate point-in-time recovery:
gcloud sql instances patch INSTANCE_NAME \ --no-enable-bin-log
- Confirm your change:
gcloud sql instances describe INSTANCE_NAME
In the
backupConfiguration
section, you seebinaryLogEnabled: false
if the change was successful.
REST v1
Before using any of the request data, make the following replacements:
- project-id : The project ID
- instance-id : The instance ID
HTTP method and URL:
PATCH https://sqladmin.googleapis.com/v1/projects/ project-id /instances/ instance-id
Request JSON body:
{ "settings": { "backupConfiguration": { "enabled": false, "binaryLogEnabled": false } } }
To send your request, expand one of these options:
You should receive a JSON response similar to the following:
REST v1beta4
Before using any of the request data, make the following replacements:
- project-id : The project ID
- instance-id : The instance ID
HTTP method and URL:
PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/ project-id /instances/ instance-id
Request JSON body:
{ "settings": { "backupConfiguration": { "enabled": false, "binaryLogEnabled": false } } }
To send your request, expand one of these options:
You should receive a JSON response similar to the following:
Check the storage location of transaction logs used for PITR
You can check where your Cloud SQL instance is storing the transaction logs used for PITR.
gcloud
To determine whether your instance stores logs for PITR on disk or Cloud Storage, use the following command:
gcloud sql instances describe INSTANCE_NAME
Replace INSTANCE_NAME with the name of the instance.
You can also check the storage location of the transaction logs for multiple instances in the same project. To determine the location for multiple instances, use the following command:
gcloud sql instances list --show-transactional-log-storage-state
Example response:
NAME DATABASE_VERSION LOCATION TRANSACTIONAL_LOG_STORAGE_STATE my_01 MYSQL_8_0 us-central-1 DISK my_02 MYSQL_8_0 us-central-1 CLOUD_STORAGE ...
In the output of the command, the transactionalLogStorageState
field or the TRANSACTIONAL_LOG_STORAGE_STATE
column provides information about where the transaction
logs for PITR are stored for the instance.
The possible transaction log
storage states are the following:
-
DISK
: the instance stores the transaction logs used for PITR on disk. If you upgrade a Cloud SQL Enterprise edition instance to Cloud SQL Enterprise Plus edition, then the upgrade process switches the log storage location to Cloud Storage automatically. For more information, see Upgrade an instance to Cloud SQL Enterprise Plus edition by using in-place upgrade . You can also choose to switch the storage location by using gcloud CLI or the Cloud SQL Admin API without upgrading the edition of your instance. For more information, see Switch transaction log storage to Cloud Storage . -
SWITCHING_TO_CLOUD_STORAGE
: the instance is switching the storage location for the PITR transaction logs to Cloud Storage. -
SWITCHED_TO_CLOUD_STORAGE
: the instance has completed the switching the storage location for PITR transaction logs from disk to Cloud Storage. -
CLOUD_STORAGE
: the instance stores the transaction logs used for PITR in Cloud Storage.
Switch transaction log storage to Cloud Storage
If your instance stores its transaction logs used for PITR on disk, then you can switch the storage location to Cloud Storage. The switch operation takes approximately the duration of the transaction log retention period (days) to complete. During the operation, you can check the status by using the command in Check the storage location of transaction logs used for PITR .
After the switch to Cloud Storage is complete, you can free up disk space on your instance. For more information about how to free up disk space, see Logs and disk usage .
gcloud
To switch the storage location to Cloud Storage, use the following command:
gcloud sql instances patch INSTANCE_NAME \ --switch-transaction-logs-to-cloud-storage
Replace INSTANCE_NAME with the name of the instance. The instance must be a primary instance and not a replica instance. The response is similar to the following:
The following message is used for the patch API method. {"name": " INSTANCE_NAME ", "project": " PROJECT_NAME ", "switchTransactionalLogsToCloudStorageEnabled": "true"} Patching Cloud SQL instance...done. Updated [https://sqladmin.prod.googleapis.com/v1/projects/ PROJECT_NAME /instances/ INSTANCE_NAME ].
If the command returns an error, then see Troubleshoot the switch to Cloud Storage for possible next steps.
REST v1
Before using any of the request data, make the following replacements:
- PROJECT_ID : the project ID.
- INSTANCE_ID : the instance ID. The instance must be a primary instance and not a replica instance.
HTTP method and URL:
PATCH https://sqladmin.googleapis.com/v1/projects/ PROJECT_ID /instances/ INSTANCE_ID
Request JSON body:
{ "switchTransactionLogsToCloudStorageEnabled": true }
To send your request, expand one of these options:
You should receive a JSON response similar to the following:
If the request returns an error, then see Troubleshoot the switch to Cloud Storage for possible next steps.
REST v1beta4
Before using any of the request data, make the following replacements:
- PROJECT_ID : the project ID.
- INSTANCE_ID : the instance ID. The instance must be a primary instance and not a replica instance.
HTTP method and URL:
PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/ PROJECT_ID /instances/ INSTANCE_ID
Request JSON body:
{ "switchTransactionLogsToCloudStorageEnabled": true }
To send your request, expand one of these options:
You should receive a JSON response similar to the following:
If the request returns an error, then see Troubleshoot the switch to Cloud Storage for possible next steps.
Set transaction log retention
To set the number of days to retain binary logs:
Console
-
In the Google Cloud console, go to the Cloud SQL Instances page.
- Open the more actions menu
for the instance you want to set the transaction log on and select Edit .
- Under Customize your instance , expand the Data Protection section.
- In the Enable point-in-time recovery section, expand Advanced options .
- Enter the number of days to retain logs, from 1-35 for Cloud SQL Enterprise Plus edition or 1-7 for Cloud SQL Enterprise edition.
- Click Save .
gcloud
Edit the instance to set the number of days to retain binary logs.
Replace the following:
- INSTANCE-NAME - The name of the instance you want to set the transaction log on.
- DAYS-TO-RETAIN - The number of days of transaction logs to keep. For Cloud SQL Enterprise Plus edition, the valid range is between 1 and 35 days, with a default of 14 days. For Cloud SQL Enterprise edition, the valid range is between 1 and 7 days, with a default of 7 days. If no value is specified, then the default value is used. Only valid when PITR is enabled. Keeping more days of transaction logs requires bigger storage size.
gcloud sql instances patch INSTANCE-NAME \ --retained-transaction-log-days= DAYS-TO-RETAIN