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
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 Gremlinconsultate 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'Driveroggetto 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.
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 conneptune-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.
