Upgrade an instance to Cloud SQL Enterprise Plus edition by using in-place upgrade


This page shows you how to use the in-place upgrade method to upgrade a Cloud SQL Enterprise edition instance to Cloud SQL Enterprise Plus edition. Additionally, it also describes the procedure to downgrade a Cloud SQL Enterprise Plus edition instance to Cloud SQL Enterprise edition.

Upgrading to Cloud SQL Enterprise Plus edition provides you with several benefits and performance enhancements. For more information, see Introduction to Cloud SQL for MySQL editions.

To enable these enhancements for your existing Cloud SQL Enterprise edition instances, you must upgrade them to Cloud SQL Enterprise Plus edition. The upgrade process takes a few minutes to complete with an expected downtime of less than 60 seconds. Additionally, this process doesn't require your applications to change the endpoints they connect to.

Before you begin

  • Ensure that your instance uses a solid state drive (SSD).

Check the storage location of the transaction logs used for PITR

All Cloud SQL Enterprise Plus edition instances are automatically enabled with point-in-time recovery (PITR). If the Cloud SQL Enterprise edition instance that you want to upgrade stores the binary logs used for PITR on disk, then the upgrade process to Cloud SQL Enterprise Plus edition switches the storage location of the binary logs from disk to Cloud Storage.

Before you upgrade to Cloud SQL Enterprise Plus edition, check whether your Cloud SQL Enterprise edition instance will undergo the storage location switch for the binary logs used for PITR. For more information and instructions on how to check your instance, see Check the storage location of transaction logs used for PITR.

For more information about switching the transaction log storage location in the upgrade process, see Storage location of transaction logs used for PITR.

Upgrade an instance to Cloud SQL Enterprise Plus edition

Use the procedure in this section to upgrade a Cloud SQL Enterprise edition instance to Cloud SQL Enterprise Plus edition.

Console

  1. In the Google Cloud console, go to the Cloud SQL Instances page.

    Go to Cloud SQL Instances

  2. To open the Overview page of an instance, click the instance name.
  3. Click Edit.
  4. In the Choose a Cloud SQL edition section, click Upgrade.
  5. In the Upgrade to Enterprise Plus panel, enter your instance ID and then click Upgrade edition.

Alternatively, you can also upgrade an instance by clicking Upgrade in the Configuration section of the instance Overview page.

gcloud

The following code sample shows how to upgrade your instance to Cloud SQL Enterprise Plus edition:


gcloud sql instances patch INSTANCE_ID \
  --edition=enterprise-plus \
  --tier=MACHINE_TYPE \
  --project=PROJECT_ID

Replace the following:

  • PROJECT_ID: the project ID of the instance that you want to upgrade.
  • INSTANCE_ID: name of the instance that you want to upgrade.
  • MACHINE_TYPE: the machine type of the instance that you want to upgrade to. For more information about machine types for Cloud SQL Enterprise Plus edition, see Machine types for Cloud SQL Enterprise Plus edition instances.

REST

The following command upgrades your instance to Cloud SQL Enterprise edition and triggers a restart operation.

Before using any of the request data, make the following replacements:

  • PROJECT_ID: the project ID of the instance that you want to upgrade.
  • INSTANCE_ID: the instance ID of the instance that you want to upgrade.
  • MACHINE_TYPE: the machine type of the instance that you want to upgrade to. For more information about machine types for Cloud SQL Enterprise Plus edition, see Machine types for Cloud SQL Enterprise Plus edition instances.

HTTP method and URL:

PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID

Request JSON body:

{
  "settings": {
      "tier": "MACHINE_TYPE",
      "edition": "ENTERPRISE_PLUS",
      "dataCacheConfig": {
        "dataCacheEnabled": true
      },
  }
}

To send your request, expand one of these options:

You should receive a JSON response similar to the following:

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-16T02:32:12.281Z",
  "operationType": "UPDATE",
  "name": "OPERATION_ID",
  "targetId": "INSTANCE_ID",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

