Problemas de durabilidad de datos y disponibilidad
Columnas generadas (solo para instancias MySQL 5.7)
Debido a un problema en MySQL, el uso de columnas generadas puede provocar daños en los datos. Para obtener más información, consulta error #82736 de MySQL.
Problemas de conexión de la instancia
Certificados SSL/TLS vencidos
Si tu instancia está configurada para usar SSL, ve a la página Instancias de Cloud SQL en la Google Cloud consola y abre la instancia. Abre la página Conexiones, selecciona la pestaña Seguridad y asegúrate de que tu certificado de servidor sea válido. Si caducó, debes agregar uno nuevo y rotarlo.
Versión del proxy de Cloud SQL Auth
Si utilizas el proxy de Cloud SQL Auth para conectarte, asegúrate de utilizar la versión más reciente. Para obtener más información, visita Mantén actualizado el proxy de Cloud SQL Auth.
No autorizado para conectarte
Si intentas conectarte a una instancia que no existe en ese proyecto, el mensaje de error solo dirá que no estás autorizado para acceder a esa instancia.
No se puede crear una instancia de Cloud SQL
Si ves el mensaje de error Failed to create subnetwork. Router status is temporarily
unavailable. Please try again later. Help Token: [token-ID], vuelve a crear la instancia de Cloud SQL.
Problemas de administración
Solo se puede ejecutar una operación de importación o exportación de Cloud SQL de larga duración a la vez en una instancia. Cuando inicies una operación, asegúrate de que no necesites realizar otras operaciones en ella. Además, cuando inicias la operación, puedes cancelarla.
MySQL realiza confirmaciones automáticas en cada declaración DDL. Cloud SQL conserva todos los pasos de la importación hasta la cancelación de la instancia. Por lo tanto, es posible que tengas que limpiar los datos en la instancia de forma manual.
Problemas con la importación y la exportación de datos
La exportación del archivo CSV no formatea NULL ni líneas nuevas de manera adecuada.
Cuando exportas datos como CSV con la función de exportación de Cloud SQL, los NULL se exportan como "N, lo que puede hacer que el archivo CSV contenga comillas desiguales. Además, si los datos de texto contienen un carácter de líneas nuevas, se agrega una comilla de seguimiento al final de la línea.
Cuando importas un archivo que exportaste con el carácter de escape predeterminado, el archivo trata el valor como "NULL" en lugar de NULL. Para anular el valor predeterminado cuando exportes el archivo, usa --escape="5C".
La configuración del modo SQL afecta la forma en la que Cloud SQL interpreta las consultas de SQL.
Por ejemplo, si exportas desde una base de datos que no tiene habilitado el modo SQL Estricto y, luego, intentas importar a Cloud SQL (que habilita el modo SQL Estricto de forma predeterminada), la importación podría fallar. La práctica recomendada es usar en la importación el mismo modo SQL que usaste para la exportación.
La cláusula DEFINER puede hacer que la importación falle.
Una cláusula DEFINER puede hacer que una operación de importación falle si el usuario de DEFINER es un usuario de sistema o SUPER, y es diferente del usuario que realiza la importación a Cloud SQL. Obtén más información sobre el uso de DEFINER y las posibles soluciones en Cloud SQL.
Si intentas importar y exportar datos desde una base de datos grande (por ejemplo, una base de datos que tiene 500 GB de datos o más), las operaciones de importación y exportación pueden tardar mucho tiempo en completarse. Además, no puedes realizar otras operaciones (por ejemplo, la operación de copia de seguridad) mientras se realiza la importación o exportación. Una opción posible para mejorar el rendimiento del proceso de importación y exportación es restablecer una copia de seguridad anterior mediante gcloud o la API.
Cloud Storage admite un tamaño máximo de hasta 5 terabytes para un solo objeto.
Si tienes bases de datos de más de 5 TB, la operación de exportación a Cloud Storage falla. En ese caso, debes dividir tus
archivos de exportación en segmentos más pequeños.
Registros de transacciones y aumento de discos
Los registros se borran definitivamente una vez al día, no de forma continua. Cuando la cantidad de días de retención de
registros se configura para ser la misma que la cantidad de copias de seguridad, es posible que
se pierda un día de registro, según el momento en que se realice la copia de seguridad. Por ejemplo, establecer
la retención de registros en siete días y la retención de copias de seguridad en siete copias de seguridad implica que se
conservarán entre seis y siete días de registros.
Recomendamos configurar la cantidad de copias de seguridad en un día más que los días de
retención de registros para garantizar un mínimo de días específicos de retención.
Problemas con la actualización de la instancia de MySQL
Si usas Database Migration Service para actualizar tu instancia de MySQL de la versión 5.7 a la 8.0 y tienes procedimientos almacenados en la base de datos con el nombre mysql en la instancia de la versión 5.7, es posible que tus procedimientos almacenados puedan no copiarse a la base de datos mysql en la instancia actualizada de la versión 8.0. Además, es posible que no puedas crear procedimientos almacenados en la base de datos mysql en la instancia actualizada.
Problemas con la compresión de páginas de InnoDB
La compresión de páginas de InnoDB puede mejorar el rendimiento de las consultas de actualización, ya que reduce la cantidad de datos que se deben leer y escribir en el disco. Sin embargo, la compresión de páginas puede afectar el rendimiento de las consultas de actualización en tablas que se actualizan con frecuencia. Para evaluar el impacto de la compresión de páginas en tus consultas de actualización, puedes ejecutar una prueba de rendimiento con y sin compresión de páginas. Esto te ayuda a observar cómo la compresión de la página afecta el rendimiento de tu carga de trabajo.
Puedes optimizar el rendimiento de la compresión de páginas de la siguiente manera:
Usa un algoritmo de compresión adecuado para tu tipo de datos. Por ejemplo, usa LZ4 para datos de texto y ZLIB para datos binarios.
Evita usar la compresión para los datos que se actualizan con frecuencia.
La compresión y descompresión de datos puede ralentizar las consultas de actualización.
Problemas relacionados con Cloud Monitoring o Cloud Logging
Las instancias con los siguientes nombres de región se muestran de forma incorrecta en ciertos contextos, de la siguiente manera:
us-central1 se muestra como us-central
europe-west1 se muestra como europe
asia-east1 se muestra como asia
Este problema ocurre en los siguientes contextos:
Alertas en Cloud Monitoring
Explorador de métricas
Cloud Logging
Puedes mitigar el problema de las alertas en Cloud Monitoring y del explorador de métricas mediante etiquetas de metadatos de recursos.
Usa la etiqueta de metadatos del sistema region en lugar de la etiqueta de recurso supervisado cloudsql_databaseregion.
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-09-04 (UTC)"],[],[],null,["# Known issues\n\n\u003cbr /\u003e\n\nMySQL \\| [PostgreSQL](/sql/docs/postgres/known-issues \"View this page for the PostgreSQL database engine\") \\| [SQL Server](/sql/docs/sqlserver/known-issues \"View this page for the SQL Server database engine\")\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nThis page lists known issues with Cloud SQL for MySQL, along with\nways you can avoid or recover from these issues.\nIf you are experiencing issues with your instance, make sure you also review the [Operational Guidelines](/sql/docs/mysql/operational-guidelines), as well as the information in [Diagnosing Issues](/sql/docs/mysql/diagnose-issues).\n\n### Data durability and availability issues\n\n- Generated columns (MySQL 5.7 instances only)\n\n Due to an issue in MySQL, using generated columns might result in data\n corruption. For more information, see\n [MySQL bug #82736](https://bugs.mysql.com/bug.php?id=82736).\n\n### Instance connection issues\n\n- Expired SSL/TLS certificates\n\n\n If your instance is configured to use SSL, go to the\n [Cloud SQL Instances page](https://console.cloud.google.com/sql/instances)\n in the Google Cloud console and open the instance. Open its **Connections** page, select the\n **Security** tab and make sure that your server certificate is valid. If it has expired, you must\n add a new certificate and rotate to it.\n\n \u003cbr /\u003e\n\n- Cloud SQL Auth Proxy version\n\n If you are connecting using the Cloud SQL Auth Proxy, make sure you are using the\n most recent version. For more information, see\n [Keeping the Cloud SQL Auth Proxy up to date](/sql/docs/mysql/sql-proxy#keep-current).\n- Not authorized to connect\n\n If you try to connect to an instance that does not exist in that project,\n the error message only says that you are not authorized to access that\n instance.\n- Can't create a Cloud SQL instance\n\n If you see the `Failed to create subnetwork. Router status is temporarily\n unavailable. Please try again later. Help Token: [token-ID]` error\n message, try to create the Cloud SQL instance again.\n\n### Administrative issues\n\n- Only one long-running Cloud SQL import or export operation can run at a time on an instance. When you start an operation, make sure you don't need to perform other operations on the instance. Also, when you start the operation, you can [cancel it](/sql/docs/mysql/import-export/cancel-import-export).\n\n- MySQL auto-commits on each DDL statement. Cloud SQL\n persists all steps of the import up to cancelling the\n instance. Therefore, you might have to clean up the data on the\n instance manually.\n\n\u003cbr /\u003e\n\n### Issues with importing and exporting data\n\n- CSV export does not format NULLs and newlines correctly.\n\n When you export data as CSV using the Cloud SQL export feature,\n NULLs are exported as `\"N`, which can cause the CSV file to contain\n unbalanced quotation marks. Additionally, if your\n text data contains a newline character, a trailing quote mark is added\n at the end of the line.\n\n When you import a file that you exported using the default escape character,\n the file treats the value as `\"NULL\"` instead of `NULL`. To override the default\n when you export the file, use `--escape=\"5C\"`.\n\n \u003cbr /\u003e\n\n- The SQL Mode setting affects how Cloud SQL interprets SQL queries.\n\n For example, if you export from a database without Strict SQL enabled, then\n try to import to Cloud SQL (which enables Strict SQL by default), the\n import might fail. The best practice is to use the same SQL Mode on import\n that you used for export.\n\n \u003cbr /\u003e\n\n- The DEFINER clause may cause import to fail\n\n A DEFINER clause may cause an import operation to fail if the DEFINER user is\n a SUPER or system user and is different from the user doing the import into\n Cloud SQL. Learn more about [DEFINER usage](/sql/docs/mysql/import-export#definer-clause)\n and potential workarounds in Cloud SQL.\n\n \u003cbr /\u003e\n\n- If you're trying to import and export data from a large database (for example,\n a database that has 500 GB of data or greater), then the import and export\n operations might take a long time to complete. In addition, other operations\n (for example, the backup operation) aren't available for you to perform\n while the import or export is occurring. A potential option to improve the\n performance of the import and export process is to [restore a previous backup](/sql/docs/mysql/backup-recovery/restoring#projectid) using `gcloud`\n or the API.\n\n\u003c!-- --\u003e\n\n- Cloud Storage supports a [maximum single-object size up five terabytes](/storage-transfer/docs/known-limitations-transfer#object-limit). 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.\n\n### Transaction logs and disk growth\n\nLogs are purged once daily, not continuously. When the number of days of log\nretention is configured to be the same as the number of backups, a day of\nlogging might be lost, depending on when the backup occurs. For example, setting\nlog retention to seven days and backup retention to seven backups means that\nbetween six and seven days of logs will be retained.\n\nWe recommend setting the number of backups to at least one more than the days of\nlog retention to guarantee a minimum of specified days of log retention.\n\n### Issues with upgrading your MySQL instance\n\nIf you use Database Migration Service to [upgrade your MySQL instance](/sql/docs/mysql/upgrade-major-db-version-migrate) 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.\n\n### Issues with InnoDB page compression\n\n[InnoDB page compression](https://dev.mysql.com/doc/refman/8.0/en/innodb-page-compression.html)\ncan improve the performance of update queries by reducing the amount of data that\nneeds to be read and written to disk. However, page compression can impact performance on the\nupdate queries on frequently updated tables. To evaluate\nthe impact of page compression on your update queries, you can run a performance\ntest with and without page compression. This helps you to observe how page\ncompression affects the performance of your workload.\n\nYou can optimize page compression performance as follows:\n\n- Use a compression algorithm suitable for your data type. For example, use LZ4\n for text data and ZLIB for binary data.\n\n- Avoid using compression for data that is frequently updated.\n Compressing and decompressing data can slow down your update queries.\n\n### Issues related to Cloud Monitoring or Cloud Logging\n\nInstances with the following region names are displayed incorrectly in certain\ncontexts, as follows:\n\n- `us-central1` is displayed as `us-central`\n- `europe-west1` is displayed as `europe`\n- `asia-east1` is displayed as `asia`\n\nThis issue occurs in the following contexts:\n\n- Alerting in Cloud Monitoring\n- Metrics Explorer\n- Cloud Logging\n\nYou can mitigate the issue for Alerting in Cloud Monitoring, and for Metrics\nExplorer, by using\n[Resource metadata labels](https://cloud.google.com/monitoring/api/v3/metric-model#meta-labels).\nUse the system metadata label `region` instead of the\n[cloudsql_database](https://cloud.google.com/monitoring/api/resources#tag_cloudsql_database)\nmonitored resource label `region`."]]
