Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://cloud.google.com/sql/docs/mysql/flags below:

Configure database flags | Cloud SQL for MySQL

Stay organized with collections Save and categorize content based on your preferences.

This page describes how to configure database flags for Cloud SQL, and lists the flags that you can set for your instance. You use database flags for many operations, including adjusting MySQL parameters, adjusting options, and configuring and tuning an instance.

In some cases, setting one flag may require that you set another flag to fully enable the functionality you want to use. For example, to enable slow query logging, you must set both the slow_query_log flag to on and the log_output flag to FILE to make your logs available using the Google Cloud console Logs Explorer.

When you set, remove, or modify a flag for a database instance, the database might be restarted. The flag value is then persisted for the instance until you remove it. If the instance is the source of a replica, and the instance is restarted, the replica is also restarted to align with the current configuration of the instance.

The following sections cover common flag management tasks.

1. In the Google Cloud console, select the project that contains the Cloud SQL instance for which you want to set a database flag.
2. Open the instance and click Edit.
3. Go to the Flags section.
4. To set a flag that has not been set on the instance before, click Add item, choose the flag from the drop-down menu, and set its value.
5. Click Save to save your changes.
6. Confirm your changes under Flags on the Overview page.

Edit the instance:

gcloud sql instances patch INSTANCE_NAME --database-flags=FLAG1=VALUE1,FLAG2=VALUE2

This command will overwrite all database flags previously set. To keep those and add new ones, include the values for all flags you want set on the instance; any flag not specifically included is set to its default value. For flags that don't take a value, specify the flag name followed by an equals sign ("=").

For example, to set the general_log, skip_show_database, and wait_timeout flags, you can use the following command:

gcloud sql instances patch INSTANCE_NAME \
  --database-flags=general_log=on,skip_show_database=on,wait_timeout=200000

To add database flags, use a Terraform resource.

To apply your Terraform configuration in a Google Cloud project, complete the steps in the following sections.

1. Launch Cloud Shell.

2. 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.

Each Terraform configuration file must have its own directory (also called a root module).

1. In Cloud Shell, create a directory and a new file within that directory. The filename must have the .tf extension—for example main.tf. In this tutorial, the file is referred to as main.tf.

   mkdir DIRECTORY && cd DIRECTORY && touch main.tf

2. 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.

3. Review and modify the sample parameters to apply to your environment.
4. Save your changes.
5. 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

1. 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.

2. 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.

3. 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.

To delete your changes, do the following:

1. To disable deletion protection, in your Terraform configuration file set the deletion_protection argument to false.

   deletion_protection =  "false"

2. Apply the updated Terraform configuration by running the following command and entering yes at the prompt:

   terraform apply

1. Remove resources previously applied with your Terraform configuration by running the following command and entering yes at the prompt:

   terraform destroy

To set a flag for an existing database:

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":
  {
    "databaseFlags":
    [
      {
        "name": "flag_name",
        "value": "flag_value"
      }
    ]
  }
}

To send your request, expand one of these options:

Save the request body in a file named request.json, and execute the following command:

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/v1/projects/project-id/instances/instance-id"

Save the request body in a file named request.json, and execute the following command:

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }
Invoke-WebRequest `

    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/v1/projects/project-id/instances/instance-id" | Select-Object -Expand Content

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-21T22:43:37.981Z",
  "operationType": "UPDATE",
  "name": "operation-id",
  "targetId": "instance-id",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/project-id/operations/operation-id",
  "targetProject": "project-id"
}

For example, to set the general_log flag for an existing database use:

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":
  {
    "databaseFlags":
    [
      {
        "name": "general_log",
        "value": "on"
      }
    ]
  }
}

To send your request, expand one of these options:

Save the request body in a file named request.json, and execute the following command:

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/v1/projects/project-id/instances/instance-id"

Save the request body in a file named request.json, and execute the following command:

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }
Invoke-WebRequest `

    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/v1/projects/project-id/instances/instance-id" | Select-Object -Expand Content

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-21T22:43:37.981Z",
  "operationType": "UPDATE",
  "name": "operation-id",
  "targetId": "instance-id",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/project-id/operations/operation-id",
  "targetProject": "project-id"
}

