Les opérations de maintenance (mises à niveau de spécifications, basculements, mises à jour mineures) et les incidents imprévus, tels que les défaillances du nœud principal, peuvent interrompre la connexion entre votre application et PolarDB. Sans connexions persistantes, votre application doit détecter cette déconnexion et se reconnecter, ce qui interrompt le service ou impose l'ajout d'une logique de reconnexion dans votre code. Lorsque les connexions persistantes sont activées, PolarProxy maintient la connexion frontale active pendant ces événements et restaure l'état de session de manière transparente, évitant ainsi toute interruption pour votre application.
Configurations prises en charge
Les connexions persistantes requièrent les éléments suivants :
PolarProxy version 2.4.7 ou ultérieure. Pour vérifier votre version et procéder à la mise à niveau, consultez Mise à niveau de version mineure.
PolarDB for MySQL 5.6, 5.7 ou 8.0 (Cluster Edition).
Un type d'endpoint pris en charge (voir le tableau ci-dessous).
Types d'endpoints pris en charge :
| Type d'endpoint | Politique d'équilibrage de charge | Prise en charge des connexions persistantes |
|---|---|---|
| Endpoint de cluster par défaut | Toutes | Oui |
| Endpoint personnalisé | Équilibrage de charge basé sur les requêtes actives | Oui |
| Endpoint personnalisé | Équilibrage de charge basé sur les connexions | Non — la suppression d'un nœud déconnecte toutes les connexions associées |
| Connexion directe à un nœud en lecture seule | N/A | Non — toujours déconnectée lors de la suppression du nœud |
Fonctionnement
Basculement du nœud principal
Chaque session de base de données comporte deux niveaux :
Une connexion frontale entre votre application et PolarProxy
Une connexion dorsale entre PolarProxy et le nœud principal ou en lecture seule
Sans connexions persistantes, un basculement du nœud principal rompt ces deux niveaux et oblige votre application à se reconnecter. Avec les connexions persistantes activées, PolarProxy maintient la connexion frontale active tout en se déconnectant de l'ancien nœud principal, en se connectant au nouveau nœud principal et en restaurant l'état de la session. Ce basculement est transparent pour votre application.
Restauration de l'état de session
Une session MySQL transporte un état qui doit survivre au basculement : variables système, variables utilisateur, tables temporaires, encodage du jeu de caractères, statut des transactions et statut des instructions préparées. Lorsque PolarProxy se connecte au nouveau nœud principal, il rejoue cet état afin que les paramètres de session de votre application restent inchangés.
Par exemple, après l'exécution de set names utf8;, la session se trouve dans un état names=utf8. PolarProxy restaure cet encodage sur le nouveau nœud principal, ce qui évite toute erreur liée au jeu de caractères.
Délais lors d'un basculement
Lorsque le nouveau nœud principal prend le relais, les bases de données d'origine et nouvelle sont temporairement inaccessibles. La durée de cette indisponibilité dépend de la charge de la base de données.
Si le nouveau nœud principal récupère dans un délai de 60 secondes, PolarProxy y achemine les requêtes et la session se poursuit.
Si le nouveau nœud principal ne récupère pas dans les 60 secondes, PolarProxy ferme la connexion. Votre application doit alors se reconnecter. Ce comportement s'applique indépendamment de l'activation des connexions persistantes.
Suppression d'un nœud en lecture seule
Dès réception d'une demande de suppression pour un nœud en lecture seule, PolarProxy redirige immédiatement toutes les nouvelles connexions et requêtes inactives loin de ce nœud.
Si une requête est déjà en cours d'exécution sur le nœud supprimé, PolarProxy attend sa fin pendant 60 secondes maximum. Si la requête se termine dans ce délai, la connexion reste active. En revanche, si la requête est toujours en cours après 60 secondes, la connexion est fermée.
La suppression d'un nœud en lecture seule depuis un endpoint utilisant la politique Connections-based load balancing déconnecte toutes les connexions sur ce nœud, y compris les connexions directes.
Limitations
Les connexions persistantes ne peuvent pas maintenir une session active dans les situations suivantes :
| Situation | Description |
|---|---|
| Tables temporaires actives | La session contient des tables temporaires au moment du basculement. |
| Livraison partielle des résultats | Le résultat d'une requête n'est que partiellement transmis à PolarProxy lors du basculement. Par exemple, une instruction SELECT retourne 100 Mo, mais seuls 10 Mo ont été reçus lorsque le basculement se déclenche. |
| Transactions en cours | Une transaction active existe au début du basculement, par exemple begin; insert into .... |
Utilisation d'un curseur ou de stmt_send_long_data |
Le curseur ou la méthode stmt_send_long_data est en cours d'utilisation et la requête n'est pas terminée au début du basculement. |
Lorsqu'un basculement ou une suppression de nœud commence, PolarProxy attend jusqu'à 60 secondes que les connexions actives deviennent inactives, c'est-à-dire que toutes les requêtes aient reçu une réponse ou que la transaction soit terminée. Les connexions qui deviennent inactives dans ce délai restent actives.
Tests de performance
Les résultats suivants indiquent le pourcentage de connexions maintenues actives selon différents scénarios de maintenance.
Environnement de test :
| Paramètre | Valeur |
|---|---|
| Cluster | PolarDB for MySQL 8.0, un nœud principal et deux nœuds en lecture seule |
| Spécification du nœud | 4 cœurs, 16 Go (polar.mysql.x4.large) |
| Outil de test | Sysbench |
| Données de test | 20 tables, 10 000 lignes par table, degré de parallélisme de 20 |
Procédure : Mesurez le taux de maintien des connexions avant et après chaque opération de maintenance.
Résultats :
| Scénario | Taux de maintien | Conditions |
|---|---|---|
| Basculement vers un nouveau nœud principal | 100 % | |
| Mise à niveau de la version mineure du moteur de base de données | 100 % | Ne couvre pas les mises à niveau de version mineure du proxy de base de données ; ces mises à niveau peuvent entraîner des interruptions réseau. |
| Mise à niveau des spécifications du cluster | 100 % | S'applique uniquement aux mises à niveau progressives (par exemple, de 4 cœurs à 8 cœurs). Le fait de sauter des niveaux, comme passer de 4 cœurs à 16 cœurs ou plus, peut provoquer une interruption de service. |
| Ajout ou suppression de nœuds | 100 % | Si le nœud proxy de base de données est rétrogradé lors de la suppression d'un nœud en lecture seule, certaines connexions peuvent être fermées. |