Gérer le remplacement de l'hôte et le blocage de la connexion

Lorsque Neptune remplace un hôte (par exemple, lors d'une maintenance ou d'un basculement), les connexions existantes à cet hôte ne sont plus valides. Dans les environnements conteneurisés, cela peut bloquer tous les threads d'un conteneur si le client ne gère pas le remplacement correctement.

Utiliser les versions actuelles du client

Si vous utilisez le langage de requête Gremlin, utilisez une version TinkerPop du pilote compatible avec la version de votre moteur Neptune (Accès au graphe Neptune avec Gremlinvoir le tableau de compatibilité). Si vous utilisez le pilote Java, envisagez neptune-gremlin-client d'ajouter une enveloppe au pilote TinkerPop Java qui ajoute des fonctionnalités de gestion des connexions, telles que la vérification de l'état des terminaux et la gestion du basculement. Il suit les mêmes règles de compatibilité de version que le TinkerPop pilote sous-jacent.

Utilisez neptune-gremlin-client la version 3.x (ou au minimum la version 2.0.7), selon ce que votre version de Neptune autorise. Ces nouvelles versions améliorent la résilience et la gestion des connexions.

Pour les utilisateurs d'OpenCypher dotés du pilote Neo4j, fermez et recréez l'Driverobjet lorsque vous détectez un échec de connexion lors du basculement. Neptune prend en charge les versions 1 à 4.0 du protocole Bolt. Pour de plus amples informations, veuillez consulter Bonnes pratiques Neptune avec openCypher et Bolt.

Utiliser les points de terminaison du cluster ou du lecteur

Ne vous connectez pas directement aux points de terminaison de l'instance. Utilisez le point de terminaison du cluster pour les écritures et le point de terminaison du lecteur pour les lectures. Si vous devez utiliser des points de terminaison d'instance avecneptune-gremlin-client, activez le filtrage de vérification de l'état des points de terminaison via l'/statusAPI.

Configuration des sondes de vivacité avec tolérance

Réglez votre sonde de vivacité Kubernetes sur failureThreshold au moins 30 avec une période de 10 secondes (300 secondes au total). Cela empêche Kubernetes de redémarrer les pods pendant la période d'environ 5 minutes pendant laquelle Neptune effectue le remplacement d'un hôte.

Implémenter une nouvelle tentative avec backoff

Une seule demande échouée lors du remplacement de l'hôte ne devrait pas faire planter le conteneur. Implémentez une logique de nouvelle tentative avec un retard exponentiel en cas de défaillance de connexion afin que les erreurs transitoires lors du remplacement soient résolues sans intervention. Pour obtenir des conseils sur les exceptions réessayables, consultez la section Exceptions relatives aux transactions Neptune.