Operational guidelines

MySQL   |  PostgreSQL   |  SQL Server

The Cloud SQL Service Level Agreement (SLA) excludes outages "caused by factors outside of Google’s reasonable control". This page describes some of the user-controlled configurations that can cause an outage for a Cloud SQL instance to be excluded.

Introduction

Cloud SQL strives to give you as much control over how your instance is configured as possible. This includes some configurations that increase the risk of instance downtime, depending on the load and other configuration parameters. If your instance goes down, and Cloud SQL determines that it was out of compliance with the operational limits as described on this page, then the downtime period is not covered by (or does not count against) the Cloud SQL SLA.

This list of operational limits is presented to inform you which configurations present these risks, ways to avoid inadvertently moving into one of these configurations, and ways to mitigate the risks when the configuration is required for your business environment.

Note: You are responsible for monitoring your instance to ensure that it is properly sized and configured for the size and type of load it is experiencing. Potential impacts and detection methods are listed in the tables below.

Excluded configurations

The excluded configurations fall into the following categories:

• General configuration requirements
• Database flag values
• Resource constraints

General configuration requirements

Only Cloud SQL instances configured for high availability with at least one dedicated CPU are covered by the Cloud SQL SLA. Shared-core instances and single-zone instances are not covered by the SLA.

If the instance is configured and used in a way that the workload overloads the instance, then the SLA does not apply.

We strongly advise you to set up alerts and monitoring in Cloud Monitoring.

Database flag values

Cloud SQL lets you configure your instance using database flags. Some of these flags can be set in ways that might compromise the stability of the instance or the durability of its data.

Resource constraints

The following resource constraints must be avoided to retain SLA coverage:

• Storage full
• CPU overloaded
• Memory overloaded
• Too many database tables

Constraint	Description	Detection	Remedy	Prevention
Storage full	If your instance runs out of storage, and the automatic storage increase capability is not enabled, your instance goes offline; this outage is not covered by the SLA.	You can view the amount of storage your instance is using on the Instance details page in the Google Cloud console. Learn more. To monitor your storage usage and receive alerts at a specified threshold, set up a Stackdriver alert. Learn more.	Increase the storage size for the instance. Although storage size can be increased, it cannot be decreased.	Enable automatic storage increase for the instance. Learn more.
CPU overloaded	If CPU utilization is over 98% for six hours, your instance is not properly sized for your workload, and it is not covered by the SLA.	You can view the percentage of available CPU your instance is using on the Instance details page in the Google Cloud console. Learn more. To monitor your CPU usage and receive alerts at a specified threshold, set up a Stackdriver alert. Learn more.	Increase the number of CPUs for your instance. Note that changing CPUs requires an instance restart. If your instance is already at the maximum number of CPUs, shard your database to multiple instances.	Monitor CPU usage and increase when necessary. Note that changing your instance CPUs requires a restart.
Memory overloaded	You can use the total_usage metric to observe the percentage of available memory that your Cloud SQL instance is using, including memory used by the database container and memory allocated by the operating system cache. When looking for signs of memory exhaustion, you should primarily use the usage metric. To avoid out-of-memory errors, we recommend that this metric remains below 90%. If memory utilization is over 90% for six hours, your instance isn't properly sized for your workload and it's not covered by the SLA. By observing the difference between the two metrics, you can identify how much memory is utilized by processes versus how much is used by the operating system cache. You can repurpose the memory in this cache. To learn more about monitoring both metrics in the Google Cloud console, see Metrics.	To predict out-of-memory issues, check both metrics and interpret them together. If the metrics appear high, the instance might be low in memory. This can be because of a custom configuration, the instance being undersized for the workload, or a combination of these factors. To monitor your memory usage and receive alerts at a specified threshold, set up an alert. For more information about configuring alerts, see Introduction to alerting.	Scale your Cloud SQL instance to increase the size of its memory. Changing the instance's memory size requires a restart. If your instance is already at the maximum memory size, shard your database across multiple instances.	Monitor the memory usage and increase it when necessary.
Too many database tables	If you have 50,000 or more database tables on a single instance, it could result in the instance becoming unresponsive or unable to perform maintenance operations, and the instance is not covered by the SLA.	To see how many tables there are on your instance: SELECT COUNT(*) FROM information_schema.tables; To see how many tables there are in each database: SELECT TABLE_SCHEMA,COUNT(*) FROM information_schema.tables group by TABLE_SCHEMA;	Reduce the number of tables to less than 50,000. If you cannot immediately reduce the number of tables, you can reduce the likelihood of your instance being impacted by the high table count by setting the innodb_file_per_table flag to OFF; however, this setting does not bring the instance back into SLA compliance.	If your data architecture requires many tables, split the data across several instances.