Déboguer les problèmes de connexion

Présentation

Généralement, les problèmes de connexion relèvent de l'un des trois domaines suivants :

  • Connexion – parvenez-vous à accéder à votre instance via le réseau ?
  • Autorisation – êtes-vous autorisé à vous connecter à l'instance ?
  • Authentification – la base de données accepte-t-elle vos identifiants de base de données ?

Chacun de ces éléments peut être subdivisé en différentes pistes d'analyse. La section suivante présente des exemples de questions que vous pouvez vous poser afin de mieux cerner le problème :

Checklist des problèmes de connexion

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 des problèmes de connectivité supplémentaires

Pour d'autres problèmes, consultez la section Connectivité sur la page de dépannage.

Problèmes de connexion courants

Vérifier que l'application ferme correctement les connexions

Si vous constatez des erreurs contenant "Aborted connection nnnn to db:", cela indique généralement que votre application ne met pas fin aux connexions de manière appropriée. Des problèmes de réseau peuvent également provoquer cette erreur. Elle n'indique pas forcément des problèmes avec votre instance Cloud SQL. Vous êtes également invité à exécuter tcpdump pour inspecter les paquets afin d'identifier la source du problème.

Pour obtenir des exemples de bonnes pratiques en matière de gestion des connexions, consultez la page Gérer les connexions à la base de données.

Vérifier la date d'expiration des certificats

Si votre instance est configurée pour utiliser SSL, accédez à la page "Instances Cloud SQL" dans Cloud Console et ouvrez l'instance. Accédez à la page Connexions et vérifiez que votre certificat de serveur est valide. S'il a expiré, vous devez ajouter un nouveau certificat et effectuer une rotation pour le mettre en application.

Vérifier que vous êtes autorisé à vous connecter

En cas d'échec de connexion, vérifiez que vous êtes autorisé à vous connecter :

  • Si vous ne parvenez pas à vous connecter à l'aide d'une adresse IP (par exemple, vous vous connectez depuis votre environnement sur site avec le client mysql), assurez-vous que l'adresse IP à laquelle vous vous connectez est autorisée à se connecter à l'instance Cloud SQL.

    Les connexions à une instance Cloud SQL à l'aide d'une adresse IP privée sont automatiquement autorisées pour les plages d'adresses RFC 1918. De cette manière, tous les clients privés peuvent accéder à la base de données sans passer par le proxy d'authentification Cloud SQL. Les plages d'adresses non-RFC 1918 doivent être configurées en tant que réseaux autorisés.

    Par défaut, Cloud SQL n'apprend pas les routes de sous-réseau non-RFC 1918 à partir de votre VPC. Vous devez mettre à jour l'appairage de réseaux vers Cloud SQL pour exporter les routes non-RFC 1918. Exemple :

    gcloud compute networks peerings update cloudsql-mysql-googleapis-com \
    --network=NETWORK \
    --export-subnet-routes-with-public-ip \
    --project=PROJECT_ID
    
  • Voici votre adresse IP actuelle.

  • Essayez la commande gcloud sql connect pour vous connecter à votre instance. Cette commande autorise votre adresse IP pour une courte période. Vous pouvez l'exécuter dans un environnement où le SDK Cloud et le client mysql sont installés. Vous pouvez également exécuter cette commande dans Cloud Shell, disponible dans Google Cloud Console et sur lequel le SDK Cloud et le client mysql sont préinstallés. Cloud Shell fournit une instance Compute Engine qui vous permet de vous connecter à Cloud SQL.
  • Autorisez temporairement toutes les adresses IP à se connecter à une instance. Pour IPv4, autorisez 0.0.0.0/0 (pour IPv6, autorisez ::/0).

Vérifier votre mode de connexion

Si vous recevez un message d'erreur du type :

ERROR 1045 (28000): Access denied for user 'root'@'1.2.3.4' (using password: NO)

lorsque vous vous connectez, vérifiez que avez bien renseigné un mot de passe.

Si vous recevez un message d'erreur du type :

ERROR 1045 (28000): Access denied for user 'root'@'1.2.3.4' (using password: YES)

lorsque vous vous connectez, vérifiez que vous utilisez le bon mot de passe et que vous vous connectez via SSL si l'instance l'exige.

Déterminer le mode de lancement des connexions

Pour afficher des informations sur vos connexions actuelles, connectez-vous à votre base de données et exécutez la commande suivante :

SHOW PROCESSLIST;

Les connexions qui affichent une adresse IP, telle que 1.2.3.4, se connectent via une adresse IP. Les connexions avec cloudsqlproxy~1.2.3.4 utilisent le proxy d'authentification Cloud SQL, sinon elles proviennent d'App Engine. Les connexions à partir de localhost peuvent être utilisées par certains processus Cloud SQL internes.

