Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Gestione el reemplazo del host y el bloqueo de la conexión
Cuando Neptune reemplaza un host (por ejemplo, durante el mantenimiento o la conmutación por error), las conexiones existentes a ese host dejan de ser válidas. En entornos contenerizados, esto puede detener todos los subprocesos de un contenedor si el cliente no gestiona el reemplazo correctamente.
Utilice las versiones actuales del cliente
Si utiliza el lenguaje de consulta Gremlin, utilice una versión TinkerPop del controlador que sea compatible con la versión del motor Neptune (consulte la tabla Acceso al gráfico de Neptune con Gremlin de compatibilidad). Si utilizas el controlador de Java, considera neptune-gremlin-client la posibilidad de utilizar un paquete alrededor del controlador de TinkerPop Java que añada funciones de administración de conexiones, como la comprobación del estado de los terminales y la gestión de las conmutaciones por error. Sigue las mismas reglas de compatibilidad de versiones que el controlador subyacente TinkerPop .
Usa neptune-gremlin-client la versión 3.x (o, como mínimo, la versión 2.0.7), según lo que permita tu versión de Neptune. Estas versiones más recientes mejoran la resiliencia y el manejo de las conexiones.
Los usuarios de OpenCypher que utilicen el controlador Neo4j deben cerrar y volver a crear el Driver objeto cuando detecten un fallo de conexión durante la conmutación por error. Neptune es compatible con las versiones 1 a 4.0 del protocolo Bolt. Para obtener más información, consulte Prácticas recomendadas de Neptune con openCypher y Bolt.
Utilice puntos finales de clúster o lector
No te conectes directamente a los puntos finales de la instancia. Usa el punto final del clúster para las escrituras y el punto final del lector para las lecturas. Si debe usar los puntos de enlace de la instancia conneptune-gremlin-client, habilite el filtrado de verificación del estado de los puntos finales a través de la /status API.
Configure las sondas de vivacidad con tolerancia
Configure su sonda de actividad de Kubernetes en failureThreshold al menos 30 durante un período de 10 segundos (300 segundos en total). Esto evita que Kubernetes reinicie los pods durante el período de aproximadamente 5 minutos en el que Neptune completa un reemplazo de host.
Implemente el reintento con retraso
Una sola solicitud fallida durante la sustitución del host no debería bloquear el contenedor. Implemente una lógica de reintento con un retraso exponencial en caso de fallos de conexión, de modo que los errores transitorios durante la sustitución se resuelvan sin intervención. Para obtener información sobre las excepciones que se pueden volver a intentar, consulta Excepciones de transacciones de Neptune.
