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.
Configure database flags
The following sections cover common flag management tasks.
Set a database flag
Console
- In the Google Cloud console , select the project that contains the Cloud SQL instance for which you want to set a database flag.
- Open the instance and click Edit .
- Go to the Flags section.
- 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.
- Click Save to save your changes.
- Confirm your changes under Flags on the Overview page.
gcloud
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
Terraform
To add database flags, 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
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:
You should receive a JSON response similar to the following:
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:
You should receive a JSON response similar to the following:
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.
REST v1beta4
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:
You should receive a JSON response similar to the following:
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:
You should receive a JSON response similar to the following:
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.
Clear all flags to their default values
Console
- In the Google Cloud console , select the project that contains the Cloud SQL instance for which you want to clear all flags.
- Open the instance and click Edit .
- Open the Database flags section.
- Click the X next to all of the flags shown.
- Click Save to save your changes.
gcloud
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.
REST v1
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:
You should receive a JSON response similar to the following:
REST v1beta4
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:
You should receive a JSON response similar to the following:
View current values of database flags
To view all current values of the MySQL system variables, log into your instance with themysql
client and enter the following statement:
SHOW
VARIABLES
;
Note that you can change the value only for supported flags (as listed below).
Determine which database flags have been set for an instance
To see which flags have been set for a Cloud SQL instance:
Console
- 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.
- Select the instance to open its Instance Overview
page.
The database flags that have been set are listed under the Database flags section.
gcloud
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
.
REST v1
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:
You should receive a JSON response similar to the following:
In the output, look for the databaseFlags
field.
REST v1beta4
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:
You should receive a JSON response similar to the following:
In the output, look for the databaseFlags
field.
Flags managed by Cloud SQL
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.
Supported flags
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
Acceptable Values and Notes
Required?
integer
0
or 86400 (1 day)
... 4294967295 (max value)
Default is 2592000, which equals 30 days.
See the Tips section for more information about this flag.
0 ... 1000000
Supported in MySQL 5.7 and later
Default is 0 .
integer
For information about how to use this flag and its acceptable values, see Configuring parallel replication .
enumeration
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.
string
default:
MySQL 8.0 and later - utf8mb4_0900_ai_ci
See the Tips section for more information about this flag.
string
default:
MySQL 5.7:
utf8
MySQL 8.0 and later:
utf8mb4
See the Tips section for more information about this flag.
string
default:
MySQL 5.7:
utf8
MySQL 8.0 and later:
utf8mb4
See the Tips section for more information about this flag.
string
utf8 or utf8mb4
default:
MySQL 5.7:
utf8
MySQL 8.0 and later:
utf8mb4
See the Tips section for more information about this flag.
boolean
on
| off
default:
off
Supported in MySQL 5.7 and later for Cloud SQL.
string
""
, dql
, dml
, ddl
, dcl
, show
, call
, create_udf
, drop_function
, create_procedure
, create_function
, drop_procedure
, alter_procedure
, alter_function
, create_trigger
, drop_trigger
, create_event
, alter_event
, drop_event
, create_db
, drop_db
, alter_db
, create_user
, drop_user
, rename_user
, alter_user
, create_table
, create_index
, alter_table
, drop_table
, drop_index
, create_view
, drop_view
, rename_table
, update
, insert
, insert_select
, delete
, truncate
, replace
, replace_select
, delete_multi
, update_multi
, load
, select
, call_procedure
, connect
, disconnect
, grant
, revoke
, revoke_all
, show_triggers
, show_create_proc
, show_create_func
, show_procedure_code
, show_function_code
, show_create_event
, show_events
, show_create_trigger
, show_grants
, show_binlog_events
, show_relaylog_events
default:
create_user
, alter_user
, grant
, and update
integer
1073741824...innodb_buffer_pool_size/2
default:
1073741824
in bytesstring
There are two ways to specify timezones: as timezone offsets and timezone names. For example,
+00:00
is the
timezone offset for London (which is in the UTC timezone), and Europe/London
is its timezone name. 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.
boolean
on
| off
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.
integer
0
... 99
Default is 0, which means no automatic removal.
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.
integer
0
... 4294967295
default (up to version 8.0.22):
1000
default (version 8.0.23+):
0
integer
1048576
... (innodb_buffer_pool_size/innodb_buffer_pool_instances)
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.
integer
Setting this flag for MySQL 5.6 requires a restart. See the Tips section for more information about this flag.
string
Options: crc32
, strict_crc32
, innodb
, strict_innod
, none
, strict_none
.
boolean
This flag is available only for instances with Cloud SQL Enterprise Plus edition. For more information about this flag, see the Tips section.
double
0.0001
... 2700
Default:
1
Supported in MySQL 5.7 and later.
See the Tips section for more information about this flag.
integer
1, 2
Default:
1
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.
integer
100
... 100000
Default:
5000
To learn more about configuring the disk performance, see the E2 VMstable in Configure disks to meet performance requirements.
integer
100
... 100000
Default:
10000
To learn more about configuring the disk performance, see the E2 VMstable in Configure disks to meet performance requirements.
integer
MySQL 5.6:
1048576
... 274877906944
MySQL 5.7 and later:
4194304
... 274877906944
For more information about this flag, see the Tips section.
integer
100
... 2147483647
default:
MySQL 5.7:
2000
MySQL 8.0 and later:
4000
8.0.28
: No≤
8.0.27
: Yesinteger
1
... 64
Supported in MySQL 5.7 and later. For MySQL 5.7 and 8.0, the default is
4
.
For MySQL 8.4, the default is equal to the value
of configured for the innodb_buffer_pool_instances
flag.integer
MySQL 8.0.33 and earlier:
8388608
(8 MB) ... 137438953472
(128 GB)
MySQL 8.0.34 and later: 8388608
(8 MB) ... 549755813888
(512 GB) For more information about this flag, see the Tips section.
string
en_US
| cs_CZ
| da_DK
| nl_NL
| et_EE
| fr_FR
| de_DE
| el_GR
| hu_HU
| it_IT
| ja_JP
| ko_KR
| no_NO
| nb_NO
| pl_PL
| pt_PT
| ro_RO
| ru_RU
| sr_RS
| sk_SK
| es_ES
| sv_SE
| uk_UA
default:
en_US
float
0
... 30000000
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.
integer
0
or 1
Default:
0
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.
integer
16384
... 1073741824
This value must be a multiple of 1024, if sql_mode=TRADITIONAL or sql_mode=STRICT_ALL_TABLES.
multi-value repeated string
enabled=on
, enabled=off
, one_line=on
, one_line=off
See the Tips section for more information about multi-value flags.
boolean
on
| off
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.
integer
0
... 223338299392
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.
integer
0
... 9223372036854775807
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.
integer
0
... 223338299392
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.
enumeration
0
... 2
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.
boolean
on
| off
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.
integer
32
... 524280
Default is 512.
This flag doesn't affect replicas that don't have multithreading enabled.
enumeration
DATABASE
, LOGICAL_CLOCK
Default:
MySQL 8.0.26 or earlier:
DATABASE
MySQL 8.0.27 or later:
LOGICAL_CLOCK
For information about how to use this flag and its acceptable values, see Configuring parallel replication .
integer
For information about how to use this flag and its acceptable values, see Configuring parallel replication .
integer
For information about how to use this flag and its acceptable values, see Configuring parallel replication .
boolean
For information about how to use this flag and its acceptable values, see Configuring parallel replication .
string
For more information about how to use this flag, see the Replication filters section.
string
For more information about how to use this flag, see the Replication filters section.
string
For more information about how to use this flag, see the Replication filters section.
string
For more information about how to use this flag, see the Replication filters section.
string
For more information about how to use this flag, see the Replication filters section.
string
For more information about how to use this flag, see the Replication filters section.
integer
32
... 524280
Default is 512.
This flag doesn't affect replicas that don't have multithreading enabled.
enumeration
DATABASE
, LOGICAL_CLOCK
Default:
MySQL 8.0.26 or earlier:
DATABASE
MySQL 8.0.27 or later:
LOGICAL_CLOCK
For information about how to use this flag and its acceptable values, see Configuring parallel replication .
integer
For information about how to use this flag and its acceptable values, see Configuring parallel replication .
boolean
For information about how to use this flag and its acceptable values, see Configuring parallel replication .
integer
For information about how to use this flag and its acceptable values, see Configuring parallel replication .
string
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.
integer
0...18446744073709551615
default:
18446744073709551615
See the Tips section for more information about this flag.
integer
0
... 4294967295
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.
String
Version 5.7 to Version 8.0.27:
TLSv1, TLSv1.1
Version 8.0.28 or later:
TLSv1.2
Version 8.0 or later : No
enumeration
READ-UNCOMMITTED
| READ-COMMITTED
| REPEATABLE-READ
| SERIALIZABLE
enumeration
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.
Timezone names
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 name | STD | DST | Synonym names |
---|---|---|---|
Africa/Cairo
|
+02:00 | +02:00 | Egypt |
Africa/Casablanca
|
+01:00 | +00:00 | |
Africa/Harare
|
+02:00 | +02:00 | Africa/Maputo |
Africa/Monrovia
|
+00:00 | +00:00 | |
Africa/Nairobi
|
+03:00 | +03:00 | Africa/Addis_Ababa Africa/Asmera Africa/Dar_es_Salaam Africa/Djibouti Africa/Kampala Africa/Mogadishu Indian/Antananarivo Indian/Comoro Indian/Mayotte |
Africa/Tripoli
|
+02:00 | +02:00 | Libya |
Africa/Windhoek
|
+02:00 | +02:00 | |
America/Araguaina
|
−03:00 | −03:00 | |
America/Asuncion
|
−04:00 | −03:00 | |
America/Bogota
|
−05:00 | −05:00 | |
America/Buenos_Aires
|
−03:00 | −03:00 | America/Argentina/Buenos_Aires |
America/Caracas
|
−04:00 | −04:00 | |
America/Chicago
|
−06:00 | −05:00 | |
America/Chihuahua
|
−07:00 | −06:00 | America/Ojinaga |
America/Cuiaba
|
−04:00 | −04:00 | |
America/Denver
|
−07:00 | −06:00 | America/Shiprock Navajo MST7MDT US/Mountain |
America/Detroit
|
−05:00 | −04:00 | |
America/Fortaleza
|
−03:00 | −03:00 | |
America/Guatemala
|
−06:00 | −06:00 | |
America/Halifax
|
−04:00 | −03:00 | Canada/Atlantic |
America/Los_Angeles
|
−08:00 | −07:00 | |
America/Manaus
|
−04:00 | −04:00 | Brazil/West |
America/Matamoros
|
−06:00 | −05:00 | |
America/Mexico_City
|
−06:00 | −05:00 | |
America/Monterrey
|
−06:00 | −05:00 | |
America/Montevideo
|
−03:00 | −03:00 | |
America/New_York
|
−05:00 | −04:00 | |
America/Phoenix
|
−07:00 | −07:00 | US/Arizona MST America/Creston |
America/Santiago
|
−04:00 | −03:00 | Chile/Continental |
America/Sao_Paolo
|
−03:00 | −03:00 | |
America/Tijuana
|
−08:00 | −07:00 | Mexico/BajaNorte America/Ensenada America/Santa_Isabel |
Asia/Amman
|
+02:00 | +03:00 | |
Asia/Ashgabat
|
+05:00 | +05:00 | Asia/Ashkhabad |
Asia/Baghdad
|
+03:00 | +03:00 | |
Asia/Baku
|
+04:00 | +04:00 | |
Asia/Bangkok
|
+07:00 | +07:00 | Asia/Phnom_Penh Asia/Vientiane |
Asia/Beirut
|
+02:00 | +03:00 | |
Asia/Calcutta
|
+05:30 | +05:30 | Asia/Kolkata |
Asia/Damascus
|
+02:00 | +03:00 | |
Asia/Dhaka
|
+06:00 | +06:00 | Asia/Dacca |
Asia/Irkutsk
|
+08:00 | +08:00 | |
Asia/Jerusalem
|
+02:00 | +03:00 | Asia/Tel_Aviv Israel |
Asia/Kabul
|
+04:30 | +04:30 | |
Asia/Karachi
|
+05:00 | +05:00 | |
Asia/Kathmandu
|
+05:45 | +05:45 | Asia/Katmandu |
Asia/Kolkata
|
+05:30 | +05:30 | |
Asia/Krasnoyarsk
|
+07:00 | +07:00 | |
Asia/Magadan
|
+11:00 | +11:00 | |
Asia/Muscat
|
+04:00 | +04:00 | Asia/Dubai |
Asia/Novosibirsk
|
+07:00 | +07:00 | |
Asia/Riyadh
|
+03:00 | +03:00 | Asia/Kuwait Antarctica/Syowa Asia/Aden |
Asia/Seoul
|
+09:00 | +09:00 | ROK |
Asia/Shanghai
|
+08:00 | +08:00 | Asia/Chongqing Asia/Chungking Asia/Harbin PRC |
Asia/Singapore
|
+08:00 | +08:00 | Singapore |
Asia/Taipei
|
+08:00 | +08:00 | ROC |
Asia/Tehran
|
+03:30 | +04:30 | Iran |
Asia/Tokyo
|
+09:00 | +09:00 | Japan |
Asia/Ulaanbaatar
|
+08:00 | +08:00 | Asia/Ulan_Bator |
Asia/Vladivostok
|
+10:00 | +10:00 | |
Asia/Yakutsk
|
+09:00 | +09:00 | |
Asia/Yerevan
|
+04:00 | +04:00 | |
Atlantic/Azores
|
−01:00 | +00:00 | |
Australia/Adelaide
|
+09:30 | +10:30 | Australia/South |
Australia/Brisbane
|
+10:00 | +10:00 | Australia/Queensland |
Australia/Darwin
|
+09:30 | +09:30 | Australia/North |
Australia/Hobart
|
+10:00 | +11:00 | Australia/Currie Australia/Tasmania |
Australia/Perth
|
+08:00 | +08:00 | Australia/West |
Australia/Sydney
|
+10:00 | +11:00 | Australia/NSW Australia/ACT Australia/Canberra |
Brazil/East
|
−03:00 | −03:00 | America/Sao_Paulo |
Canada/Newfoundland
|
−03:30 | −02:30 | America/St_Johns |
Canada/Saskatchewan
|
−06:00 | −06:00 | America/Regina |
Canada/Yukon
|
−07:00 | −07:00 | America/Whitehorse |
Europe/Amsterdam
|
+01:00 | +02:00 | |
Europe/Athens
|
+02:00 | +03:00 | |
Europe/Dublin
|
+01:00 | +00:00 | Eire |
Europe/Helsinki
|
+02:00 | +03:00 | Europe/Mariehamn |
Europe/Istanbul
|
+03:00 | +03:00 | Turkey Asia/Istanbul |
Europe/Kaliningrad
|
+02:00 | +02:00 | |
Europe/Madrid
|
+01:00 | +02:00 | |
Europe/Moscow
|
+03:00 | +03:00 | W-SU |
Europe/Paris
|
+01:00 | +02:00 | MET CET |
Europe/Prague
|
+01:00 | +02:00 | Europe/Bratislava |
Europe/Sarajevo
|
+01:00 | +02:00 | Europe/Belgrade Europe/Ljubljana Europe/Podgorica Europe/Skopje Europe/Zagreb |
Pacific/Auckland
|
+12:00 | +13:00 | NZ Antarctica/McMurdo Antarctica/South_Pole |
Pacific/Fiji
|
+12:00 | +13:00 | |
Pacific/Guam
|
+10:00 | +10:00 | Pacific/Saipan |
Pacific/Honolulu
|
−10:00 | −10:00 | US/Hawaii Pacific/Johnston HST |
Pacific/Samoa
|
−11:00 | −11:00 | Pacific/Pago_Pago US/Samoa |
US/Alaska
|
−09:00 | −08:00 | America/Anchorage America/Juneau America/Metlakatla America/Nome America/Sitka America/Yakutat |
US/Central
|
−06:00 | −05:00 | America/Chicago |
US/Eastern
|
−05:00 | −04:00 | America/New_York |
US/East-Indiana
|
−05:00 | −04:00 | America/Indiana/Indianapolis America/Indianapolis America/Fort_Wayne |
US/Mountain
|
−07:00 | −06:00 | America/Denver |
US/Pacific
|
−08:00 | −07:00 | America/Los_Angeles |
UTC
|
+00:00 | +00:00 | Etc/UTC Etc/UCT Etc/Universal Etc/Zulu |
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 .
Tips for working with flags
- general_log, slow_query_log
-
To make your
general
orslow query
logs available, enable the corresponding flag and set thelog_output
flag toFILE
. 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
andslow 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 toNONE
, you can't access the logs. If you setlog_output
toTABLE
, 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, theTABLE
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 .
- 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
byinnodb_buffer_pool_instances
. If you alter the buffer pool size to a value that's not equal to or a multiple ofinnodb_buffer_pool_chunk_size
multiplied byinnodb_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-micro0.6 - 0.053 - db-g1-small1.7 - 0.625 - db-custom-1-38403.75 0.875
(23%)1.375
(37%)1.375
(37%)db-custom-2-76807.5 1.5
(20%)4
(53%)4
(53%)db-custom-4-1536015 3
(20%)10.5
(70%)10.5
(70%)db-custom-8-3072030 6
(20%)22
(73%)22
(73%)db-custom-16-6144060 12
(20%)44
(73%)44
(73%)db-custom-32-122880120 24
(20%)87
(73%)87
(73%)db-custom-64-245760240 48
(20%)173
(72%)173
(72%)db-custom-96-368640360 72
(20%)260
(72%)260
(72%)db-custom-2-1331213 3
(23%)9
(69%)9
(69%)db-custom-4-2662426 6
(23%)19
(73%)19
(73%)db-custom-8-5324852 11
(21%)38
(73%)38
(73%)db-custom-16-106496104 21
(20%)75
(72%)75
(72%)db-custom-32-212992208 42
(20%)150
(72%)150
(72%)db-custom-64-425984416 84
(20%)300
(72%)300
(72%)db-custom-96-638976624 125
(20%)450
(72%)450
(72%)
ON
. This flag improves write performance by optimizing the flushing algorithm, controlling flush limits, and adjusting background activity to prioritize your database write operations.
For the majority of use cases, you can experience better performance such as improved throughput and reduced latency with this flag enabled. However, if your database write operations cause extremely heavy load on the server, then the flag can delay some background activities. This delay can cause a small increase in disk usage, which decreases automatically after the load subsides.
By default, the innodb_cloudsql_optimized_write
flag is
enabled for all new and upgraded Cloud SQL Enterprise Plus edition instances. For existing Cloud SQL Enterprise Plus edition instances, this flag is enabled after the related maintenance update is applied.
If you need to disable the flag, then run the following command.
gcloud sql instances patch INSTANCE_NAME \ --database-flags = "innodb_cloudsql_optimized_write=OFF"
Changing the value of the flag requires restarting the instance.
For all MySQL versions 5.6 and higher, the default value is ON
.
innodb_flush_log_at_trx_commit
and the sync_binlog
flags must be set to the default value of 1
. If you change the default value,
then durability might decrease, which might lead to
inconsistency between the primary instance and replicas. Therefore, the instance
loses its SLA coverage. In addition, any of the following might occur: - Data loss in certain situations, such as a VM crash or failover for regional HA instance
- Out-of-sync data in binary log and InnoDB data files
- PITR data loss or failure
- Data inconsistency between a primary instance and its replicas
- A replication break
Setting the value of the innodb_flush_log_at_trx_commit
or sync_binlog
flag to non-default values for primary, standalone, and HA instances causes
reduced durability.
If you need higher performance for read replicas, then we recommend setting the innodb_flush_log_at_trx_commit
value to 2
.
Cloud SQL does not support setting the value for this flag to 0. If you
set the flag value to 2, you must either disable the binary log on the
replica, or set sync_binlog
to a
value other than 1 for higher performance.
Cloud SQL might temporarily change the innodb_flush_log_at_trx_commit
and sync_binlog
flag values to default when taking a backup. This might
cause reduced performance when taking backups. To avoid this from impacting
your instance, you can change
the backup window when instance usage is low. For more information,
see Create and manage on-demand and
automatic backups
.
innodb_flush_log_at_timeout
lets you modify the frequency
of page flushes so you can avoid impacting the performance of binary log group
commit. The default setting is once per second.
Cloud SQL has extended this flag to support specifying a time period in microseconds.
Examples:
-
0.001
to specify 1 ms -
0.0001
to specify 100 us -
12.5
to specify 12.5 seconds -
12.005
to specify 12 seconds and 5 ms -
0.005100
to specify 5 ms and 100 us
For certain workloads, using whole second granularity for flushing pages might be unacceptable in terms of potential transaction loss. Instead, you can flush pages using microsecond granularity to maintain performance without significantly compromising durability.
The microsecond time periods for the innodb_flush_log_at_timeout
flag are only applicable when the innodb_flush_log_at_trx_commit
durability flag is set to 2
.
The flushing of pages might happen more or less frequently than the value
specified for innodb_flush_log_at_timeout
and the value is not the
upper bound.
If you configure a value for the innodb_redo_log_capacity
flag,
then Cloud SQL ignores any value that you define for
the innodb_log_file_size
flag.
If you don't configure any values for
the innodb_redo_log_capacity
or innodb_log_file_size
flags, then Cloud SQL uses
the default value of the innodb_redo_log_capacity
flag, or 104857600
(100 MB).
If you don't configure the innodb_redo_log_capacity
flag, but configure
the innodb_log_file_size
flag,
then the value of your innodb redo log size is calculated by innodb_log_file_size
* innodb_log_file_in_group
. For example, if you configure innodb_log_file_size
to a value of 10 GB and the default value of innodb_log_file_in_group
is 2
, then the effective
value of your innodb redo log size is 20 GB.
Exhausting the available instance memory can occur when you set tmp_table_size
and max_heap_table_size
too high for
the number of concurrent queries the instance processes. Exhausting the memory
results in an instance crash and restart.
For more information about working with these flags, see How MySQL Uses Internal Temporary Tables and The MEMORY Storage Engine .
You can't enable this flag on instances with a shared core (less than 3 GB of RAM). If you enable this flag, then you can't change your machine type to a size that does not support the flag; you must first disable this flag.
OFF
and the default value for MySQL 8.0 is ON
. To
learn more about the event_scheduler
flag, see event_scheduler
.
If the event_scheduler
flag is set to ON
for a read
replica, it can cause errors based on the type of statements defined in the
events: - If your scheduled event is a
write
event on a read replica, it causes an error as read replicas are read only. See Read Replicas for more information. - If your scheduled event contains a stop operation, such as
kill
,event_scheduler
applies it to the replica. This stops the replication and delete the replica.
event_scheduler
flag to OFF
when creating replicas. For more information on how to enable or disable event_scheduler
,
see Configure database flags
.
replica_skip_errors
or the slave_skip_errors
flag can cause replication issues. In general,
if an error occurs while executing a statement, the replication is stopped.
Using this flag will cause the error to be skipped and replication to continue,
leading to inconsistency between the primary instance and replica.
This can also make it harder to troubleshoot replication issues. Cloud SQL recommends only using this flag if necessary. If you are experiencing replication errors, see Troubleshooting Cloud SQL: Replication more information on how to resolve this issue.
character_set_connection
character_set_results
collation_connection
innodb_buffer_pool_dump_now
innodb_buffer_pool_load_abort
innodb_buffer_pool_load_now
innodb_ft_aux_table
foreign_key_checks
sql_select_limit
unique_checks
SET GLOBAL FLAG_NAME = FLAG_VALUE
Using the SET GLOBAL
command requires the CLOUDSQL_SPECIAL_SYSEM_VARIABLES_ADMIN
privilege, which is granted to the cloudsqlsuperuser
role.
For more information on how to grant special privilege access to a specific user, see About MySQL users . These flags are non-persisted. When your Cloud SQL instance is recreated or restarted, the flag settings are reset back to default value.
- binlog_order_commits
-
The default value for the
binlog_order_commits
flag isON
. Cloud SQL recommends to not change the default value of this flag. If the default value is changed toOFF
, 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:
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 thebatched_key_access
sub-flag is set toon
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
block_nested_loop
sub-flag is set toon
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
batched_key_access
, which was set toon
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.
System flags changed in Cloud SQL
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.
Variable Name | Setting in Cloud SQL. | Notes |
---|---|---|
ROW | Differs in MySQL 5.6 only | |
ABORT_SERVER | Differs in MySQL 5.6 only | |
64 | Applies to MySQL 8.0.26 and above | |
Barracuda | Differs in MySQL 5.6 only | |
O_DIRECT | ||
true | ||
ON | ||
TABLE | Removed in MySQL 8.4 | |
ON | ||
TABLE | Removed in MySQL 8.4 | |
1 | ||
3000 | ||
127.0.0.1 | Differs in MySQL 8.0 and later. | |
ON | ||
120 | Differs in MySQL 8.0 and later. | |
ON | MySQL 8.0 and later. For more information about this flag, see Partial revokes system flag in MySQL 8.0 . |
partial_revokes system flag in MySQL 8.0 and later
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.
-
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' @ '%' ;
-
With
partial_revokes
, you can use thegrant
andrevoke
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
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.
Index advisor flags
The following is a list of database flags that Cloud SQL for MySQL uses to enable and manage features specific to the index advisor .
Flag name | Type Acceptable values and notes |
Restart Required? |
---|---|---|
cloudsql_index_advisor_auto_advisor_schedule
|
string
default: 00:00
|
No |
cloudsql_index_advisor_run_at_timestamp
|
Datetime
default: 00:00:00
|
No |
Aliased flags
The following list below contains the flag names that have been changed by Cloud SQL for MySQL versions 8.0.26 and above.
Deprecated flag name | New flag name |
---|---|
log_slow_slave_statements | log_slow_replica_statements |
master_verify_checksum | source_verify_checksum |
slave_checkpoint_group | replica_checkpoint_group |
slave_checkpoint_period | replica_checkpoint_period |
slave_compressed_protocol | replica_compressed_protocol |
slave_net_timeout | replica_net_timeout |
slave_parallel_type | replica_parallel_type |
slave_parallel_workers | replica_parallel_workers |
slave_pending_jobs_size_max | replica_pending_jobs_size_max |
slave_preserve_commit_order | replica_preserve_commit_order |
slave_skip_errors | replica_skip_errors |
slave_sql_verify_checksum | replica_sql_verify_checksum |
slave_transaction_retries | replica_transaction_retries |
slave_type_conversions | replica_type_conversions |
sync_master_info | sync_source_info |
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 .
Troubleshooting
Issue | Troubleshooting |
---|---|
After enabling a flag the instance loops between panicking and crashing. | Contact customer support
to
request flag removal followed by a hard drain
. This forces the
instance to restart on a different host with a fresh configuration without
the undesired flag or setting. |
You see the error message Bad syntax for dict arg
when
trying to set a flag. |
Complex parameter values , such as comma-separated lists, require special treatment when used with gcloud commands. |
What's next
- Learn more about MySQL system variables .
- Learn more about Operational Guidelines .