Comprendre les limites de connexion

Les instances Cloud SQL ne sont pas limitées en nombre de requêtes par seconde. Toutefois, il existe des limites spécifiques liées aux connexions, à la taille et à App Engine. Consultez la section Quotas et limites pour en savoir plus.

Les connexions aux bases de données consomment des ressources sur le serveur et sur l'application de connexion. Suivez toujours les bonnes pratiques en matière de gestion des connexions afin de réduire au maximum l'encombrement de votre application et les risques de dépassement des limites de connexion Cloud SQL. Pour en savoir plus, consultez la page Gérer les connexions à la base de données.

Afficher les connexions et les threads

Si le message d'erreur "too many connections" (trop de connexions) s'affiche ou si vous souhaitez savoir ce qui se passe sur une instance, exécutez la commande SHOW PROCESSLIST pour afficher le nombre de connexions et de threads.

Depuis un client MySQL, exécutez :

mysql> SHOW PROCESSLIST;

Un résultat semblable aux lignes suivantes doit s'afficher :

+----+-----------+--------------+-----------+---------+------+-------+----------------------+
| Id | User      | Host         | db        | Command | Time | State | Info                 |
+----+-----------+--------------+-----------+---------+------+-------+----------------------+
|  3 | user-name | client-IP    | NULL      | Query   |    0 | NULL  | SHOW processlist     |
|  5 | user-name | client-IP    | guestbook | Sleep   |    1 |       | SELECT * from titles |
| 17 | user-name | client-IP    | employees | Query   |    0 | NULL  | SHOW processlist     |
+----+-----------+--------------+-----------+---------+------+-------+----------------------+
3 rows in set (0.09 sec)

Pour en savoir plus sur l'interprétation des colonnes renvoyées par PROCESSLIST, consultez la documentation de référence MySQL.

Pour obtenir le nombre de threads, vous pouvez exécuter :

mysql> SHOW STATUS WHERE Variable_name = 'Threads_connected';

Un résultat semblable aux lignes suivantes doit s'afficher :

+-------------------+-------+
| Variable_name     | Value |
+-------------------+-------+
| Threads_connected | 7     |
+-------------------+-------+
1 row in set (0.08 sec)

Délai avant expiration des connexions (depuis Compute Engine)

Les connexions à une instance Compute Engine expirent après 10 minutes d'inactivité, ce qui peut affecter les connexions inutilisées à longue durée de vie entre votre instance Compute Engine et votre instance Cloud SQL. Pour plus d'informations, consultez la section Mise en réseau et pare-feu dans la documentation Compute Engine.

Pour maintenir des connexions non utilisées à longue durée de vie, vous pouvez définir TCP keepalive. Les commandes suivantes définissent la valeur de TCP keepalive sur une minute et rendent la configuration permanente dans tous les redémarrages d'instance.

Affichez la valeur tcp_keepalive_time actuelle.

cat /proc/sys/net/ipv4/tcp_keepalive_time

Définissez le paramètre tcp_keepalive_time sur 60 secondes et de manière permanente à chaque redémarrage.

echo 'net.ipv4.tcp_keepalive_time = 60' | sudo tee -a /etc/sysctl.conf

Appliquez la modification.

sudo /sbin/sysctl --load=/etc/sysctl.conf

Affichez la valeur tcp_keepalive_time pour vérifier que la modification a été appliquée.

cat /proc/sys/net/ipv4/tcp_keepalive_time

Se connecter avec IPv6

Si vous recevez l'un des messages d'erreur suivants :

Can't connect to MySQL server on '2001:1234::4321' (10051)
Can't connect to MySQL server on '2001:1234::4321' (101)

lorsque vous vous connectez, il est probable que vous tentiez de vous connecter à l'adresse IPv6 de l'instance alors que ce protocole n'est pas disponible sur votre poste de travail. Pour vérifier si IPv6 fonctionne sur votre poste de travail, accédez à ipv6.google.com. S'il ne se charge pas, IPv6 n'est pas disponible. Connectez-vous à l'adresse IPv4 ou à l'instance Cloud SQL. Vous devrez peut-être d'abord ajouter une adresse IPv4 à l'instance.

Échecs de connexion occasionnels (ancienne fonctionnalité de haute disponibilité)