If there are existing flags configured for the database, modify the previous command to include them. The PATCH command overwrites the existing flags with the ones specified in the request.

To set a flag for an existing database:

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":
  {
    "databaseFlags":
    [
      {
        "name": "flag_name",
        "value": "flag_value"
      }
    ]
  }
}

To send your request, expand one of these options:

Save the request body in a file named request.json, and execute the following command:

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id"

Save the request body in a file named request.json, and execute the following command:

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }
Invoke-WebRequest `

    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id" | Select-Object -Expand Content

You should receive a JSON response similar to the following:

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "UPDATE",
  "name": "operation-id",
  "targetId": "instance-id",
  "selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/operations/operation-id",
  "targetProject": "project-id"
}

For example, to set the general_log flag for an existing database use:

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":
  {
    "databaseFlags":
    [
      {
        "name": "general_log",
        "value": "on"
      }
    ]
  }
}

To send your request, expand one of these options:

Save the request body in a file named request.json, and execute the following command:

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id"

Save the request body in a file named request.json, and execute the following command:

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }
Invoke-WebRequest `

    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id" | Select-Object -Expand Content

You should receive a JSON response similar to the following:

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "UPDATE",
  "name": "operation-id",
  "targetId": "instance-id",
  "selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/operations/operation-id",
  "targetProject": "project-id"
}

If there are existing flags configured for the database, modify the previous command to include them. The PATCH command overwrites the existing flags with the ones specified in the request.

1. In the Google Cloud console, select the project that contains the Cloud SQL instance for which you want to clear all flags.
2. Open the instance and click Edit.
3. Open the Database flags section.
4. Click the X next to all of the flags shown.
5. Click Save to save your changes.

Clear all flags to their default values on an instance:

gcloud sql instances patch INSTANCE_NAME \
--clear-database-flags

You are prompted to confirm that the instance will be restarted.

To clear all flags for an existing instance:

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":
  {
    "databaseFlags": []
  }
}

To send your request, expand one of these options:

Save the request body in a file named request.json, and execute the following command:

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/v1/projects/project-id/instances/instance-id"

Save the request body in a file named request.json, and execute the following command:

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }
Invoke-WebRequest `

    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/v1/projects/project-id/instances/instance-id" | Select-Object -Expand Content

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-21T22:43:37.981Z",
  "operationType": "UPDATE",
  "name": "operation-id",
  "targetId": "instance-id",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/project-id/operations/operation-id",
  "targetProject": "project-id"
}

To clear all flags for an existing instance:

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":
  {
    "databaseFlags": []
  }
}

To send your request, expand one of these options:

Save the request body in a file named request.json, and execute the following command:

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id"

Save the request body in a file named request.json, and execute the following command:

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }
Invoke-WebRequest `

    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id" | Select-Object -Expand Content

You should receive a JSON response similar to the following:

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "UPDATE",
  "name": "operation-id",
  "targetId": "instance-id",
  "selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/operations/operation-id",
  "targetProject": "project-id"
}

To view all current values of the MySQL system variables, log into your instance with the

client and enter the following statement:

 SHOW VARIABLES;

Note that you can change the value only for supported flags (as listed below).

To see which flags have been set for a Cloud SQL instance:

1. In the Google Cloud console, select the project that contains the Cloud SQL instance for which you want to see the database flags that have been set.
2. Select the instance to open its Instance Overview page.

   The database flags that have been set are listed under the Database flags section.

Get the instance state:

gcloud sql instances describe INSTANCE_NAME

In the output, database flags are listed under the settings as the collection databaseFlags. For more information about the representation of the flags in the output, see Instances Resource Representation.

To list flags configured for an instance:

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:

