Les fonctions Function Compute qui accèdent à des bases de données peuvent rencontrer deux types de défaillances : des échecs occasionnels ou des échecs systématiques. Cette rubrique détaille les causes les plus courantes et explique comment résoudre chacune d'elles.
Échecs de connexion intermittents
Si les connexions à la base de données échouent occasionnellement, effectuez les vérifications suivantes dans l'ordre indiqué.
1. Utilisez destroy() plutôt que end() pour fermer les connexions.
Les instances de fonction sont automatiquement recyclées après 2 à 5 minutes d'inactivité. La méthode end() attend que le serveur MySQL accuse réception du résultat d'une requête avant de fermer la connexion. Ce comportement peut laisser la connexion dans un état incohérent et provoquer l'expiration du délai de la prochaine invocation. Appelez destroy() pour forcer la fermeture immédiate de la connexion.
2. Remplacez votre groupe de sécurité par une liste d'autorisation d'adresses IP si vous accédez à la base de données via un Virtual Private Cloud (VPC).
Un groupe de sécurité côté base de données peut rendre les connexions instables lorsqu'elles proviennent de Function Compute. Privilégiez une liste d'autorisation d'adresses IP pour autoriser le trafic de manière fiable.
3. Si les échecs persistent, suivez les étapes décrites dans la section Échec constant de la connexion à la base de données.
Échec constant de la connexion à la base de données
Si chaque tentative de connexion échoue, procédez aux vérifications suivantes dans l'ordre.
-
Examinez les journaux de connexion de la base de données correspondant à la période où les échecs se sont produits.
Aucune demande de connexion provenant de Function Compute n'est détectée → passez à l'étape 2.
Des demandes de connexion provenant de Function Compute sont présentes → passez à l'étape 4.
-
Vérifiez le nom d'utilisateur et le mot de passe.
Les identifiants sont corrects → passez à l'étape 3.
Les identifiants sont incorrects → corrigez-les et réessayez.
-
Testez la connectivité réseau avec telnet depuis une instance Function Compute. Exécutez la commande suivante en remplaçant
<DB_HOST>et<DB_PORT>par l'endpoint et le port de votre base de données :La connexion réussit → passez à l'étape 4.
La connexion échoue → suivez les étapes décrites dans Résoudre les problèmes réseau.
telnet <DB_HOST> <DB_PORT> -
Analysez la logique du code de votre fonction pour détecter d'éventuels bugs dans la gestion des connexions.
Si le problème persiste après avoir suivi toutes ces étapes, rejoignez le groupe d'utilisateurs DingTalk 11721331 pour obtenir une assistance technique.
Résoudre les problèmes réseau
Accès VPC
Assurez-vous que l'instance de base de données et la fonction se trouvent dans la même région.
En cas d'erreur
AccessDenied(code d'erreur 403), vérifiez que votre fonction dispose des permissions nécessaires sur l'interface réseau élastique (ENI).Face à une erreur
InvalidArgument(code d'erreur 400), validez les configurations du VPC, du vSwitch et du Security Group.Si une liste d'autorisation d'adresses IP est configurée sur la base de données, incluez-y le bloc CIDR privé du VPC ainsi que celui du vSwitch. Pour autoriser le trafic depuis toutes les adresses IP, ajoutez
0.0.0.0/0.Confirmez que le groupe de sécurité autorise le trafic sortant vers l'adresse IP privée et le port de la base de données.
Lorsqu'une erreur
ResourceExhausted(code d'erreur 429) apparaît, cela signifie que le vSwitch n'a plus d'adresses IP disponibles. Le bloc CIDR par défaut possède un préfixe de longueur/24, offrant 252 adresses utilisables. Si votre fonction dépasse cette limite lors de sa mise à l'échelle, étendez manuellement le bloc CIDR du vSwitch et mettez à jour le groupe de sécurité en conséquence.
Accès Internet
Activez l'accès Internet pour votre service. Pour plus de détails, consultez Configurer les paramètres réseau.
Si la base de données utilise une liste d'autorisation d'adresses IP statiques, configurez une adresse IP publique statique pour votre fonction. Function Compute alloue les adresses IP de manière dynamique ; sans adresse IP statique, votre fonction ne peut pas passer la vérification de la liste d'autorisation. Pour plus de détails, consultez Configurer des adresses IP publiques statiques.
Problèmes réseau côté base de données
Pour déterminer si le problème provient de la base de données, reproduisez un environnement réseau similaire dans un autre service et lancez un test telnet :
telnet <DB_HOST> <DB_PORT>Une connexion réussie indique que le réseau côté base de données fonctionne normalement.