Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

# Gestisci la sostituzione dell'host e lo stallo della connessione
<a name="best-practices-ecs-eks-host-replacement"></a>

Quando Neptune sostituisce un host (ad esempio, durante la manutenzione o il failover), le connessioni esistenti a quell'host non sono più valide. Negli ambienti containerizzati, ciò può bloccare tutti i thread in un contenitore se il client non gestisce correttamente la sostituzione.

**Usa le versioni client correnti**

Se utilizzate il linguaggio di interrogazione Gremlin, utilizzate una versione del TinkerPop driver compatibile con la versione del motore Neptune in uso ([Accesso al grafo Neptune con Gremlin](access-graph-gremlin.md)consultate la tabella di compatibilità). Se utilizzate il driver Java, prendete in considerazione `neptune-gremlin-client` una soluzione alternativa al driver TinkerPop Java che aggiunga funzionalità di gestione delle connessioni come il controllo dello stato degli endpoint e la gestione del failover. Segue le stesse regole di compatibilità delle versioni del driver sottostante. TinkerPop 

Usa `neptune-gremlin-client` la versione 3.x (o almeno la versione 2.0.7), a seconda di ciò che consente la versione di Neptune. Queste versioni più recenti migliorano la resilienza e la gestione delle connessioni.

Per gli utenti di OpenCypher con il driver Neo4j, chiudete e ricreate l'`Driver`oggetto quando rilevate un errore di connessione durante il failover. Neptune supporta le versioni del protocollo Bolt da 1 a 4.0. Per ulteriori informazioni, consulta [Best practice di Neptune per l'utilizzo di openCypher e Bolt](best-practices-opencypher.md).

**Utilizza gli endpoint del cluster o del lettore**

Non connetterti direttamente agli endpoint dell'istanza. Usa l'endpoint del cluster per le scritture e l'endpoint reader per le letture. Se devi utilizzare gli endpoint dell'istanza con`neptune-gremlin-client`, abilita il filtraggio dell'endpoint health-check tramite l'API. `/status`

**Configura le sonde di vivacità con tolleranza**

Imposta la tua sonda di liveness Kubernetes su almeno 30 con un periodo `failureThreshold` di 10 secondi (300 secondi in totale). Ciò impedisce a Kubernetes di riavviare i pod durante la finestra di circa 5 minuti in cui Neptune sta completando la sostituzione dell'host.

**Implementa un nuovo tentativo con backoff**

Una singola richiesta non riuscita durante la sostituzione dell'host non dovrebbe causare l'arresto anomalo del contenitore. Implementa la logica di ripetizione con backoff esponenziale in caso di errori di connessione in modo che gli errori transitori durante la sostituzione si risolvano senza alcun intervento. [Per indicazioni sulle eccezioni riprovabili, consulta le eccezioni delle transazioni di Neptune.](https://docs.aws.amazon.com/neptune/latest/userguide/transactions-exceptions.html)