GET https://sqladmin.googleapis.com/v1/projects/project-id/instances/instance-id

To send your request, expand one of these options:

Execute the following command:

curl -X GET \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     "https://sqladmin.googleapis.com/v1/projects/project-id/instances/instance-id"

Execute the following command:

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }
Invoke-WebRequest `

    -Method GET `
    -Headers $headers `
    -Uri "https://sqladmin.googleapis.com/v1/projects/project-id/instances/instance-id" | Select-Object -Expand Content

You should receive a JSON response similar to the following:

{
  "settings":
  {
    "authorizedGaeApplications": [],
    "tier": "machine-type",
    "kind": "sql#settings",
    "availabilityType": "REGIONAL",
    "pricingPlan": "PER_USE",
    "replicationType": "SYNCHRONOUS",
    "activationPolicy": "ALWAYS",
    "ipConfiguration":
    {
      "privateNetwork": "projects/project-id/global/networks/default",
      "authorizedNetworks": [],
      "ipv4Enabled": false
    },
    "locationPreference":
    {
      "zone": "zone",
      "kind": "sql#locationPreference"
    },
    "databaseFlags": [
      {
        "name": "general_log",
        "value": "on"
      }
    ],
    "dataDiskType": "PD_SSD",
    "maintenanceWindow":
    {
      "kind": "sql#maintenanceWindow",
      "hour": 0,
      "day": 0
    },
    "backupConfiguration":
    {
      "startTime": "03:00",
      "kind": "sql#backupConfiguration",
      "enabled": true,
      "binaryLogEnabled": true
    },
    "settingsVersion": "54",
    "storageAutoResizeLimit": "0",
    "storageAutoResize": true,
    "dataDiskSizeGb": "10"
  }
}

In the output, look for the databaseFlags field.

To list flags configured for an instance:

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:

GET https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id

To send your request, expand one of these options:

Execute the following command:

curl -X GET \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id"

Execute the following command:

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }
Invoke-WebRequest `

    -Method GET `
    -Headers $headers `
    -Uri "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id" | Select-Object -Expand Content

You should receive a JSON response similar to the following:

{
  "settings":
  {
    "authorizedGaeApplications": [],
    "tier": "machine-type",
    "kind": "sql#settings",
    "availabilityType": "REGIONAL",
    "pricingPlan": "PER_USE",
    "replicationType": "SYNCHRONOUS",
    "activationPolicy": "ALWAYS",
    "ipConfiguration":
    {
      "privateNetwork": "projects/project-id/global/networks/default",
      "authorizedNetworks": [],
      "ipv4Enabled": false
    },
    "locationPreference":
    {
      "zone": "zone",
      "kind": "sql#locationPreference"
    },
    "databaseFlags": [
      {
        "name": "general_log",
        "value": "on"
      }
    ],
    "dataDiskType": "PD_SSD",
    "maintenanceWindow":
    {
      "kind": "sql#maintenanceWindow",
      "hour": 0,
      "day": 0
    },
    "backupConfiguration":
    {
      "startTime": "03:00",
      "kind": "sql#backupConfiguration",
      "enabled": true,
      "binaryLogEnabled": true
    },
    "settingsVersion": "54",
    "storageAutoResizeLimit": "0",
    "storageAutoResize": true,
    "dataDiskSizeGb": "10"
  }
}

In the output, look for the databaseFlags field.

Cloud SQL adjusts certain system flags depending on the instance machine type.

innodb_buffer_pool_instances

• 1 for db-f1-micro and db-g1-small.
• 1 if RAM < 7.5 GB.
• 2 if 7.5 GB <= RAM < 13 GB.
• 4 if 13 GB <= RAM < 26 GB.
• 8 if RAM >= 26 GB.

The flags supported in Cloud SQL are the most commonly requested flags for MySQL. Flags not mentioned below are not supported.

For a given flag, Cloud SQL might support a different value or range from the corresponding MySQL parameter or option.

The flags apply to all versions of MySQL supported by Cloud SQL except where noted.