Lorsque Cloud SQL redémarre une instance en raison d'événements de maintenance, les connexions peuvent être acheminées vers l'instance dupliquée de basculement. Lors de la connexion à l'instance dupliquée de basculement :

  • Les requêtes de lecture provenant de clients utilisant des connexions non chiffrées aboutissent normalement. Cependant, les requêtes d'écriture échouent et renvoient un message d'erreur, tel que "Error 1290: The MySQL server is running with the --read-only option so it cannot execute this statement" (Erreur 1290 : Le serveur MySQL s'exécute avec l'option lecture seule et ne peut donc pas exécuter cette instruction).
  • Les requêtes de lecture et d'écriture provenant de clients utilisant des connexions chiffrées échouent et renvoient un message d'erreur, tel que "x509: certificate is valid for master-instance, not failover-instance." (x509 : Le certificat est valide pour l'instance maître mais pas pour l'instance de basculement).

Une fois l'événement terminé, Cloud SQL réinitialise la connexion. Effectuer une nouvelle tentative de connexion. Nous vous recommandons de concevoir vos applications de façon à pouvoir gérer les échecs de connexion occasionnels, en appliquant des règles de gestion des erreurs telles que l'intervalle exponentiel entre les tentatives. Pour en savoir plus, reportez-vous à la section Mise en œuvre des applications.

Outils pour le débogage de la connectivité

Les outils les plus élémentaires sont ping et traceroute.

Ping

La commande Ping effectue un test de base pour déterminer si la destination ("instance Cloud SQL") est disponible depuis la source. Ping envoie un paquet ICMP Echo Request à une instance Cloud SQL et s'attend à recevoir un ICMP Echo Reply en retour. Si ping échoue, il n'y a pas de route entre la source et la destination. Si elle réussit, cela ne signifie pas pour autant que vos paquets peuvent transiter, mais que, de manière générale, l'instance Cloud SQL est accessible.

Si ping peut déterminer si un hôte est actif et en état de répondre, la fiabilité de ce dernier n'est pas garantie. Certains fournisseurs de réseau bloquent ICMP par mesure de sécurité, ce qui peut compliquer le débogage de la connectivité.

Traceroute

La commande Traceroute teste la route complète suivie par les paquets réseau d'un hôte à un autre. Elle montre l'ensemble des étapes ("sauts") parcourues par le paquet tout au long de son acheminement, ainsi que le temps nécessaire à chaque étape. Si le paquet ne parvient pas à destination, traceroute ne se termine pas, mais indique en sortie une série d'astérisques. Dans ce cas, identifiez la dernière adresse IP atteinte avec succès dans l'acheminement. C'est là que la connectivité s'est interrompue.

La commande Traceroute peut expirer. Elle peut également échouer si une passerelle située le long du trajet n'est pas correctement configurée pour transmettre le paquet au saut suivant.

Lorsque traceroute échoue, vous pouvez éventuellement savoir où elle s'est arrêtée. Recherchez la dernière adresse IP indiquée par la sortie de traceroute et faites une recherche sur who owns [IP_ADDRESS] dans un navigateur. Les résultats peuvent afficher ou non le propriétaire de l'adresse, mais cela vaut la peine d'essayer.

mtr

L'outil mtr est une variante de traceroute qui reste active et mise à jour en continu, de la même manière que la commande top pour le suivi des processus locaux.

tcpdump

tcpdump est un outil permettant de capturer des paquets. Nous vous recommandons vivement d'exécuter tcpdump pour capturer et inspecter les paquets entre votre hôte et les instances Cloud SQL lorsque vous déboguez les problèmes de connectivité.

Localiser votre adresse IP locale

Si vous ne connaissez pas l'adresse locale de votre hôte, exécutez la commande ip -br address show. Sous Linux, cette commande affiche l'interface réseau, l'état de l'interface, l'adresse IP locale et les adresses MAC. Exemple : eth0 UP 10.128.0.7/32 fe80::4001:aff:fe80:7/64.

Vous pouvez également exécuter ipconfig ou ifconfig pour afficher l'état de vos interfaces réseau.

Effectuer des tests avec le module Tests de connectivité

Le module Tests de connectivité se présente comme un outil de diagnostic qui vous permet de vérifier la connectivité entre les points de terminaison de votre réseau. Il analyse votre configuration et, dans certains cas, procède à la vérification de l'exécution. Il est désormais compatible avec Cloud SQL. Suivez ces instructions pour exécuter des tests avec vos instances Cloud SQL.

Tester la connexion

Le client mysql permet de tester votre capacité à vous connecter depuis votre environnement local. Pour en savoir plus, consultez les pages Connecter le client mysql à l'aide d'adresses IP et Connecter le client mysql à l'aide du proxy d'authentification Cloud SQL.

Déterminer l'adresse IP de votre application

