Cette page répertorie les problèmes les plus fréquents que vous pouvez rencontrer en travaillant avec des instances Cloud SQL, ainsi que la procédure à suivre pour y remédier. Consultez également les pages Problèmes connus, Dépannage et Assistance.
Afficher les journaux
Pour afficher des informations sur les opérations récentes, vous pouvez consulter les journaux des opérations des instances Cloud SQL ou les journaux des erreurs MySQL.
L'instance ne répond pas
Si l'instance cesse de répondre aux connexions, ou si vous constatez une diminution des performances, assurez-vous qu'elle respecte les consignes opérationnelles. Si ce n'est pas le cas, elle n'est pas couverte par le Contrat de niveau de service Cloud SQL.
Problèmes de connexion
Pour obtenir de l'aide concernant les problèmes de connexion, consultez la page Déboguer les problèmes de connexion ou la section Connectivité de la page de dépannage.
Problèmes d'instance
Sauvegardes
Pour optimiser les performances des sauvegardes, conservez un nombre raisonnable de tables.
Pour les autres problèmes de sauvegarde, consultez la section Sauvegardes de la page de dépannage.
Importation et exportation
Les importations et les exportations dans Cloud SQL reviennent au même qu'employer l'utilitaire mysqldump
, mais avec la fonctionnalité d'importation/exportation de Cloud SQL, vous transférez des données à l'aide d'un bucket Cloud Storage.
L'exécution d'opérations d'importation dans Cloud SQL et d'exportations à partir de Cloud SQL peut prendre beaucoup de temps selon la taille des données traitées. Cela peut avoir les conséquences suivantes :
- Vous ne pouvez pas arrêter une opération d'instance Cloud SQL de longue durée.
- Vous ne pouvez effectuer qu'une seule opération d'importation ou d'exportation à la fois pour chaque instance, tandis qu'une importation ou une exportation de longue durée bloque d'autres opérations, telles que les sauvegardes automatiques quotidiennes. Les exportations sans serveur vous permettent d'exécuter d'autres opérations, comme la modification d'instances, l'importation, le basculement et le déblocage des sauvegardes quotidiennes.
Vous pouvez réduire le temps nécessaire à l'exécution de chaque opération en utilisant la fonctionnalité d'importation ou d'exportation Cloud SQL avec de plus petits lots de données.
Pour les exportations, vous pouvez effectuer l'exportation à partir d'une instance dupliquée avec accès en lecture ou utiliser l'exportation sans serveur afin de minimiser l'impact sur les performances de la base de données et de permettre que d'autres opérations s'exécutent sur votre instance pendant l'exécution d'une exportation.
Autres points à garder à l'esprit lors de l'importation :
- Si l'importation plante, cela peut être dû à une erreur de mémoire insuffisante.
Dans ce cas, vous pouvez essayer d'utiliser directement des commandes MySQL pour ajouter les paramètres
--extended-insert=FALSE --complete-insert
. Ces paramètres réduisent la vitesse de l'importation, mais également la quantité de mémoire requise par l'importation.
Pour les autres problèmes d'importation et d'exportation, consultez la section Importation et exportation de la page de dépannage.
Espace disque
Si l'instance atteint l'espace de stockage maximal autorisé, les écritures vers la base de données échouent. Si vous supprimez des données, par exemple en supprimant une table, l'espace de stockage utilisé indiqué pour l'instance ne reflète pas l'espace libéré. Consultez la section Comment récupérer l'espace d'une table supprimée ? dans les questions fréquentes pour obtenir une explication de ce comportement.Si vous atteignez la limite de stockage maximale, l'instance risque d'être bloquée au redémarrage.
Éviter la corruption des données
Éviter les colonnes générées
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.
Arrêts corrects
Lorsque Cloud SQL arrête une instance (par exemple, à des fins de maintenance), aucune nouvelle connexion n'est envoyée à cette dernière, et les connexions existantes sont terminées. Le temps d'arrêt de mysqld est plafonné à une minute. S'il ne se termine pas dans ce délai, l'arrêt du processus mysqld est forcé. Cela peut entraîner l'abandon des écritures sur le disque au beau milieu du processus.
Moteurs de base de données
InnoDB est le seul moteur de stockage accepté pour les instances MySQL, car il résiste mieux à la corruption des tables que d'autres moteurs de stockage MySQL, tels que MyISAM.
Par défaut, les tables de base de données Cloud SQL sont créées à l'aide du moteur de stockage InnoDB. Si votre syntaxe CREATE TABLE
inclut une option ENGINE
spécifiant un moteur de stockage autre qu'InnoDB, par exemple ENGINE = MyISAM
, la table n'est pas créée et des messages d'erreur semblables à l'exemple suivant s'affichent :
ERROR 3161 (HY000): Storage engine MyISAM is disabled (Table creation is disallowed).
Vous pouvez éviter cette erreur en supprimant l'option ENGINE = MyISAM
de la commande CREATE TABLE
. Cela entraîne la création de la table avec le moteur de stockage InnoDB.
Modifications apportées aux tables système
Les tables système MySQL utilisent le moteur de stockage MyISAM, y compris toutes les tables de la base de données mysql
, comme mysql.user
et mysql.db
. Ces tables sont sensibles aux arrêts incorrects. Vous devez exécuter la commande FLUSH CHANGES
après avoir modifié ces tables. En cas de corruption de MyISAM, les commandes CHECK TABLE
et REPAIR TABLE
peuvent vous permettre de rétablir l'état de fonctionnement, mais pas d'enregistrer des données.
Identifiants globaux de transaction (GTID)
Les GTID sont automatiquement activés dans toutes les instances MySQL. Cela offre une protection contre la perte de données lors de la création d'instances dupliquées et du basculement, et rend la réplication plus robuste. Cependant, MySQL impose certaines limites concernant les GTID, comme indiqué dans le manuel MySQL. Les opérations suivantes, risquées d'un point de vue transactionnel, ne peuvent pas être utilisées avec un serveur MySQL compatible GTID :
- Instructions
CREATE TABLE ... SELECT
- Instructions
CREATE TEMPORARY TABLE
à l'intérieur des transactions - Transactions ou instructions ayant une incidence à la fois sur les tables transactionnelles et non transactionnelles
Si vous utilisez une transaction risquée d'un point de vue transactionnel, un message d'erreur semblable à l'exemple suivant s'affiche :
Exception: SQLSTATE[HY000]: General error: 1786
CREATE TABLE ... SELECT is forbidden when @@GLOBAL.ENFORCE_GTID_CONSISTENCY = 1.
Utiliser des déclencheurs et des fonctions stockées
Si la journalisation binaire est activée sur votre instance et que vous devez utiliser des déclencheurs ou des fonctions stockées, assurez-vous que l'option log_bin_trust_function_creators
est définie sur on
.
État suspendu
Cloud SQL peut suspendre une instance pour plusieurs raisons, parmi lesquelles :
Problèmes de facturation
Par exemple, l'instance est susceptible d'être suspendue si la carte de crédit liée au compte de facturation du projet a expiré. Pour vérifier les informations de facturation d'un projet, accédez à la page de facturation de la console Google Cloud, puis sélectionnez le projet pour afficher les informations du compte de facturation correspondantes. Une fois le problème de facturation résolu, l'instance retourne à l'état opérationnel dans les heures qui suivent.
Principaux problèmes liés à Cloud Key Management Service
Par exemple, si la version de clé Cloud KMS utilisée pour chiffrer les données utilisateur dans l'instance Cloud SQL n'est pas présente ou si la clé est désactivée ou supprimée, l'accès à la clé est révoqué. Pour en savoir plus, consultez Utiliser des clés de chiffrement gérées par le client (CMEK).
Problèmes d'ordre juridique
Par exemple, une violation des Règles d'utilisation autorisée de Google Cloud peut entraîner la suspension de l'instance. Pour en savoir plus, consultez la section "Suspensions et suppressions" dans les Conditions d'utilisation de Google Cloud.
Problèmes opérationnels
Par exemple, si une instance est bloquée dans une boucle de plantage (disons qu'elle se bloque au démarrage ou juste après le démarrage), Cloud SQL est susceptible de la suspendre.
Lorsqu'une instance est suspendue, vous pouvez continuer à afficher les informations la concernant ou la supprimer si la suspension a été déclenchée par des problèmes de facturation.
Les utilisateurs de Cloud SQL disposant des formules d'assistance Platinum, Gold ou Silver peuvent contacter directement notre équipe d'assistance au sujet des instances suspendues. Tous les utilisateurs peuvent utiliser les conseils précédents et accéder au forum google-cloud-sql.
Performances
Présentation
Cloud SQL traite les charges de travail exigeantes en performances et peut gérer jusqu'à 60 000 IOPS sans frais supplémentaires. Les performances d'IOPS et de débit dépendent de facteurs tels que la taille des disques, le nombre de processeurs virtuels de l'instance et la taille des blocs d'E/S.
Les performances de votre instance dépendent également du type de stockage que vous avez choisi et de votre charge de travail.
En savoir plus :
- Disques persistants et performances.
- Performances et métriques de limitation.
- Optimiser les performances des disques.
- Autres facteurs ayant une incidence sur les performances.
Activer les journaux de requêtes
Pour ajuster les performances de vos requêtes, vous pouvez configurer Cloud SQL pour enregistrer les requêtes lentes en ajoutant les options de base de données --log_output='FILE'
et --slow_query_log=on
à votre instance.
De cette façon, la sortie du journal sera disponible dans la visionneuse de journaux de Google Cloud Console.
Notez que les frais de journalisation de Google Cloud Observability s'appliquent.
Ne définissez pas log_output sur TABLE
. Cela peut entraîner des problèmes de connexion, comme décrit dans la section Conseils pour l'utilisation d'options.
Vous pouvez consulter ce tutoriel pour savoir comment enregistrer et surveiller les requêtes lentes Cloud SQL pour MySQL à l'aide de Cloud Logging et Cloud Monitoring.
Activer la surveillance des verrous
Les moniteurs InnoDB fournissent des informations sur l'état interne du moteur de stockage InnoDB que vous pouvez utiliser pour ajuster les performances.
Accédez à l'instance à l'aide du client MySQL, puis obtenez une sortie du moniteur à la demande :
SHOW ENGINE INNODB STATUS\G
Pour obtenir des explications sur les différentes sections de la sortie du moniteur, consultez la page InnoDB Standard Monitor and Lock Monitor Output (Sortie de surveillance standard et surveillance des verrous InnoDB).
Vous pouvez activer les moniteurs InnoDB afin que la sortie soit générée régulièrement dans un fichier ou une table, mais cela entraînera une détérioration des performances. Pour en savoir plus, consultez la page Activer les moniteurs InnoDB.
Utiliser un schéma de performances
La fonctionnalité MySQL Performance Schema permet de surveiller l'exécution du serveur MySQL à un niveau inférieur. La manière la plus simple d'utiliser les statistiques générées dans performance_schema est d'utiliser la fonctionnalité MySQL Workbench Performance Reports.
Maintenir un nombre raisonnable de tables de base de données
Les tables de base de données consomment des ressources système. Si elles sont très nombreuses, cela peut affecter les performances et la disponibilité de l'instance, et entraîner la perte de sa couverture par le contrat de niveau de service. En savoir plus
Conseils relatifs aux performances générales
. Pour les insertions, mises à jour ou suppressions lentes de bases de données, envisagez les actions suivantes :- Vérifiez les emplacements du processus d'écriture et de la base de données. L'envoi de données sur une longue distance entraîne une latence.
En cas de sélections lentes dans une base de données, prenez en compte les éléments suivants :
- La mise en cache est importante pour les performances de lecture. Comparez la taille de l'ensemble de données à celle de la mémoire RAM de l'instance. Dans l'idéal, l'intégralité de l'ensemble de données tient dans 70 % de la mémoire RAM de l'instance. Le cas échéant, les requêtes ne sont pas limitées par les performances d'E/S. Si ce n'est pas le cas, envisagez d'augmenter la taille de la mémoire RAM de votre instance.
- Si la charge de travail consiste en des requêtes nécessitant une utilisation intensive des processeurs (opérations de tri, expressions régulières et autres fonctions complexes), il est possible que votre instance soit limitée : pensez à augmenter le nombre de processeurs.
Si vous constatez de mauvaises performances lors de l'exécution de requêtes, utilisez EXPLAIN
. EXPLAIN est une instruction que vous ajoutez à d'autres instructions, comme SELECT. Elle renvoie des informations sur la manière dont MySQL exécute l'instruction. Elle est compatible avec les instructions SELECT, DELETE, INSERT, REPLACE et UPDATE. Par exemple, EXPLAIN SELECT * FROM myTable;
.
Utilisez EXPLAIN
pour identifier les endroits où vous pouvez effectuer les opérations suivantes :
Ajouter des index aux tables pour améliorer les performances des requêtes. Par exemple, assurez-vous que chaque champ utilisé en tant que clé JOIN (clé de jointure) possède un index sur les deux tables.
Améliorer les opérations
ORDER BY
. SiEXPLAIN
affiche "Using temporary; Using filesort" (Utilisation de tables temporaires ; Tri du fichier) dans la colonne Extra de la sortie, les résultats intermédiaires sont stockés dans un fichier qui est ensuite trié, ce qui entraîne généralement de mauvaises performances. Dans ce cas, effectuez l'une des opérations suivantes :Si possible, utilisez des index plutôt que le tri. Pour en savoir plus, consultez la page Optimisation ORDER BY.
Augmentez la taille de la variable
sort_buffer_size
pour la session de requête.Utilisez moins de mémoire RAM par ligne en déclarant des colonnes d'une taille limitée au strict nécessaire.
Résoudre les problèmes
Si vous rencontrez d'autres problèmes Cloud SQL, consultez la page de Dépannage.
Messages d'erreur
Pour en savoir plus sur les messages d'erreur liés à l'API, consultez la page de référence Messages d'erreur.
Résoudre les problèmes liés aux clés de chiffrement gérées par le client (CMEK)
Les opérations d'administrateur Cloud SQL, telles que la création, le clonage ou la mise à jour peuvent échouer en raison d'erreurs Cloud KMS et de l'absence de rôles ou d'autorisations. Les causes habituelles d'échec sont les suivantes : la version de clé Cloud KMS est manquante, la version de clé Cloud KMS est désactivée ou détruite, les autorisations IAM sont insuffisantes pour accéder à la version de clé Cloud KMS ou la version de clé Cloud KMS se trouve dans une région différente de celle de l'instance Cloud SQL. Utilisez le tableau de dépannage ci-dessous pour diagnostiquer et résoudre les problèmes courants.
Tableau de dépannage des clés de chiffrement gérées par le client
Pour cette erreur... | Le problème peut être... | Essayez ce qui suit... |
---|---|---|
Le compte de service par produit et par projet est introuvable | Le nom du compte de service est incorrect. | Assurez-vous d'avoir créé un compte de service pour le bon projet utilisateur. |
Impossible d'accorder l'accès au compte de service | Le compte utilisateur n'a pas l'autorisation d'accorder l'accès à cette version de clé. | Ajoutez le rôle Administrateur de l'organisation à votre compte utilisateur ou de service.
|
La version de clé Cloud KMS est détruite | La version de clé est détruite. | Si la version de clé est détruite, vous ne pouvez pas l'utiliser pour chiffrer ou déchiffrer des données. |
La version de clé Cloud KMS est désactivée | La version de clé est désactivée. | Réactivez la version de clé Cloud KMS.
|
Autorisation insuffisante pour utiliser la clé Cloud KMS | Le rôle cloudkms.cryptoKeyEncrypterDecrypter est manquant sur le compte utilisateur ou de service que vous utilisez pour exécuter des opérations sur des instances Cloud SQL, ou la version de clé Cloud KMS n'existe pas. |
Dans le projet Google Cloud qui héberge la clé, ajoutez le rôle cloudkms.cryptoKeyEncrypterDecrypter à votre compte utilisateur ou de service.
Si le rôle est déjà attribué à votre compte, consultez Créer une clé pour savoir comment créer une version de clé. Voir la remarque ci-dessous. |
La clé Cloud KMS est introuvable | La version de clé n'existe pas. | Créez une nouvelle version de la clé. Consultez la section Créer une clé. Voir la remarque ci-dessous. |
L'instance Cloud SQL et la version de clé Cloud KMS se trouvent dans des régions différentes | La version de clé Cloud KMS et l'instance Cloud SQL doivent se trouver dans la même région. Cela ne fonctionnera pas si la version de clé Cloud KMS se trouve dans une région mondiale ou dans un emplacement multirégional. | Créez une version de clé dans la même région que celle où vous souhaitez créer des instances. Consultez la section Créer une clé. Voir la remarque ci-dessous. |
La version de clé Cloud KMS est restaurée, mais l'instance est toujours suspendue | La version de clé est désactivée ou n'accorde pas les autorisations appropriées. | Réactivez la version de clé et attribuez le rôle cloudkms.cryptoKeyEncrypterDecrypter à votre compte utilisateur ou de service dans le projet Google Cloud qui héberge la clé. |
Tableau de dépannage du rechiffrement
Pour cette erreur... | Le problème peut être... | Essayez ce qui suit... |
---|---|---|
Le rechiffrement des ressources CMEK a échoué, car la clé Cloud KMS est inaccessible. Veuillez vous assurer que la version de clé primaire est activée et que l'autorisation est accordée correctement. | La version de clé est désactivée ou n'accorde pas les autorisations appropriées. | Réactivez la version de clé Cloud KMS : ACCÉDER À LA PAGE "CLÉS DE CHIFFREMENT" Dans le projet Google Cloud qui héberge la clé, confirmez que le rôle |
Échec du rechiffrement des ressources CMEK en raison d'une erreur interne du serveur. Veuillez réessayer plus tard. | Une erreur interne du serveur s'est produite. | Relancez le rechiffrement. Pour en savoir plus, consultez Rechiffrer une instance ou une instance répliquée existante sur laquelle l'option CMEK est activée. |