A | B | C | D | E | F | G | H | I | L | M | N | O | P | Q | R | S | T | U | W

For more information about this flag, see the Tips section.

See the Tips section for more information about this flag.

Supported in MySQL 5.7 and later

Default is 0.

Supported in MySQL 5.7 and later

Default is 0.

See the Tips section for more information about this flag.

For information about how to use this flag and its acceptable values, see Configuring parallel replication.

For information about how to use this flag and its acceptable values, see Configuring parallel replication. This flag is not supported in MySQL 8.4.

Note: This flag takes a value in aes-keylen-mode format, where keylen is the key length (in bits) and mode is the encryption mode. The value isn't case-sensitive.

Allowed keylen values are 128, 192, and 256.

Allowed mode values are ECB, CBC, CFB1, CFB8, CFB128, and OFB.

See the Tips section for more information about this flag.

default:

See the Tips section for more information about this flag.

See the Tips section for more information about this flag.

See the Tips section for more information about this flag.

default: create_user, alter_user, grant, and update

You use values to specify timezone offsets, from -12:59 to +13:00. Leading zeros are required.

When using timezone names, automatic adjustment to daylight saving time is supported. When using timezone offsets, it isn't supported. See a list of timezone names that Cloud SQL for MySQL supports. You must update this flag manually, on the primary instance and on all read replicas, to account for it.

To set the timezone without causing a restart of the Cloud SQL instance, use the set time_zone=timezone_offset or timezone_name command with the init_connect flag.

If you are using the Event Scheduler, configure your instance with an activation policy of ALWAYS to ensure that scheduled events run.

See the Tips section for more information about this flag.

Note: This flag is not supported in MySQL 8.4. Use binlog_expire_logs_seconds instead. See the Tips section for more information about this flag.

See the Tips section for more information about this flag.

See the Tips section for more information about general logs.

This flag value is dependent on innodb_buffer_pool_size and innodb_buffer_pool_instances. MySQL can auto-tune the value of innodb_buffer_pool_chunk_size based on these two flags.

See the Tips section for more information about this flag.

See the Tips section for more information about this flag.

See the Tips section for more information about this flag.

Setting this flag for MySQL 5.6 requires a restart. See the Tips section for more information about this flag.

Options: none, inserts, deletes, changes, purges, all.

Options: crc32, strict_crc32, innodb, strict_innod, none, strict_none.

This flag is available only for instances with Cloud SQL Enterprise Plus edition. For more information about this flag, see the Tips section.

Supported in MySQL 5.7 and later.

Default: on

See the Tips section for more information about this flag.

Supported in MySQL 5.7 and later.

See the Tips section for more information about this flag.

If you promote a replica with this flag enabled, the flag is automatically removed causing the promoted replica to have full durability by default. To use this flag with a promoted replica, you can update the flag to the replica after promotion.

See the Tips section for more information about this flag.

See the Tips section for more information about this flag.

To learn more about configuring the disk performance, see the E2 VMs table in Configure disks to meet performance requirements.

To learn more about configuring the disk performance, see the E2 VMs table in Configure disks to meet performance requirements.

Supported only in MySQL 5.6.

For more information about this flag, see the Tips section.

Default is 1.

Cloud SQL provides the ability to set this flag to less than 1 if needed.

If the log_queries_not_using_indexes flag is also enabled, you may see queries with less than the time specified here.

If you use the default value of 0 for this flag, table and database names are case sensitive. When set to 1, table and database names are case insensitive.

For MySQL 5.7 instances, you can change the value of this flag at any time. If you do, then make sure that you understand how the change affects your existing tables and databases.

For MySQL 8.0 and later instances, you can set the value of this flag to a desired value only while an instance is being created. After you set this value, you can't change it. Also, for an existing instance, you can't change the value of this flag.

When creating read replicas for MySQL 5.7, MySQL 8.0, or MySQL 8.4 instances, the replica inherits this flag value from the primary.

