Problèmes de disponibilité et de durabilité des données
Colonnes générées (instances MySQL 5.7 uniquement)
En raison d'un problème dans MySQL, l'utilisation de colonnes générées peut entraîner une corruption des données. Pour en savoir plus, reportez-vous au bug MySQL n° 82736.
Problèmes de connexion à l'instance
Certificats SSL/TLS expirés
Si votre instance est configurée pour utiliser SSL, accédez à la page Instances Cloud SQL dans la console Google Cloud et ouvrez l'instance. Accédez à la page Connexions, sélectionnez l'onglet Sécurité et vérifiez que le certificat de serveur est valide. S'il a expiré, vous devez ajouter un nouveau certificat et effectuer une rotation pour le mettre en application.
Version du proxy d'authentification Cloud SQL
Si vous vous connectez à l'aide du proxy d'authentification Cloud SQL, assurez-vous d'utiliser la version la plus récente. Pour en savoir plus, consultez la section Maintenir le proxy d'authentification Cloud SQL à jour.
Connexion non autorisée
Si vous essayez de vous connecter à une instance qui n'existe pas dans le projet concerné, un message d'erreur vous indique simplement que vous n'êtes pas autorisé à y accéder.
Impossible de créer une instance Cloud SQL
Si le message d'erreur Failed to create subnetwork. Router status is temporarily
unavailable. Please try again later. Help Token: [token-ID] s'affiche, essayez de créer à nouveau l'instance Cloud SQL.
Problèmes d'administration
Une seule opération d'importation ou d'exportation Cloud SQL de longue durée peut être exécutée à la fois sur une instance. Lorsque vous démarrez une opération, assurez-vous que vous n'avez pas besoin d'effectuer d'autres opérations sur l'instance. En outre, lorsque vous démarrez l'opération, vous pouvez l'annuler.
MySQL effectue un commit automatique sur chaque instruction LDD. Cloud SQL conserve toutes les étapes de l'importation jusqu'à l'annulation de l'instance. Par conséquent, vous devrez peut-être nettoyer les données de l'instance manuellement.
Problèmes d'importation et d'exportation des données
L'exportation CSV ne formate pas correctement les valeurs NULL ni les nouvelles lignes.
Lorsque vous exportez des données au format CSV à l'aide de la fonctionnalité d'exportation Cloud SQL, les valeurs NULL sont exportées en tant que "N, ce qui peut entraîner des problèmes au niveau des guillemets dans le fichier CSV. En outre, si vos données de texte contiennent un caractère de nouvelle ligne, un guillemet final est ajouté en bout de ligne.
Lorsque vous importez un fichier que vous avez exporté avec le caractère d'échappement par défaut, le fichier traite la valeur comme "NULL" au lieu de NULL. Pour remplacer la valeur par défaut lorsque vous exportez le fichier, utilisez --escape="5C".
Le paramètre Mode SQL a une incidence sur la façon dont Cloud SQL interprète les requêtes SQL.
Par exemple, si vous exportez depuis une base de données sans SQL Strict, puis que vous essayez d'importer dans Cloud SQL (qui active le mode SQL Strict par défaut), l'importation peut échouer. La bonne pratique consiste à utiliser le même mode SQL pour l'importation et pour l'exportation.
La clause DEFINER peut entraîner l'échec de l'importation.
Une clause DEFINER peut faire échouer une opération d'importation si l'utilisateur est un super-utilisateur ou un utilisateur système et qu'il est différent de celui qui effectue l'importation dans Cloud SQL. Apprenez-en plus sur l'utilisation de la clause DEFINER et les solutions potentielles dans Cloud SQL.
Si vous essayez d'importer et d'exporter des données à partir d'une base de données volumineuse (par exemple, une base de données contenant au moins 500 Go de données), les opérations d'importation et d'exportation peuvent prendre beaucoup de temps. En outre, d'autres opérations (par exemple, l'opération de sauvegarde) ne sont pas disponibles pendant l'importation ou l'exportation. Une option potentielle pour améliorer les performances du processus d'importation et d'exportation consiste à restaurer une sauvegarde précédente à l'aide de gcloud ou de l'API.
Cloud Storage accepte une taille d'objet unique maximale de 5 téraoctets.
Si vous disposez de bases de données plus volumineuses, l'opération d'exportation vers Cloud Storage échoue. Dans ce cas, vous devez diviser vos fichiers d'exportation en segments plus petits.
Journaux des transactions et augmentation de la taille du disque
Les journaux sont supprimés définitivement une fois par jour, et non de manière continue. Lorsque le nombre de jours de conservation des journaux est configuré pour être identique au nombre de sauvegardes, une journée de journalisation peut être perdue, selon le moment où la sauvegarde se produit. Par exemple, si vous définissez la durée de conservation des journaux sur sept jours et la durée de conservation de sauvegarde sur sept sauvegardes, cela signifie que six à sept jours de journaux seront conservés.
Nous vous recommandons de définir le nombre de sauvegardes sur une valeur correspondant au moins à la durée de conservation des journaux plus un, afin de garantir un minimum de jours spécifiés de conservation des journaux.
Problèmes liés à la mise à niveau de votre instance MySQL
Si vous utilisez le service de migration de base de données pour mettre à niveau votre instance MySQL de la version 5.7 vers la version 8.0, et que vous avez stocké des procédures créées dans la base de données mysql dans votre instance de version 5.7, vos procédures stockées peuvent ne pas être copiées dans la base de données mysql de l'instance mise à niveau vers la version 8.0. De plus, vous risquez de ne pas pouvoir créer de procédures stockées dans la base de données mysql de l'instance mise à niveau.
Problèmes liés à la compression des pages InnoDB
La compression des pages InnoDB peut améliorer les performances des requêtes de mise à jour en réduisant la quantité de données à lire et à écrire sur le disque. Toutefois, la compression des pages peut avoir un impact sur les performances des requêtes de mise à jour sur les tables fréquemment mises à jour. Pour évaluer l'impact de la compression des pages sur vos requêtes de mise à jour, vous pouvez effectuer un test de performances avec et sans compression des pages. Cela vous permet d'observer l'impact de la compression des pages sur les performances de votre charge de travail.
Vous pouvez optimiser les performances de compression des pages comme suit :
Utilisez un algorithme de compression adapté à votre type de données. Par exemple, utilisez LZ4 pour les données textuelles et ZLIB pour les données binaires.
Évitez d'utiliser la compression pour les données fréquemment mises à jour.
La compression et la décompression des données peuvent ralentir vos requêtes de mise à jour.
Problèmes liés à Cloud Monitoring ou Cloud Logging
Les instances portant les noms de région suivants s'affichent de manière incorrecte dans certains contextes, comme suit :
us-central1 s'affiche en tant que us-central
europe-west1 s'affiche en tant que europe
asia-east1 s'affiche en tant que asia
Ce problème se produit dans les contextes suivants :
Alertes dans Cloud Monitoring
Explorateur de métriques
Cloud Logging
Vous pouvez limiter les problèmes liés aux alertes dans Cloud Monitoring et à l'explorateur de métriques à l'aide des libellés de métadonnées de ressource.
Utilisez le libellé de métadonnées système region au lieu du libellé de ressource surveillée cloudsql_databaseregion.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/04 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 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`."]]