REST v1beta4

The following command upgrades your instance to Cloud SQL Enterprise edition and triggers a restart operation.

Before using any of the request data, make the following replacements:

  • PROJECT_ID: the project ID of the instance that you want to upgrade.
  • INSTANCE_ID: the instance ID of the instance that you want to upgrade.
  • MACHINE_TYPE: the machine type of the instance that you want to upgrade to. For more information about machine types for Cloud SQL Enterprise Plus edition, see Machine types for Cloud SQL Enterprise Plus edition instances.

HTTP method and URL:

PATCH https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID

Request JSON body:

{
  "settings": {
      "tier": "MACHINE_TYPE",
      "edition": "ENTERPRISE_PLUS",
      "dataCacheConfig": {
        "dataCacheEnabled": true
      },
  }
}

To send your request, expand one of these options:

You should receive a JSON response similar to the following:

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-16T02:32:12.281Z",
  "operationType": "UPDATE",
  "name": "OPERATION_ID",
  "targetId": "INSTANCE_ID",
  "selfLink": "https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

Storage location of transaction logs used for PITR

If your Cloud SQL Enterprise edition instance stores transaction logs for PITR on disk, then starting the upgrade process to Cloud SQL Enterprise Plus edition switches the storage location of these logs to Cloud Storage.

The following conditions apply to the location switch process:

  • The process takes approximately the duration of the transactionLogRetentionDays PITR configuration setting to complete the switch to Cloud Storage.
  • If you have values set for the expire_logs_days or binlog_expire_logs_seconds flag on your instance, then those values are preserved.
  • During the switch to Cloud Storage, you can't modify the values for the expire_logs_days or binlog_expire_logs_seconds flags on your instance.
  • During the switch to Cloud Storage, we recommend that you don't modify the transactionLogRetentionDays PITR configuration setting. Even if you do increase transactionLogRetentionDays, binary logs won't be retained on disk any longer than the default of 7 days for an Cloud SQL Enterprise edition instance.
  • While the switch is in progress, Cloud SQL only retains logs on disk for the minimum value of one of the following:
    • the transactionLogRetentionDays PITR configuration setting from before the switch, 7 days by default
    • the expire_logs_days or binlog_expire_logs_seconds flags manually set on your instance
  • After the switch, Cloud SQL retains the same amount of binary logs on disk that you had before the switch unless you have set the expire_logs_days or binlog_expire_logs_seconds flags on your instance. If you have set these flags, then Cloud SQL retains binary logs on disk based on the minimum value of the transactionLogRetentionDays configuration setting or the value of the flags.

Cloud SQL Enterprise Plus edition backup and log storage defaults

After the switch to Cloud Storage completes for an instance, Cloud SQL still retains copies of binary logs on disk for replication purposes. Storing binary logs on disk can be useful if you want to browse binary logs with the mysqlbinlog utility.

If you configured the expire_logs_days and binlog_expire_logs_seconds flags on your instance before the upgrade, then the configured values remain intact.

After the switch, since the binary logs that are used to perform PITR are now stored in Cloud Storage, ensure that the values of the flags reflect the retention of transaction logs on disk that you expect. Cloud SQL only retains logs on disk for the minimum value of one of the following:

  • the transactionLogRetentionDays PITR configuration setting before switch, 7 days by default
  • the expire_logs_days or binlog_expire_logs_seconds flags manually set on your instance

If you want to save disk space, then after the upgrade has completed, configure the value of the expire_logs_days or binlog_expire_logs_seconds flag to the equivalent of 1 day so you can reduce your allocated disk size and disk storage costs. For more information about transaction log storage and PITR, see Log storage for PITR.