This value must be a multiple of 1024, if sql_mode=TRADITIONAL or sql_mode=STRICT_ALL_TABLES.

See the Tips section for more information about this flag.

See the Tips section for more information about multi-value flags.

See the Tips section for more information about multi-value flags.

See the Tips section for more information about multi-value flags.

default: off, for MySQL 5.6, 5.7, 8.0, and 8.4 if instance RAM is less than 15 GB.

default: on, for MySQL 8.0 and later if instance RAM is greater than 15 GB

See Tips section for more information about performance_schema flags.

See Tips section for more information about performance_schema flags.

See Tips section for more information about performance_schema flags.

See Tips section for more information about performance_schema flags.

See Tips section for more information about performance_schema flags.

See Tips section for more information about performance_schema flags.

See Tips section for more information about performance_schema flags.

See Tips section for more information about performance_schema flags.

See Tips section for more information about performance_schema flags.

See Tips section for more information about performance_schema flags.

See Tips section for more information about performance_schema flags.

See Tips section for more information about performance_schema flags.

See Tips section for more information about performance_schema flags.

See Tips section for more information about performance_schema flags.

See Tips section for more information about performance_schema flags.

See Tips section for more information about performance_schema flags.

See Tips section for more information about performance_schema flags.

See Tips section for more information about performance_schema flags.

See Tips section for more information about performance_schema flags.

See Tips section for more information about performance_schema flags.

See Tips section for more information about performance_schema flags.

See Tips section for more information about performance_schema flags.

See Tips section for more information about performance_schema flags.

See Tips section for more information about performance_schema flags.

See Tips section for more information about performance_schema flags.

See Tips section for more information about performance_schema flags.

See Tips section for more information about performance_schema flags.

See Tips section for more information about performance_schema flags.

See Tips section for more information about performance_schema flags.

See Tips section for more information about performance_schema flags.

See Tips section for more information about performance_schema flags.

See Tips section for more information about performance_schema flags.

See Tips section for more information about performance_schema flags.

See Tips section for more information about performance_schema flags.

See Tips section for more information about performance_schema flags.

See Tips section for more information about performance_schema flags.

See Tips section for more information about performance_schema flags.

See Tips section for more information about performance_schema flags.

See Tips section for more information about performance_schema flags.

See Tips section for more information about performance_schema flags.

See Tips section for more information about performance_schema flags.

This flag is not available for MySQL 8.0 and later as the query cache is deprecated as of MySQL 5.7.20, and is removed in MySQL 8.0.

This flag is not available for MySQL 8.0 and later as the query cache is deprecated as of MySQL 5.7.20, and is removed in MySQL 8.0.

This flag is not available for MySQL 8.0 and later as the query cache is deprecated as of MySQL 5.7.20, and is removed in MySQL 8.0.

This flag is not available for MySQL 8.0 and later as the query cache is deprecated as of MySQL 5.7.20, and is removed in MySQL 8.0.

This flag is not available for MySQL 8.0 and later as the query cache is deprecated as of MySQL 5.7.20, and is removed in MySQL 8.0.

Has no effect for replicas.

This flag doesn't affect replicas that don't have multithreading enabled.

The unit is milliseconds.

The unit is seconds.

For information about how to use this flag and its acceptable values, see Configuring parallel replication.

For information about how to use this flag and its acceptable values, see Configuring parallel replication.

For information about how to use this flag and its acceptable values, see Configuring parallel replication.

For information about how to use this flag and its acceptable values, see Configuring parallel replication.

For more information about this flag, see the Tips section.

For more information about how to use this flag, see the Replication filters section.

For more information about how to use this flag, see the Replication filters section.

For more information about how to use this flag, see the Replication filters section.

For more information about how to use this flag, see the Replication filters section.

For more information about how to use this flag, see the Replication filters section.

For more information about how to use this flag, see the Replication filters section.

Supported in MySQL 5.7 only.

This flag doesn't affect replicas that don't have multithreading enabled.

