Known issues

This page lists known issues with Cloud SQL for MySQL, along with ways you can avoid or recover from these issues.

If you are experiencing issues with your instance, make sure you also review the Operational Guidelines, as well as the information in Diagnosing Issues.

Data durability and availability issues

  • Generated columns (MySQL 5.7 instances only)

    Due to an issue in MySQL, using generated columns might result in data corruption. For more information, see MySQL bug #82736.

Instance connection issues

  • Expired SSL/TLS certificates

    If your instance is configured to use SSL, go to the Cloud SQL Instances page in the Cloud console and open the instance. Open its Connections page, select the Security tab and make sure that your server certificate is valid. If it has expired, you must add a new certificate and rotate to it.

  • Cloud SQL Auth proxy version

    If you are connecting using the Cloud SQL Auth proxy, make sure you are using the most recent version. For more information, see Keeping the Cloud SQL Auth proxy up to date.

  • Not authorized to connect

    If you try to connect to an instance that does not exist in that project, the error message only says that you are not authorized to access that instance.

Administrative issues

  • Long-running Cloud SQL instance operations can't be cancelled or stopped

    Only one operation can run at a time on a Cloud SQL instance. For this reason, make sure you don't need to perform other operations on an instance when you start a long-running operation.

    When you start a long-running Cloud SQL instance operation, such as an import or export operation, there's no way to cancel the operation without restarting the instance.

  • Setting the time zone for MySQL instances

    It is possible to set the MySQL time zone to a named area, such as "Europe/Moscow", using a session variable. However, doing so is not supported in Cloud SQL, and is not guaranteed to provide up-to-date time settings. To change the default time zone for your instance, update the default_time_zone flag with the offset from UTC (for example, +10:00). Automatic adjustment to daylight savings time is not supported; you must update the default_time_zone flag manually to account for daylight savings time.

Issues with importing and exporting data

  • CSV export does not format NULLs and newlines correctly

    When you export data as CSV using the Cloud SQL export feature, NULLs are exported as "N, which can cause the CSV file to contain unbalanced quotation marks. Additionally, if your text data contains a newline character, a trailing quote mark is added at the end of the line.

  • The SQL Mode setting affects how Cloud SQL interprets SQL queries.

    For example, if you export from a database without Strict SQL enabled, then try to import to Cloud SQL (which enables Strict SQL by default), the import might fail. The best practice is to use the same SQL Mode on import that you used for export.

  • The DEFINER clause may cause import to fail

    A DEFINER clause may cause an import operation to fail if the DEFINER user is a SUPER or system user and is different from the user doing the import into Cloud SQL. Learn more about DEFINER usage and potential workarounds in Cloud SQL.

  • Cloud Storage supports a maximum single-object size up five terabytes. If you have databases larger than 5TB, the export operation to Cloud Storage fails. In this case, you need to break down your export files into smaller segments.

Transaction logs and disk growth

Logs are purged once daily, not continuously. When the number of days of log retention is configured to be the same as the number of backups, a day of logging might be lost, depending on when the backup occurs. For example, setting log retention to seven days and backup retention to seven backups means that between six and seven days of logs will be retained.

We recommend setting the number of backups to at least one more than the days of log retention to guarantee a minimum of specified days of log retention.

Issues with upgrading your MySQL instance

If you use Database Migration Service to upgrade your MySQL instance from version 5.7 to version 8.0, and you have stored procedures created in the database named mysql in your version 5.7 instance, then your stored procedures may not get copied to the mysql database in the upgraded version 8.0 instance. Also, you may not be able to create stored procedures in the mysql database in the upgraded instance.