Pour déterminer l'adresse IP d'un ordinateur exécutant votre application et autoriser l'accès à votre instance Cloud SQL à partir de cette adresse, utilisez l'une des options suivantes :

  • Si l'ordinateur n'est pas situé derrière un proxy ou un pare-feu, vous devez vous y connecter et utiliser ce lien pour identifier son adresse IP.
  • Si l'ordinateur est situé derrière un proxy ou un pare-feu, vous devez vous y connecter, et utiliser un outil ou un service (tel que whatismyipaddress.com) pour identifier son adresse IP réelle.

Ports locaux ouverts

Pour vérifier que votre hôte écoute bien sur les ports que vous pensez, exécutez la commande ss -tunlp4. Cela vous indique quels ports sont ouverts et à l'écoute. Par exemple, si une base de données MySQL est en cours d'exécution, le port 3306 doit être opérationnel et à l'écoute. Pour SSH, vous devriez voir apparaître le port 22.

Ensemble de l'activité sur les ports locaux

Exécutez la commande netstat pour afficher l'ensemble de l'activité des ports locaux. Par exemple, netstat -lt affiche tous les ports actuellement actifs.

Se connecter à l'instance Cloud SQL à l'aide de SSL

Pour vérifier que vous pouvez vous connecter à votre instance Cloud SQL à l'aide de TCP, exécutez la commande telnet. Telnet tente de se connecter à l'adresse IP et au port que vous lui indiquez.

Si votre instance Cloud SQL exécute une base de données MySQL, par exemple, vous devriez pouvoir vous y connecter par telnet via le port 3306 : telnet 35.193.198.159 3306.

En cas de réussite, les éléments suivants s'affichent :

Trying 35.193.198.159...

Connected to 35.193.198.159. .

En cas d'échec, telnet s'interrompt jusqu'à ce que vous forciez sa fermeture :

Trying 35.193.198.159...

^C. .

Cloud Logging

Cloud SQL et Cloud SQL utilisent Cloud Logging. Consultez la documentation de Cloud Logging pour obtenir des informations complètes et accéder à des exemples de requêtes Cloud SQL.

Afficher les journaux

Vous pouvez afficher les journaux des instances Cloud SQL et d'autres projets Google Cloud tels que des instances Cloud VPN ou Compute Engine. Pour afficher les journaux correspondant aux entrées de journal de votre instance Cloud SQL, procédez comme suit :

Console

  1. Dans Google Cloud Console, accédez à la page Cloud Logging.

    Accéder à Cloud Logging

  2. Sélectionnez un projet Cloud SQL existant en haut de la page.
  3. Dans le générateur de requêtes, ajoutez les éléments suivants :
    • Ressource : sélectionnez Base de données Cloud SQL. Dans la boîte de dialogue, sélectionnez une instance Cloud SQL.
    • Noms des journaux : faites défiler la page jusqu'à la section Cloud SQL et sélectionnez les fichiers journaux correspondant à votre instance. Par exemple :
      • cloudsql.googlapis.com/mysql-general.log
      • cloudsql.googleapis.com/mysql.err
    • Gravité : sélectionnez un niveau de journalisation.
    • Période : sélectionnez une valeur prédéfinie ou créez une période personnalisée.

gcloud

Exécutez la commande gcloud logging pour afficher les entrées de journal. Dans l'exemple ci-dessous, remplacez PROJECT_ID. L'option limit est un paramètre facultatif qui indique le nombre maximal d'entrées à renvoyer.

gcloud logging read "projects/PROJECT_ID/logs/cloudsql.googleapis.com/mysql-general.log" \
--limit=10

Adresses IP privées

Les connexions à une instance Cloud SQL à l'aide d'une adresse IP privée sont automatiquement autorisées pour les plages d'adresses RFC 1918. Les plages d'adresses non-RFC 1918 doivent être configurées dans Cloud SQL en tant que réseaux autorisés. Vous devez mettre à jour l'appairage de réseaux vers Cloud SQL pour exporter les routes non-RFC 1918. Exemple :

gcloud compute networks peerings update cloudsql-mysql-googleapis-com 
--network=NETWORK
--export-subnet-routes-with-public-ip
--project=PROJECT_ID

La plage d'adresses IP 172.17.0.0/16 est réservée au réseau de la liaison Docker. De même, les instances Cloud SQL créées avec une adresse IP de cette plage sont inaccessibles. Les connexions depuis n'importe quelle adresse IP de cette plage vers des instances Cloud SQL utilisant une adresse IP privée échouent.

Dépannage du VPN

Consultez la page Dépannage de Cloud VPN.