The unit is milliseconds.

The unit is seconds.

For information about how to use this flag and its acceptable values, see Configuring parallel replication.

For information about how to use this flag and its acceptable values, see Configuring parallel replication.

For information about how to use this flag and its acceptable values, see Configuring parallel replication.

For information about how to use this flag and its acceptable values, see Configuring parallel replication.

For more information about this flag, see the Tips section.

See the Tips section for more information on slow query logs.

See the Server SQL Modes in the MySQL documentation for allowed values, including combined modes, such as ANSI. NO_DIR_IN_CREATE is not supported.

Cloud SQL for MySQL doesn't support empty values for the sql_mode flag. Instead of using an empty value, set this flag to the NO_ENGINE_SUBSTITUTION mode.

See the Tips section for more information about this flag.

The default setting of 1 enables the synchronization of the binary log to disk before transactions are committed.

If you promote a replica with this flag enabled, the flag is automatically removed causing the promoted replica to have full durability by default. To use this flag with a promoted replica, you can update the flag to the replica after promotion.

See the Tips section for more information about this flag.

Version 5.7 to Version 8.0.27: TLSv1, TLSv1.1

Version 8.0 or later: No

See the Tips section for more information about this flag.

For information about how to use this flag and its acceptable values, see Configuring parallel replication. This flag is not supported in MySQL 8.4.

See the Tips section for more information about this flag.

In this section, you'll learn about the time-zone names that Cloud SQL for MySQL supports.

The table in this section displays the following:

• Timezone name: The name that Cloud SQL for MySQL supports.
• STD: The time-zone offset in standard time (STD).
• DST: The time-zone offset in daylight savings time (DST).
• Synonym names: The names for time zones that you may want to use, but they aren't supported by Cloud SQL for MySQL. If this situation occurs, then use the corresponding time-zone name.

Time-zone names are case insensitive. You can supply the time-zone name in any case. The format for the STD and DST time-zone offsets is +/-hh:mm, and the offsets are in UTC. Not all time-zone names have corresponding synonym names. If this occurs, then use the time-zone name.

Timezone tables in Cloud SQL might need refreshing with the latest data. For example, a country might shift from a DST timezone offset to an STD offset or a country might introduce a new timezone.

For every critical service agent (CSA) release for Cloud SQL, timezone tables are refreshed with the latest data. When this happens, during the non-maintenance window, the replica instances are refreshed. Primary instances are then refreshed during the maintenance window.

You can either wait until the regular maintenance window for the CSA release or you can perform self service maintenance to refresh the timezone tables with the latest data. For more information about viewing the available maintenance versions, see Determine the target maintenance version.

general_log, slow_query_log

To make your general or slow query logs available, enable the corresponding flag and set the log_output flag to FILE. This makes the log output available using the Logs Viewer in the Google Cloud console. Note that Google Cloud Observability logging charges apply. To minimize instance storage cost, general and slow query logs on the instance disk are rotated when the log file is older than 24 hours (and no changes have been made within that duration) or greater than 100MB in size. Old log files are automatically deleted after the rotation.

If the log_output is set to NONE, you can't access the logs. If you set log_output to TABLE, the log output is placed in a table in the mysql system database. It might consume a considerable amount of disk space. If this table becomes large, it can affect instance restart time or cause the instance to lose its SLA coverage. For this reason, the TABLE option is not recommended. In addition, the log content isn't available in Logs Explorer and it isn't rotated. If needed, you can truncate your log tables by using the API. For more information, see the instances.truncateLog reference page.

MySQL provides a more sophisticated utility for examining and processing binary log files called mysqlbinlog. This utility is available with the MySQL Server software. If you have a MySQL instance, then you can use mysqlbinlog to determine your desired recovery position.

expire_logs_days, binlog_expire_logs_seconds

If you enable point-in-time recovery, the expiration period of your binary logs is determined by the lesser of your transaction log retention period and the values of these flags. You can use these flags to manage how long binary logs are stored on your replicas. The expire_logs_days flag is removed from MySQL 8.4 and later. For more information, see the transaction log retention page.

