This page contains a list of the most frequent issues you might run intowhen working with Cloud SQL instances and steps you can take to addressthem. Also review theKnown issues,Troubleshooting, andSupport page pages.

View logs

To see information about recent operations, you can view theCloud SQL instance operation logsor thePostgreSQL error logs.

Connection issues

See theDebugging connectionissues page or theConnectivity section in the troubleshooting page for help with connectionproblems.

Instance issues

Backups

For the best performance forbackups, keep thenumber of tables to a reasonable number.

For other backups issues, see theBackups section in the troubleshooting page.

Import and export

Imports into Cloud SQL and exports out of Cloud SQL can take a long time to complete, depending on the size of the data being processed. This can have the following impacts:

• You can't stop a long-running Cloud SQL instance operation.
• You can perform only one import or export operation at a time for each instance, and a long-running import or export blocks other operations, such as daily automated backups. Serverless exports allow you to run other operations, including editing instances, import, failover, and unblocking daily automated backups.

You can decrease the amount of time it takes to complete each operation by using the Cloud SQL import or export functionality with smaller batches of data.

For exports, you can perform the export from aread replica or useserverless export to minimize the impact on database performance and allow other operations to run on your instance while an export is running.

Note: Serverless export costs extra. See thepricing page.

For other import and export issues, see theImport and export section in the troubleshooting page.

Disk space

If your instance reaches the maximum storage amount allowed, writes tothe database fail. If you delete data, for example, by dropping atable, the space is freed, but it is not reflected in the reportedStorage Used of the instance. You can run theVACUUM FULL command torecover unused space; note that write operations are blocked while the vacuumcommand is running.Learn more.

Suspended state

There are various reasons why Cloud SQL may suspend an instance,including:

• Billing issues

  For example, if the credit card for the project's billing account hasexpired, the instance may be suspended. You can check the billinginformation for a project by going to the Google Cloud consolebilling page, selecting the project, and viewingthe billing account information used for the project. After you resolvethe billing issue, the instance returns to runnable status withina few hours.

• Key issues with Cloud Key Management Service

  For example, if the key version of the Cloud KMS that's used to encrypt the user data in the Cloud SQL instance isn't present, access to the key is revoked, or if the key is deactivated or deleted. For more information, seeUsing customer-managed encryption keys (CMEK).

• Legal issues

  For example, a violation of theGoogle Cloud Acceptable Use Policy may cause theinstance to be suspended. For more information, see "Suspensions andRemovals" in theGoogle Cloud Terms of Service.

• Operational issues

  For example, if an instance is stuck in a crash loop (it crasheswhile starting or just after starting), Cloud SQL may suspend it.

While an instance is suspended, you can continue to view information about itor you can delete it, if billing issues triggered the suspension.

Cloud SQL users with Platinum, Gold, or Silversupport packages can contact our support team directly aboutsuspended instances. All users can use the earlier guidance along with thegoogle-cloud-sql forum.

Performance

Overview

Cloud SQL supports performance-intensive workloads with up to 60,000 IOPSand no extra cost for I/O. IOPS and throughput performance depends on disk size,instance vCPU count, and I/O block size, among other factors.

Your instance's performance also depends on yourchoice of storage type andworkload.

Learn more about:

• Persistent disks and performance.
• Performance and throttling metrics.
• Optimizing disk performance.
• Other factors that affect performance.

Keep a reasonable number of database tables

Database tables consume system resources. A large numbercan affect instance performance and availability, and cause the instance tolose its SLA coverage.Learn more.

Enable query logs

You can log slow queries for Cloud SQL for PostgreSQL by settinglog_min_duration_statementflag. The queries that ran for at least the specified amount of time will belogged. If this value is specified without units, it is taken as milliseconds.Navigate to Operations Logging to view the logs.

General performance tips

Make sure that your instance is not constrained on memory or CPU. Forperformance-intensive workloads, ensure your instance has at least 60 GB ofmemory.For slow database inserts, updates, or deletes, check the locations of thewriter and database; sending data a long distance introduces latency.

Improve query performance by usingQuery Insights.

For slow database selects, consider the following:

• Caching is important for read performance. Check the variousblks_hit / (blks_hit + blks_read) ratios from thePostgreSQL Statistics Collector.Ideally, the ratio is above 99%. If not, considerincreasing the size of your instance's RAM.
• If your workload consists of CPU intensive queries (sorting, regularexpressions, other complex functions), your instance might be throttled;add vCPUs.
• Check the location of the reader and database - latency affects readperformance even more than write performance.
• Investigate non-Cloud SQL specific performance improvements, such asadding appropriate indexing, reducing data scanned, and avoiding extra roundtrips.

If you observe poor performance executing queries, useEXPLAIN to identify where to addindexes to tables to improve query performance. For example, make sureevery field that you use as a JOIN key has an index on both tables.

Troubleshoot

For other Cloud SQL issues, see thetroubleshooting page.

Error messages

For specific API error messages, see theError messages reference page.

Troubleshoot customer-managed encryption keys (CMEK)

Cloud SQL administrator operations, such as create, clone, or update, might fail due to Cloud KMS errors, and missing roles or permissions. Common reasons for failure include a missing Cloud KMS key version, a disabled or destroyed Cloud KMS key version, insufficient IAM permissions to access the Cloud KMS key version, or the Cloud KMS key version is in a different region than the Cloud SQL instance. Use the following troubleshooting table to diagnose and resolve common problems.

Customer-managed encryption keys troubleshooting table

For this error...	The issue might be...	Try this...
Per-product, per-project service account not found	The service account name is incorrect.	Make sure you created a service account for the correct user project. GO TO THE SERVICE ACCOUNTS PAGE.
Cannot grant access to the service account	The user account does not have permission to grant access to this key version.	Add theOrganization Administrator role to your user or service account. GO TO THE IAM ACCOUNTS PAGE
Cloud KMS key version is destroyed	The key version is destroyed.	If the key version is destroyed, you cannot use it to encrypt or decrypt data.
Cloud KMS key version is disabled	The key version is disabled.	Re-enable the Cloud KMS key version. GO TO THE CRYPTO KEYS PAGE
Insufficient permission to use the Cloud KMS key	Thecloudkms.cryptoKeyEncrypterDecrypter role is missing on the user or service account you are using to run operations on Cloud SQL instances, or the Cloud KMS key version doesn't exist.	In the Google Cloud project that hosts the key, add thecloudkms.cryptoKeyEncrypterDecrypter role to your user or service account. GO TO THE IAM ACCOUNTS PAGE If the role is already granted to your account, seeCreating a key to learn how to create a new key version. See note.
Cloud KMS key is not found	The key version does not exist.	Create a new key version. SeeCreating a key. See note.
Cloud SQL instance and Cloud KMS key version are in different regions	The Cloud KMS key version and Cloud SQL instance must be in the same region. It does not work if the Cloud KMS key version is in a global region or multi-region.	Create a key version in the same region where you want to create instances. SeeCreating a key. See note.
Cloud KMS key version is restored but instance is still suspended	The key version is disabled or doesn't grant proper permissions.	Re-enable the key version, and grant thecloudkms.cryptoKeyEncrypterDecrypter role to your user or service account in the Google Cloud project that hosts the key.

Note:If the instance is in a failed state during thecreate operation, you must delete it, add the role to the account you are using, and create a new instance with an active Cloud KMS key version.

Re-encryption troubleshooting table

For this error...	The issue might be...	Try this...
CMEK resource re-encryption failed because the Cloud KMS key is inaccessible. Please ensure that the primary key version is enabled and the permission is granted properly.	The key version is disabled or doesn't grant proper permissions.	Re-enable the Cloud KMS key version: GO TO THE CRYPTO KEYS PAGE In the Google Cloud project that hosts the key, confirm thecloudkms.cryptoKeyEncrypterDecrypter role is granted to your user or service account: GO TO THE IAM ACCOUNTS PAGE
CMEK resource re-encryption failed due to server internal error. Please retry later	There is a server internal error.	Retry re-encryption. For more information, seeRe-encrypt an existing CMEK-enabled instance or replica