Gestion des erreurs de connectivité temporaires dans un serveur flexible Azure Database pour PostgreSQL

S’APPLIQUE À : Azure Database pour PostgreSQL – Serveur flexible

Cet article explique comment gérer les erreurs de connectivité temporaires sur un serveur flexible Azure Database pour PostgreSQL.

Erreurs temporaires

Une erreur temporaire, également appelée erreur temporaire, est une erreur qui se résout elle-même. Le plus souvent, ces erreurs se manifestent sous forme de rupture de la connexion au serveur de base de données. De plus, aucune nouvelle connexion à un serveur ne peut être ouverte. Des erreurs temporaires peuvent se produire, par exemple, lorsque des défaillances matérielles ou réseau se produisent. Une autre raison peut être une nouvelle version d’un service PaaS en cours de déploiement. Le système atténue automatiquement la plupart de ces événements en moins de 60 secondes. En matière de conception et de développement d’applications dans le cloud, il convient de s’attendre à des erreurs temporaires. Partez du principe qu’elles peuvent se produire dans n’importe quel composant à n’importe quel moment, et qu’il existe une logique appropriée pour faire face à ces situations.

Gestion des erreurs temporaires

Les erreurs temporaires doivent être gérées à l’aide d’une logique de nouvelle tentative. Situations qui doivent être prises en compte :

• Une erreur se produit lorsque vous essayez d’ouvrir une connexion
• Une connexion inactive est supprimée côté serveur. Lorsque vous essayez d’émettre une commande, elle ne peut pas s’exécuter.
• Une connexion active qui exécute actuellement une commande est supprimée.

Le premier et le deuxième cas sont assez simples à gérer. Essayez d’ouvrir à nouveau la connexion. Une fois que le système atténue l’erreur temporaire, vous réussissez à vous connecter. Vous pouvez réutiliser votre instance de serveur flexible Azure Database pour PostgreSQL. Nous vous recommandons d’attendre avant de réessayer la connexion. Abandonnez si les tentatives initiales échouent. Ainsi, le système peut utiliser toutes les ressources disponibles pour résoudre la situation d’erreur. Nous vous recommandons de procéder comme suit :

• Patientez cinq secondes avant votre première nouvelle tentative.
• Pour chaque tentative suivante, augmentez l’attente de façon exponentielle, jusqu’à 60 secondes.
• Définissez un nombre maximal de tentatives au-delà duquel votre application considère que l’opération a échoué.

Lorsqu’une connexion avec une transaction active échoue, il est plus difficile de gérer correctement la récupération. Il existe deux cas : si la transaction était en lecture seule, il est sûr de rouvrir la connexion et de réessayer la transaction. Toutefois, si la transaction a également été écrite dans la base de données, vous devez déterminer si la transaction a été annulée ou si elle a réussi avant que l’erreur temporaire se produise. Dans ce cas, vous n’avez peut-être pas reçu l’accusé de réception de validation du serveur de base de données.

Une façon d’y remédier est de générer un identifiant unique sur le client qui est utilisé pour toutes les tentatives. Vous transmettez cet ID unique dans le cadre de la transaction au serveur, et vous le stockez dans une colonne avec une contrainte unique. Ainsi, vous pouvez retenter la transaction en toute sécurité. Elle réussit si la transaction précédente a été restaurée et que l’ID unique généré par le client n’existe pas encore dans le système. Elle échoue, indiquant une violation de clé en double si l’ID unique a été précédemment stocké, car la transaction précédente s’est terminée avec succès.

Si votre programme communique avec le serveur flexible Azure Database pour PostgreSQL au moyen d’un intergiciel tiers, demandez au fournisseur si l’intergiciel contient une logique de nouvelle tentative pour les erreurs temporaires.

Veillez à tester votre logique de nouvelle tentative. Par exemple, essayez d’exécuter votre code tout en effectuant un scale up/down des ressources de calcul de votre instance de serveur flexible Azure Database pour PostgreSQL. Votre application doit être en mesure de gérer la courte interruption qui survient au cours de cette opération sans le moindre problème.