innodb_buffer_pool_size

The value of this flag is the size in bytes of the buffer pool. The buffer pool size must always be equal to or a multiple of the value that you get when you multiply innodb_buffer_pool_chunk_size by innodb_buffer_pool_instances. If you alter the buffer pool size to a value that's not equal to or a multiple of innodb_buffer_pool_chunk_size multiplied by innodb_buffer_pool_instances, then Cloud SQL adjusts the buffer pool size automatically. You can't enable this flag on instances that have fewer than 3,840 MiB of RAM.

You can't configure this flag for shared-core machine types (f1_micro and g1_small). Changing this flag on MySQL 5.6 requires a restart.

In Cloud SQL, the default, minimum allowable, and maximum allowable values of the innodb_buffer_pool_size flag depend on the instance's memory. These values can be roughly calculated as a percentage of the instance's RAM. By default, the value of this flag is typically set close to the maximum allowable value. The maximum allowable allocation percentage increases with instance size. The minimum allowable value is usually about 20% of the instance's RAM.

Approximate values for this flag:

Instance RAM Range Min % Default % Max % 0 - 4.0GB of RAM ~34% 4.0GB - 7.5GB ~20% ~34% ~34% 7.5GB - 12GB ~20% ~52% ~52% 12GB - 24GB ~20% ~67% ~67% 24GB and above ~20% ~72% ~72%

Your exact values may vary. To calculate the current value for your instance, you can run the query:

  show global variables like 'innodb_buffer_pool_size';
  

For reference, the minimum allowable, default, and maximum allowable values are provided for the machine types below.

Machine type Instance RAM (GB) Min (GB)
(% of total) Default (GB)
(% of total) Max (GB)
(% of total) db-f1-micro 0.6 - 0.053 - db-g1-small 1.7 - 0.625 - db-custom-1-3840 3.75 0.875
(23%) 1.375
(37%) 1.375
(37%) db-custom-2-7680 7.5 1.5
(20%) 4
(53%) 4
(53%) db-custom-4-15360 15 3
(20%) 10.5
(70%) 10.5
(70%) db-custom-8-30720 30 6
(20%) 22
(73%) 22
(73%) db-custom-16-61440 60 12
(20%) 44
(73%) 44
(73%) db-custom-32-122880 120 24
(20%) 87
(73%) 87
(73%) db-custom-64-245760 240 48
(20%) 173
(72%) 173
(72%) db-custom-96-368640 360 72
(20%) 260
(72%) 260
(72%) db-custom-2-13312 13 3
(23%) 9
(69%) 9
(69%) db-custom-4-26624 26 6
(23%) 19
(73%) 19
(73%) db-custom-8-53248 52 11
(21%) 38
(73%) 38
(73%) db-custom-16-106496 104 21
(20%) 75
(72%) 75
(72%) db-custom-32-212992 208 42
(20%) 150
(72%) 150
(72%) db-custom-64-425984 416 84
(20%) 300
(72%) 300
(72%) db-custom-96-638976 624 125
(20%) 450
(72%) 450
(72%)

gcloud sql instances patch INSTANCE_NAME \
 --database-flags="innodb_cloudsql_optimized_write=OFF"

SET GLOBAL FLAG_NAME=FLAG_VALUE

binlog_order_commits

The default value for the binlog_order_commits flag is ON. Cloud SQL recommends to not change the default value of this flag. If the default value is changed to OFF, transactions in the same binary log group will commit in a different order than when they were written in the binary log. This impacts the following operations that execute transactions in the binary log order:

• Replication: may lead to data inconsistency between the source and replicas
• Point-in-time-recovery: may lead to data inconsistency between the PITR restored state and historical state

optimizer_switch,optimizer_trace,optimizer_trace_features