After the upgrade to Cloud SQL Enterprise Plus edition completes, the default transaction log retention period for all upgraded instances is increased to 14 days. For this increase, and any other increase that you configure for the transaction log retention period, it takes up to the new and increased value to reach the full retention window of PITR. For example, if the old value for transaction log retention days is 7 and the new value is increased to 14, then the window for PITR for the first 7 days after the upgrade is only 7 days. On the 8th day, the window for PITR becomes 8 days, on the 9th day it becomes 9 days, until the retention window is finally increased to 14 days on the 14th day.

In addition, the default number of automated backups is increased from 8 to 15.

If you upgrade to Cloud SQL Enterprise Plus edition after doing a major version upgrade, then you won't be able to perform PITR to a point-in-time that occurs prior to the major version upgrade. This limitation applies even if your retention period covers that time period. You can restore your instance to a point-in-time after you started the major version upgrade.

Change to Cloud SQL Enterprise edition

Console

  1. In the Google Cloud console, go to the Cloud SQL Instances page.

    Go to Cloud SQL Instances

  2. To open the Overview page of an instance, click the instance name.
  3. Click Edit.
  4. In the Choose a Cloud SQL edition section, click Switch to Enterprise.
  5. In the Switch to Enterprise panel, enter your instance ID and then click Switch edition.

Alternatively, you can also change to Cloud SQL Enterprise edition by clicking Switch to Enterprise in Configuration section of the instance Overview page.

gcloud

The following code sample shows how to change your instance to Cloud SQL Enterprise edition:

gcloud sql instances patch INSTANCE_ID \
  --edition=enterprise \
  --tier=MACHINE_TYPE \
  --project=PROJECT_ID

Replace the following:
  • PROJECT_ID: the project ID of the instance.
  • INSTANCE_ID: name of the instance.
  • MACHINE_TYPE: the machine type of the instance that you want to switch to. For more information about machine types for Cloud SQL Enterprise edition, see Machine types for Cloud SQL Enterprise edition instances.

REST

The following command changes your instance to Cloud SQL Enterprise edition and triggers a restart operation.

Before using any of the request data, make the following replacements:

  • PROJECT_ID: the project ID of the instance.
  • INSTANCE_ID: the instance ID of the instance.
  • MACHINE_TYPE: the machine type of the instance that you want to switch to. For more information about machine types for Cloud SQL Enterprise edition, see Machine types for Cloud SQL Enterprise edition instances.

HTTP method and URL:

PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID

Request JSON body:

{
  "settings": {
      "tier": "MACHINE_TYPE",
      "edition": "ENTERPRISE"
  }
}

To send your request, expand one of these options:

You should receive a JSON response similar to the following:

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-16T02:32:12.281Z",
  "operationType": "UPDATE",
  "name": "OPERATION_ID",
  "targetId": "INSTANCE_ID",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

REST v1beta4

The following command changes your instance to Cloud SQL Enterprise edition and triggers a restart operation.

Before using any of the request data, make the following replacements:

  • PROJECT_ID: the project ID of the instance.
  • INSTANCE_ID: the instance ID of the instance.
  • MACHINE_TYPE: the machine type of the instance that you want to switch to. For more information about machine types for Cloud SQL Enterprise edition, see Machine types for Cloud SQL Enterprise edition instances.

HTTP method and URL:

PATCH https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID

Request JSON body:

{
  "settings": {
      "tier": "MACHINE_TYPE",
      "edition": "ENTERPRISE"
  }
}

To send your request, expand one of these options:

You should receive a JSON response similar to the following:

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-16T02:32:12.281Z",
  "operationType": "UPDATE",
  "name": "OPERATION_ID",
  "targetId": "INSTANCE_ID",
  "selfLink": "https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

Cloud SQL Enterprise edition backup and log storage defaults

Changing to Cloud SQL Enterprise edition doesn't switch the storage location of the transaction logs used for PITR. If your Cloud SQL Enterprise Plus edition instance stores its transaction logs for PITR in Cloud Storage, then the logs remain in Cloud Storage. However, instead of storing 14 days of transaction logs for PITR by default, the default is changed to 7 days. Backup configuration is not changed.

What's next