Optimizer flags have comma-separated values. You can set these flags using the Console or gcloud. For more information on how to set this flag using the console, see Configure database flags. If using gcloud, you can specify the value for these flags using two different ways:

• gcloud topic flags-file
• gcloud topic escaping-file

To set multiple optimizer sub-flags in one command, use the comma delimiter to separate each flag name. If you set a single sub-flag value using the gcloud command, it overwrites all previously set sub-flags. For example, if you run the following command, the expected value for the batched_key_access sub-flag is set to on and all other sub-flags for optimizer_flags are set to their default values.

gcloud sql instances patch my-instance --database-flags=^~^optimizer_switch=batched_key_access=on

If you run the following command, the value of the block_nested_loop sub-flag is set to on and all other sub-flags for optimizer_switch are overwritten and set to their default values.

gcloud sql instances patch my-instance --database-flags=^~^optimizer_switch=block_nested_loop=on

This includes batched_key_access, which was set to on by the previous command. To keep all previously set sub-flags and add new ones, you must add the values of all sub-flags you want to set when adding a new sub-flag.

All other database system flags that are not listed in the supported flags section are called managed flags. For certain managed flags, Cloud SQL sets the flag to a value other than the default setting to ensure Cloud SQL instances run reliably. You can't change the values on these system flags.

Managed flags with a non-default setting are listed below.

The partial_revokes flag allows you to limit user access on a databases schema. In Cloud SQL for MySQL version 8.0 and later, the partial_revokes flag is set to ON. This limits the use of wildcard characters when granting or revoking user privileges to database schemas in MySQL 8.0. Update your GRANT statement to use the full name of the database schema instead of using wildcard characters.

For example, if you use the following command with the %\ wildcard character to grant privileges to a user in MySQL 5.7, then the user will be granted privileges to all databases ending with _foobar.

GRANT ALL PRIVILEGES ON `%\_foobar`.*  TO  'testuser'@'%';

However, in MySQL 8.0, users will only be granted access to the database that is an exact match to %\_foobar.

There are two different ways to grant access to multiple databases in MySQL 8.0 and later.

1. You can grant permissions to specific databases using the full database names as shown in the command below:

     grant select on test1_foobar.* to 'testuser'@'%';
     grant select on test2_foobar.* to 'testuser'@'%';
     grant select on test3_foobar.* to 'testuser'@'%';
   

2. With partial_revokes, you can use the grant and revoke command to grant user privileges on all database schemas while restricting access to a few database schemas.

     grant select on *.* to 'testuser'@'%';
     revoke select on test3_foobar.* from 'testuser'@'%';
   

   This grants access to all database schemas while restricting access to test3_foobar.*.

Replication filters can be set only on Cloud SQL replicas. Each replication filter is set as a single flag for multiple databases where each database name is separate by a comma. You can set up a replication filter on a Cloud SQL replica using console or the following command:

gcloud sql instances patch REPLICA_NAME --database-flags=^~^REPLICATION_FILTER_NAME=DATABASE_NAME1,DATABASE_NAME, etc

Replication filters don't support database names that contain comma values. The ^~^ value in the preceding command is necessary for database flags that are comma-separated values.

When you set a replication filter flag, keep the following in mind:

• If the replica becomes unhealthy, then data filtered by replication filters can appear on the replica as Cloud SQL uses source data from the primary to rebuild the instance replica.
• You can't set replication filters on the mysql schema.
• Replication filter rules don't apply to serverless exports.

The following is a list of database flags that Cloud SQL for MySQL uses to enable and manage features specific to the index advisor.

The following list below contains the flag names that have been changed by Cloud SQL for MySQL versions 8.0.26 and above.

If your Cloud SQL instance is using a deprecated flag name, then edit your Cloud SQL instance, delete the deprecated flag name, and add the new flag to your instance. For more information, see Setup a database flag.

• Learn more about MySQL system variables.
• Learn more about Operational Guidelines.

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

Last updated 2025-08-14 UTC.

[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-14 UTC."],[],[]]

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4