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à.
# Motore Amazon Neptune versione 1.1.1.0 (19/04/2022)
A partire dal 19 aprile 2022, viene implementata a livello generale la versione del motore 1.1.1.0. Tieni presente che occorrono diversi giorni prima che una nuova versione diventi disponibile in ogni regione.
**Importante**
**L'aggiornamento a questo rilascio del motore da una versione precedente alla `1.1.0.0` attiva anche un aggiornamento del sistema operativo su tutte le istanze del cluster database. Poiché le richieste di scrittura attive che si verificano durante l'aggiornamento del sistema operativo non vengono elaborate, è necessario sospendere tutti i carichi di lavoro in scrittura sul cluster da aggiornare, compresi i caricamenti di dati in blocco, prima di avviare l'aggiornamento.**
Per completare correttamente l'aggiornamento, ogni sottorete in ciascuna zona di disponibilità (AZ) deve avere almeno un indirizzo IP disponibile per ogni istanza di Neptune. Ad esempio, se ci sono un'istanza di scrittura e due istanze di lettura nella sottorete 1 e due istanze di lettura nella sottorete 2, la sottorete 1 deve avere almeno 3 indirizzi IP liberi e la sottorete 2 deve avere almeno 2 indirizzi IP liberi prima di avviare l'aggiornamento.
All'inizio dell'aggiornamento, Neptune genera uno snapshot con un nome composto da `preupgrade` seguito da un identificatore generato automaticamente in base alle informazioni del cluster database. Per lo snapshot non ti verrà addebitato alcun costo e potrai utilizzarlo per ripristinare il cluster database in caso di problemi durante il processo di aggiornamento.
La nuova versione del motore (una volta completato il relativo aggiornamento) rimane disponibile per un breve periodo di tempo sul vecchio sistema operativo, ma in meno di 5 minuti tutte le istanze del cluster avviano contemporaneamente un aggiornamento del sistema operativo. A questo punto, il cluster database non sarà disponibile per alcuni minuti. Puoi riprendere i carichi di lavoro in scrittura al termine dell'aggiornamento.
Questo processo genera i seguenti eventi:
Messaggi di evento per cluster:
`Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-(autogenerated snapshot ID)]`
`Database cluster major version has been upgraded`
Messaggi di evento per istanza:
`Applying off-line patches to DB instance`
`DB instance shutdown`
`Finished applying off-line patches to DB instance`
`DB instance restarted`
## Rilascio di patch successive per questa versione
+ [Rilascio di manutenzione: 1.1.1.0.R2 (16/05/2022)](engine-releases-1.1.1.0.R2.md)
+ [Rilascio: 1.1.1.0.R3 (07/06/2022)](engine-releases-1.1.1.0.R3.md)
+ [Rilascio: 1.1.1.0.R4 (23/06/2022)](engine-releases-1.1.1.0.R4.md)
+ [Rilascio: 1.1.1.0.R5 (21/07/2022)](engine-releases-1.1.1.0.R5.md)
+ [Rilascio: 1.1.1.0.R6 (23/09/2022)](engine-releases-1.1.1.0.R6.md)
+ [Rilascio: 1.1.1.0.R7 (23/01/2023)](engine-releases-1.1.1.0.R7.md)
## Nuove caratteristiche in questo rilascio del motore
+ Il [linguaggio di query openCypher](access-graph-opencypher.md) è ora disponibile a livello generale per l'uso in produzione.
**avvertimento**
In questo rilascio è presente una modifica radicale per il codice che usa openCypher con autenticazione IAM. Nell'anteprima di Neptune per openCypher, la stringa host nella firma IAM includeva il protocollo, come `bolt://`, ad esempio:
```
"Host":"bolt://(host URL):(port)"
```
A partire da questo rilascio del motore, il protocollo deve essere omesso:
```
"Host":"(host URL):(port)"
```
Per esempi, consulta [Utilizzo del protocollo Bolt](access-graph-opencypher-bolt.md).
+ È stato aggiunto il supporto per TinkerPop `3.5.2`. Tra le [modifiche inserite in questa versione](https://github.com/apache/tinkerpop/blob/3.5.2/CHANGELOG.asciidoc#release-3-5-2) vi sono la compatibilità con le transazioni remote e il supporto di bytecode per le sessioni (utilizzando [https://tinkerpop.apache.org/docs/current/reference/#transactions](https://tinkerpop.apache.org/docs/current/reference/#transactions)) e l'aggiunta della funzione `datetime()` al linguaggio Gremlin.
**avvertimento**
Sono state introdotte diverse modifiche importanti nelle TinkerPop versioni 3.5.0, 3.5.1 e 3.5.2 che potrebbero influire sul codice Gremlin. Ad esempio, [usare traversali generati da a as children come](https://issues.apache.org/jira/browse/TINKERPOP-2361) questo non funzionerà più:. GraphTraversalSource `g.V().union(identity(), g.V())`
Ora invece, viene utilizzato un attraversamento anonimo come questo: `g.V().union(identity(), __.V())`.
+ Aggiunto il supporto per le [chiavi di condizione globali AWS](iam-data-condition-keys.md#iam-data-global-condition-keys) da utilizzare nelle [policy di accesso ai dati IAM](iam-admin-policies.md) che controllano l'accesso ai dati archiviati in Neptune, un cluster database Neptune.
+ Il [motore di query Neptune DFE](neptune-dfe-engine.md) è ora disponibile a livello generale per l'uso in produzione con il linguaggio di query openCypher, ma non ancora per le query Gremlin e SPARQL. Adesso può essere abilitato utilizzando il relativo parametro di istanza [neptune\$1dfe\$1query\$1engine](parameters.md#parameters-instance-parameters-neptune_dfe_query_engine) anziché il parametro della modalità di laboratorio.
## Miglioramenti in questo rilascio del motore
+ Sono state aggiunte nuove funzionalità a [openCypher](access-graph-opencypher.md), come il supporto per le query parametrizzate, la memorizzazione nella cache dell'albero sintattico astratto (AST) per le query parametrizzate, miglioramenti del percorso a lunghezza variabile (VLP), oltre a nuovi operatori e clausole. Per scoprire il livello attuale di supporto linguistico, consulta [Conformità alle specifiche OpenCypher in Amazon Neptune](feature-opencypher-compliance.md).
+ Sono stati apportati miglioramenti significativi alle prestazioni di openCypher per semplici carichi di lavoro in lettura e scrittura, con conseguente aumento della velocità di trasmissione effettiva rispetto al rilascio 1.1.0.0.
+ Sono state rimosse le limitazioni bidirezionali e di profondità di openCypher per la gestione dei percorsi a lunghezza variabile.
+ È stato completato il supporto nel motore DFE per i predicati `within` e `without` di Gremlin, inclusi i casi in cui vengono combinati con altri operatori di predicati. Per esempio:
```
g.V().has('age', within(12, 15, 18).or(gt(30)))
```
+ È stato esteso il supporto nel motore DFE per la fase `order` di Gremlin quando l'ambito è globale (ovvero non `order(local)`) e quando i modulatori `by()` non vengono utilizzati. Ad esempio, questa query ora avrebbe il supporto DFE:
```
g.V().values("age").order()
```
+ È stato aggiunto un campo `isLastOp` al formato di risposta del [log delle modifiche apportate ai flussi Neptune](streams-using-api-reponse.md), per indicare che un record è l'ultima operazione della relativa transazione.
+ Sono state significativamente migliorate le prestazioni della registrazione di log di audit ed è stata ridotta la latenza quando la registrazione di log di audit è abilitata.
+ Ha convertito il WebSocket bytecode e le query HTTP di Gremlin in un formato leggibile dall'utente nei registri di controllo. Le query possono ora essere copiate direttamente dai log di audit per essere eseguite nei notebook Neptune e altrove. Nota: questa modifica all'attuale formato dei log di audit rappresenta un cambiamento radicale.
## Difetti corretti in questo rilascio del motore
+ È stato corretto un raro bug di Gremlin per cui non veniva restituito alcun risultato quando si utilizzavano in combinazione fasi `filter()` e `count()` annidate, come nella seguente query:
```
g.V("1").filter(out("knows")
.filter(in("knows")
.hasId("notExists"))
.count())
```
+ È stato corretto un bug di Gremlin in cui veniva restituito un errore quando si utilizzava un vertice archiviato tramite una fase di aggregazione negli attraversamenti `to()` o `from()` congiuntamente a una fase `addE`. Un esempio di query di questo tipo è:
```
g.V("id").aggregate("v").out().addE().to(select("v").unfold()))
```
+ È stato corretto un bug di Gremlin a causa del quale la fase `not` dava esito negativo nei casi limite in cui si utilizzava il motore DFE. Per esempio:
```
g.V().not(V())
```
+ È stato corretto un bug di Gremlin a causa del quale i valori `sideEffect` non erano disponibili all'interno degli attraversamenti `to()` e `from()`.
+ È stato corretto un bug che occasionalmente causava un ripristino rapido per innescare un failover dell'istanza.
+ È stato corretto un bug dello strumento di caricamento in blocco a causa del quale una transazione non riuscita non veniva chiusa prima dell'inizio del successivo processo di caricamento.
+ È stato corretto un bug dello strumento di caricamento in blocco a causa del quale una condizione di memoria insufficiente poteva causare un arresto anomalo del sistema.
+ È stato aggiunto un nuovo tentativo per correggere un bug dello strumento di caricamento in blocco a causa del quale tale strumento non aspettava abbastanza a lungo prima che le credenziali IAM diventassero disponibili dopo un failover.
+ È stato corretto un bug a causa del quale la cache interna delle credenziali non veniva cancellata correttamente per gli endpoint non sottoposti a query, come l'endpoint `status`.
+ È stato corretto un bug relativo ai flussi per garantire il corretto ordinamento dei numeri di sequenza del commit dei flussi.
+ È stato risolto un bug a causa del quale le connessioni a lunga durata venivano interrotte prima di dieci giorni nei cluster abilitati per IAM.
## Versioni di linguaggio di query supportate in questo rilascio
Prima di aggiornare un cluster database alla versione 1.1.1.0, assicurati che il tuo progetto sia compatibile con queste versioni di linguaggio di query:
+ *Versione meno recente di Gremlin supportata:* `3.5.2`
+ *Versione più recente di Gremlin supportata:* `3.5.4`
+ *Versione openCypher:* `Neptune-9.0.20190305-1.0`
+ *Versione di SPARQL:* `1.1`
## Percorsi di aggiornamento al rilascio del motore 1.1.1.0
È possibile aggiornare manualmente qualsiasi rilascio del motore Neptune precedente a questo rilascio. Nota: le versioni precedenti a quella principale del motore (1.1.0.0) impiegheranno più tempo per effettuare l'aggiornamento a questo rilascio.
L'aggiornamento a questo rilascio non viene eseguito automaticamente.
## Aggiornamento a questo rilascio
**Importante**
**L'aggiornamento a questo rilascio del motore da qualsiasi versione precedente alla `1.1.0.0` attiva anche un aggiornamento del sistema operativo su tutte le istanze del cluster database. Poiché le richieste di scrittura attive che si verificano durante l'aggiornamento del sistema operativo non vengono elaborate, è necessario sospendere tutti i carichi di lavoro in scrittura sul cluster da aggiornare, compresi i caricamenti di dati in blocco, prima di avviare l'aggiornamento.**
All'inizio dell'aggiornamento, Neptune genera uno snapshot con un nome composto da `preupgrade` seguito da un identificatore generato automaticamente in base alle informazioni del cluster database. Per lo snapshot non ti verrà addebitato alcun costo e potrai utilizzarlo per ripristinare il cluster database in caso di problemi durante il processo di aggiornamento.
La nuova versione del motore (una volta completato il relativo aggiornamento) rimane disponibile per un breve periodo di tempo sul vecchio sistema operativo, ma in meno di 5 minuti tutte le istanze del cluster avviano contemporaneamente un aggiornamento del sistema operativo. A questo punto, il cluster database non sarà disponibile per circa 6 minuti. Puoi riprendere i carichi di lavoro in scrittura al termine dell'aggiornamento.
Questo processo genera i seguenti eventi:
Messaggi di evento per cluster:
`Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-(autogenerated snapshot ID)]`
`Database cluster major version has been upgraded`
Messaggi di evento per istanza:
`Applying off-line patches to DB instance`
`DB instance shutdown`
`Finished applying off-line patches to DB instance`
`DB instance restarted`
Se un cluster database utilizza una versione del motore dalla quale esiste un percorso di aggiornamento a questo rilascio, ora è idoneo all'aggiornamento. È possibile aggiornare qualsiasi cluster idoneo utilizzando le operazioni del cluster database sulla console o utilizzando SDK. Il seguente comando CLI aggiornerà immediatamente un cluster idoneo:
Per Linux, OS X o Unix:
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine neptune \
4. --engine-version 1.1.1.0 \
5. --allow-major-version-upgrade \
6. --apply-immediately
```
Per Windows:
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine neptune ^
4. --engine-version 1.1.1.0 ^
5. --allow-major-version-upgrade ^
6. --apply-immediately
```
Invece di `--apply-immediately`, puoi specificare `--no-apply-immediately`. Per eseguire un aggiornamento della versione principale, il parametro è obbligatorio. allow-major-version-upgrade Assicurati inoltre di includere la versione del motore onde evitare che il tuo motore venga aggiornato a una versione diversa.
Se il cluster utilizza un gruppo di parametri del cluster personalizzato, assicurati di includere questo parametro per specificarlo:
```
--db-cluster-parameter-group-name (name of the custom DB cluster parameter group)
```
Analogamente, se alcune istanze del cluster utilizzano un gruppo di parametri del database personalizzato, assicurati di includere questo parametro per specificarlo:
```
--db-instance-parameter-group-name (name of the custom instance parameter group)
```
### Eseguire sempre un test prima dell'aggiornamento
Quando viene rilasciata una nuova versione principale o secondaria del motore Neptune, testa sempre le applicazioni Neptune su di essa prima di procedere all'aggiornamento. Anche un aggiornamento secondario potrebbe introdurre nuove funzionalità o comportamenti che possono influire sul codice.
Inizia confrontando le pagine delle note di rilascio della versione corrente con quelle della versione di destinazione per valutare se verranno modificate le versioni del linguaggio di query o verranno introdotte altre modifiche che causano interruzioni.
Il modo migliore per testare una nuova versione prima di aggiornare il cluster database di produzione è clonare il cluster di produzione affinché il clone esegua la nuova versione del motore. È quindi possibile eseguire query sul clone senza influire sul cluster database di produzione.
### Creare sempre uno snapshot manuale prima dell'aggiornamento
Prima di procedere a un aggiornamento, è consigliabile creare sempre uno snapshot manuale del cluster database. Uno snapshot automatico offre solo una protezione a breve termine, mentre uno snapshot manuale rimane disponibile fino a quando non lo elimini esplicitamente.
In alcuni casi Neptune crea automaticamente uno snapshot manuale come parte del processo di aggiornamento, ma non è consigliabile farvi affidamento ed è comunque opportuno creare sempre il proprio snapshot manuale.
Quando hai la certezza che non sarà necessario ripristinare lo stato precedente all'aggiornamento del cluster di database, puoi eliminare in modo esplicito lo snapshot manuale che hai creato, così come lo snapshot manuale eventualmente creato da Neptune. Se Neptune crea uno snapshot manuale, questo avrà un nome che inizia con `preupgrade`, seguito dal nome del cluster database, dalla versione del motore di origine, dalla versione del motore di destinazione e dalla data.
**Nota**
Se stai tentando di eseguire l'aggiornamento mentre [è in corso un'azione in sospeso](manage-console-maintaining), potrebbe verificarsi un errore come il seguente:
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Se riscontri questo errore, attendi il completamento dell'azione in sospeso o attiva immediatamente una finestra di manutenzione per completare l'aggiornamento precedente.
Per ulteriori informazioni sull'aggiornamento della versione del motore, consulta [Gestione del cluster di database Amazon Neptune](cluster-maintenance.md). In caso di domande o dubbi, il team di AWS supporto è disponibile nei forum della community e tramite [AWS Premium Support](https://aws.amazon.com/support).
# Motore Amazon Neptune versione 1.1.1.0.R7 (23/01/2023)
A partire dal 23 gennaio 2023, viene implementata a livello generale la versione del motore 1.1.1.0.R7. Tieni presente che occorrono diversi giorni prima che una nuova versione diventi disponibile in ogni regione.
**Importante**
**L'aggiornamento a questo rilascio del motore da una versione precedente alla `1.1.0.0` attiva anche un aggiornamento del sistema operativo su tutte le istanze del cluster database. Poiché le richieste di scrittura attive che si verificano durante l'aggiornamento del sistema operativo non vengono elaborate, è necessario sospendere tutti i carichi di lavoro in scrittura sul cluster da aggiornare, compresi i caricamenti di dati in blocco, prima di avviare l'aggiornamento.**
Per completare correttamente l'aggiornamento, ogni sottorete in ciascuna zona di disponibilità (AZ) deve avere almeno un indirizzo IP disponibile per ogni istanza di Neptune. Ad esempio, se ci sono un'istanza di scrittura e due istanze di lettura nella sottorete 1 e due istanze di lettura nella sottorete 2, la sottorete 1 deve avere almeno 3 indirizzi IP liberi e la sottorete 2 deve avere almeno 2 indirizzi IP liberi prima di avviare l'aggiornamento.
All'inizio dell'aggiornamento, Neptune genera uno snapshot con un nome composto da `preupgrade` seguito da un identificatore generato automaticamente in base alle informazioni del cluster database. Per lo snapshot non ti verrà addebitato alcun costo e potrai utilizzarlo per ripristinare il cluster database in caso di problemi durante il processo di aggiornamento.
La nuova versione del motore (una volta completato il relativo aggiornamento) rimane disponibile per un breve periodo di tempo sul vecchio sistema operativo, ma in meno di 5 minuti tutte le istanze del cluster avviano contemporaneamente un aggiornamento del sistema operativo. A questo punto, il cluster database non sarà disponibile per alcuni minuti. Puoi riprendere i carichi di lavoro in scrittura al termine dell'aggiornamento.
Questo processo genera i seguenti eventi:
Messaggi di evento per cluster:
`Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-(autogenerated snapshot ID)]`
`Database cluster major version has been upgraded`
Messaggi di evento per istanza:
`Applying off-line patches to DB instance`
`DB instance shutdown`
`Finished applying off-line patches to DB instance`
`DB instance restarted`
## Miglioramenti in questo rilascio del motore
+ Prestazioni migliorate delle query openCypher che riguardano `MERGE` e `OPTIONAL MATCH`.
+ Prestazioni migliorate delle query openCypher che riguardano `UNWIND` di un elenco di mappe di valori letterali.
+ Prestazioni migliorate delle query openCypher che dispongono di un filtro `IN` per `id`. Per esempio:
```
MATCH (n) WHERE id(n) IN ['1', '2', '3'] RETURN n
```
+ Miglioramenti delle prestazioni e correzioni della correttezza per vari operatori Gremlin, tra cui `repeat`, `coalesce`, `store` e `aggregate`.
## Difetti corretti in questo rilascio del motore
+ È stato corretto un bug di openCypher a causa del quale una richiesta che utilizzava HTTP keep-alive poteva essere chiusa erroneamente se inviata dopo una richiesta non riuscita.
+ È stato corretto un bug di openCypher a causa del quale il tipo di parametro non veniva sempre interpretato correttamente per un elenco o un elenco di mappe.
+ È stato corretto un bug di openCypher per cui le query restituivano la stringa `"null"` anziché un valore nullo in Bolt and SPARQL-JSON.
+ Sono stati corretti i codici di errore OpenCypher e i messaggi di errore per gli errori e gli errori di timeout delle query. out-of-memory
+ È stato corretto un bug di Gremlin che impediva l'ottimizzazione di `valueMap()` nel caso di un attraversamento `by()` nel motore DFE.
+ È stato risolto un problema relativo alla logica del rilevatore di deadlock che occasionalmente impediva al motore di rispondere.
+ È stato corretto un bug del log di audit che causava la registrazione di informazioni non necessarie e l'assenza di alcuni campi nei log.
## Versioni di linguaggio di query supportate in questo rilascio
Prima di aggiornare un cluster database alla versione 1.1.1.0.R7, assicurati che il tuo progetto sia compatibile con queste versioni di linguaggio di query:
+ *Versione meno recente di Gremlin supportata:* `3.5.2`
+ *Versione più recente di Gremlin supportata:* `3.5.3`
+ *Versione openCypher:* `Neptune-9.0.20190305-1.0`
+ *Versione di SPARQL:* `1.1`
## Percorsi di aggiornamento al rilascio del motore 1.1.1.0.R7
Se si esegue la versione del motore `1.1.1.0`, il cluster verrà aggiornato automaticamente a questo rilascio di patch durante la finestra di manutenzione successiva.
## Aggiornamento a questo rilascio
**Importante**
**L'aggiornamento a questo rilascio del motore da qualsiasi versione precedente alla `1.1.0.0` attiva anche un aggiornamento del sistema operativo su tutte le istanze del cluster database. Poiché le richieste di scrittura attive che si verificano durante l'aggiornamento del sistema operativo non vengono elaborate, è necessario sospendere tutti i carichi di lavoro in scrittura sul cluster da aggiornare, compresi i caricamenti di dati in blocco, prima di avviare l'aggiornamento.**
All'inizio dell'aggiornamento, Neptune genera uno snapshot con un nome composto da `preupgrade` seguito da un identificatore generato automaticamente in base alle informazioni del cluster database. Per lo snapshot non ti verrà addebitato alcun costo e potrai utilizzarlo per ripristinare il cluster database in caso di problemi durante il processo di aggiornamento.
La nuova versione del motore (una volta completato il relativo aggiornamento) rimane disponibile per un breve periodo di tempo sul vecchio sistema operativo, ma in meno di 5 minuti tutte le istanze del cluster avviano contemporaneamente un aggiornamento del sistema operativo. A questo punto, il cluster database non sarà disponibile per circa 6 minuti. Puoi riprendere i carichi di lavoro in scrittura al termine dell'aggiornamento.
Questo processo genera i seguenti eventi:
Messaggi di evento per cluster:
`Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-(autogenerated snapshot ID)]`
`Database cluster major version has been upgraded`
Messaggi di evento per istanza:
`Applying off-line patches to DB instance`
`DB instance shutdown`
`Finished applying off-line patches to DB instance`
`DB instance restarted`
Se un cluster database utilizza una versione del motore dalla quale esiste un percorso di aggiornamento a questo rilascio, ora è idoneo all'aggiornamento. È possibile aggiornare qualsiasi cluster idoneo utilizzando le operazioni del cluster database sulla console o utilizzando SDK. Il seguente comando CLI aggiornerà immediatamente un cluster idoneo:
Per Linux, OS X o Unix:
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.1.1.0 \
4. --apply-immediately
```
Per Windows:
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.1.1.0 ^
4. --apply-immediately
```
Gli aggiornamenti vengono applicati contemporaneamente a tutte le istanze in un cluster di database. Un aggiornamento richiede il riavvio del database su queste istanze, quindi si verificheranno tempi di inattività che vanno da 20-30 secondi a diversi minuti, dopodiché si potrà riprendere a usare il cluster database.
### Eseguire sempre un test prima dell'aggiornamento
Quando viene rilasciata una nuova versione principale o secondaria del motore Neptune, testa sempre le applicazioni Neptune su di essa prima di procedere all'aggiornamento. Anche un aggiornamento secondario potrebbe introdurre nuove funzionalità o comportamenti che possono influire sul codice.
Inizia confrontando le pagine delle note di rilascio della versione corrente con quelle della versione di destinazione per valutare se verranno modificate le versioni del linguaggio di query o verranno introdotte altre modifiche che causano interruzioni.
Il modo migliore per testare una nuova versione prima di aggiornare il cluster database di produzione è clonare il cluster di produzione affinché il clone esegua la nuova versione del motore. È quindi possibile eseguire query sul clone senza influire sul cluster database di produzione.
### Creare sempre uno snapshot manuale prima dell'aggiornamento
Prima di procedere a un aggiornamento, è consigliabile creare sempre uno snapshot manuale del cluster database. Uno snapshot automatico offre solo una protezione a breve termine, mentre uno snapshot manuale rimane disponibile fino a quando non lo elimini esplicitamente.
In alcuni casi Neptune crea automaticamente uno snapshot manuale come parte del processo di aggiornamento, ma non è consigliabile farvi affidamento ed è comunque opportuno creare sempre il proprio snapshot manuale.
Quando hai la certezza che non sarà necessario ripristinare lo stato precedente all'aggiornamento del cluster di database, puoi eliminare in modo esplicito lo snapshot manuale che hai creato, così come lo snapshot manuale eventualmente creato da Neptune. Se Neptune crea uno snapshot manuale, questo avrà un nome che inizia con `preupgrade`, seguito dal nome del cluster database, dalla versione del motore di origine, dalla versione del motore di destinazione e dalla data.
**Nota**
Se stai tentando di eseguire l'aggiornamento mentre [è in corso un'azione in sospeso](manage-console-maintaining), potrebbe verificarsi un errore come il seguente:
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Se riscontri questo errore, attendi il completamento dell'azione in sospeso o attiva immediatamente una finestra di manutenzione per completare l'aggiornamento precedente.
Per ulteriori informazioni sull'aggiornamento della versione del motore, consulta [Gestione del cluster di database Amazon Neptune](cluster-maintenance.md). In caso di domande o dubbi, il team di AWS supporto è disponibile nei forum della community e tramite [AWS Premium Support](https://aws.amazon.com/support).
# Motore Amazon Neptune versione 1.1.1.0.R6 (23/09/2022)
A partire dal 23 gennaio 2023, viene implementata a livello generale la versione del motore 1.1.1.0.R6. Tieni presente che occorrono diversi giorni prima che una nuova versione diventi disponibile in ogni regione.
**Importante**
**L'aggiornamento a questo rilascio del motore da una versione precedente alla `1.1.0.0` attiva anche un aggiornamento del sistema operativo su tutte le istanze del cluster database. Poiché le richieste di scrittura attive che si verificano durante l'aggiornamento del sistema operativo non vengono elaborate, è necessario sospendere tutti i carichi di lavoro in scrittura sul cluster da aggiornare, compresi i caricamenti di dati in blocco, prima di avviare l'aggiornamento.**
Per completare correttamente l'aggiornamento, ogni sottorete in ciascuna zona di disponibilità (AZ) deve avere almeno un indirizzo IP disponibile per ogni istanza di Neptune. Ad esempio, se ci sono un'istanza di scrittura e due istanze di lettura nella sottorete 1 e due istanze di lettura nella sottorete 2, la sottorete 1 deve avere almeno 3 indirizzi IP liberi e la sottorete 2 deve avere almeno 2 indirizzi IP liberi prima di avviare l'aggiornamento.
All'inizio dell'aggiornamento, Neptune genera uno snapshot con un nome composto da `preupgrade` seguito da un identificatore generato automaticamente in base alle informazioni del cluster database. Per lo snapshot non ti verrà addebitato alcun costo e potrai utilizzarlo per ripristinare il cluster database in caso di problemi durante il processo di aggiornamento.
La nuova versione del motore (una volta completato il relativo aggiornamento) rimane disponibile per un breve periodo di tempo sul vecchio sistema operativo, ma in meno di 5 minuti tutte le istanze del cluster avviano contemporaneamente un aggiornamento del sistema operativo. A questo punto, il cluster database non sarà disponibile per alcuni minuti. Puoi riprendere i carichi di lavoro in scrittura al termine dell'aggiornamento.
Questo processo genera i seguenti eventi:
Messaggi di evento per cluster:
`Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-(autogenerated snapshot ID)]`
`Database cluster major version has been upgraded`
Messaggi di evento per istanza:
`Applying off-line patches to DB instance`
`DB instance shutdown`
`Finished applying off-line patches to DB instance`
`DB instance restarted`
**Nota**
In questo rilascio è presente una modifica radicale per il codice che usa openCypher con autenticazione IAM. Finora, la stringa host nella firma IAM includeva il protocollo, come `bolt://`, ad esempio:
```
"Host":"bolt://(host URL):(port)"
```
A partire dal rilascio del motore `1.1.1.0`, il protocollo deve essere omesso:
```
"Host":"(host URL):(port)"
```
Per esempi, consulta [Utilizzo del protocollo Bolt](access-graph-opencypher-bolt.md).
## Miglioramenti in questo rilascio del motore
+ Sono state migliorate le prestazioni delle query `order-by` Gremlin. Le query Gremlin con `order-by` al termine di un `NeptuneGraphQueryStep` ora utilizzano blocchi di dimensioni superiori per prestazioni migliori. Questo non si applica a `order-by` in un nodo interno (non root) del piano di query.
+ Sono state migliorate le prestazioni delle query di aggiornamento Gremlin. I vertici e gli archi devono ora essere bloccati per impedirne l'eliminazione durante l'aggiunta di archi o proprietà. Questa modifica elimina i blocchi duplicati all'interno di una transazione, migliorando così le prestazioni.
## Difetti corretti in questo rilascio del motore
+ È stato corretto un bug di openCypher nella clausola `MERGE` che in alcuni casi causava la creazione di nodi e archi duplicati.
+ È stato corretto un bug nella gestione delle query di SPARQL che contengono `(NOT) EXISTS` all'interno di una clausola `OPTIONAL`, a causa del quale in qualche caso mancavano alcuni risultati delle query.
+ È stato corretto un bug che ritardava il riavvio del server quando era in corso un caricamento in blocco.
+ È stato corretto un bug a causa del quale l'attraversamento bidirezionale di un modello a lunghezza variabile openCypher con un filtro sulla proprietà di relazione causava un errore. Un esempio di tale modello a lunghezza variabile è `(n)-[r*1..2]->(m)`.
+ È stato corretto un bug relativo al modo in cui i dati memorizzati nella cache vengono inviati nuovamente al client, che in alcuni casi provocava una latenza inaspettatamente lunga.
## Versioni di linguaggio di query supportate in questo rilascio
Prima di aggiornare un cluster database alla versione 1.1.1.0.R6, assicurati che il tuo progetto sia compatibile con queste versioni di linguaggio di query:
+ *Versione meno recente di Gremlin supportata:* `3.5.2`
+ *Versione più recente di Gremlin supportata:* `3.5.4`
+ *Versione openCypher:* `Neptune-9.0.20190305-1.0`
+ *Versione di SPARQL:* `1.1`
## Percorsi di aggiornamento al rilascio del motore 1.1.1.0.R6
Se si esegue la versione del motore `1.1.1.0`, il cluster verrà aggiornato automaticamente a questo rilascio di patch durante la finestra di manutenzione successiva.
## Aggiornamento a questo rilascio
**Importante**
**L'aggiornamento a questo rilascio del motore da qualsiasi versione precedente alla `1.1.0.0` attiva anche un aggiornamento del sistema operativo su tutte le istanze del cluster database. Poiché le richieste di scrittura attive che si verificano durante l'aggiornamento del sistema operativo non vengono elaborate, è necessario sospendere tutti i carichi di lavoro in scrittura sul cluster da aggiornare, compresi i caricamenti di dati in blocco, prima di avviare l'aggiornamento.**
All'inizio dell'aggiornamento, Neptune genera uno snapshot con un nome composto da `preupgrade` seguito da un identificatore generato automaticamente in base alle informazioni del cluster database. Per lo snapshot non ti verrà addebitato alcun costo e potrai utilizzarlo per ripristinare il cluster database in caso di problemi durante il processo di aggiornamento.
La nuova versione del motore (una volta completato il relativo aggiornamento) rimane disponibile per un breve periodo di tempo sul vecchio sistema operativo, ma in meno di 5 minuti tutte le istanze del cluster avviano contemporaneamente un aggiornamento del sistema operativo. A questo punto, il cluster database non sarà disponibile per circa 6 minuti. Puoi riprendere i carichi di lavoro in scrittura al termine dell'aggiornamento.
Questo processo genera i seguenti eventi:
Messaggi di evento per cluster:
`Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-(autogenerated snapshot ID)]`
`Database cluster major version has been upgraded`
Messaggi di evento per istanza:
`Applying off-line patches to DB instance`
`DB instance shutdown`
`Finished applying off-line patches to DB instance`
`DB instance restarted`
Se un cluster database utilizza una versione del motore dalla quale esiste un percorso di aggiornamento a questo rilascio, ora è idoneo all'aggiornamento. È possibile aggiornare qualsiasi cluster idoneo utilizzando le operazioni del cluster database sulla console o utilizzando SDK. Il seguente comando CLI aggiornerà immediatamente un cluster idoneo:
Per Linux, OS X o Unix:
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.1.1.0 \
4. --apply-immediately
```
Per Windows:
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.1.1.0 ^
4. --apply-immediately
```
Gli aggiornamenti vengono applicati contemporaneamente a tutte le istanze in un cluster di database. Un aggiornamento richiede il riavvio del database su queste istanze, quindi si verificheranno tempi di inattività che vanno da 20-30 secondi a diversi minuti, dopodiché si potrà riprendere a usare il cluster database.
### Eseguire sempre un test prima dell'aggiornamento
Quando viene rilasciata una nuova versione principale o secondaria del motore Neptune, testa sempre le applicazioni Neptune su di essa prima di procedere all'aggiornamento. Anche un aggiornamento secondario potrebbe introdurre nuove funzionalità o comportamenti che possono influire sul codice.
Inizia confrontando le pagine delle note di rilascio della versione corrente con quelle della versione di destinazione per valutare se verranno modificate le versioni del linguaggio di query o verranno introdotte altre modifiche che causano interruzioni.
Il modo migliore per testare una nuova versione prima di aggiornare il cluster database di produzione è clonare il cluster di produzione affinché il clone esegua la nuova versione del motore. È quindi possibile eseguire query sul clone senza influire sul cluster database di produzione.
### Creare sempre uno snapshot manuale prima dell'aggiornamento
Prima di procedere a un aggiornamento, è consigliabile creare sempre uno snapshot manuale del cluster database. Uno snapshot automatico offre solo una protezione a breve termine, mentre uno snapshot manuale rimane disponibile fino a quando non lo elimini esplicitamente.
In alcuni casi Neptune crea automaticamente uno snapshot manuale come parte del processo di aggiornamento, ma non è consigliabile farvi affidamento ed è comunque opportuno creare sempre il proprio snapshot manuale.
Quando hai la certezza che non sarà necessario ripristinare lo stato precedente all'aggiornamento del cluster di database, puoi eliminare in modo esplicito lo snapshot manuale che hai creato, così come lo snapshot manuale eventualmente creato da Neptune. Se Neptune crea uno snapshot manuale, questo avrà un nome che inizia con `preupgrade`, seguito dal nome del cluster database, dalla versione del motore di origine, dalla versione del motore di destinazione e dalla data.
**Nota**
Se stai tentando di eseguire l'aggiornamento mentre [è in corso un'azione in sospeso](manage-console-maintaining), potrebbe verificarsi un errore come il seguente:
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Se riscontri questo errore, attendi il completamento dell'azione in sospeso o attiva immediatamente una finestra di manutenzione per completare l'aggiornamento precedente.
Per ulteriori informazioni sull'aggiornamento della versione del motore, consulta [Gestione del cluster di database Amazon Neptune](cluster-maintenance.md). In caso di domande o dubbi, il team di AWS supporto è disponibile nei forum della community e tramite [AWS Premium Support](https://aws.amazon.com/support).
# Motore Amazon Neptune versione 1.1.1.0.R5 (21/07/2022)
A partire dal 21 luglio 2022, viene implementata a livello generale la versione del motore 1.1.1.0.R5. Tieni presente che occorrono diversi giorni prima che una nuova versione diventi disponibile in ogni regione.
**Importante**
**L'aggiornamento a questo rilascio del motore da una versione precedente alla `1.1.0.0` attiva anche un aggiornamento del sistema operativo su tutte le istanze del cluster database. Poiché le richieste di scrittura attive che si verificano durante l'aggiornamento del sistema operativo non vengono elaborate, è necessario sospendere tutti i carichi di lavoro in scrittura sul cluster da aggiornare, compresi i caricamenti di dati in blocco, prima di avviare l'aggiornamento.**
Per completare correttamente l'aggiornamento, ogni sottorete in ciascuna zona di disponibilità (AZ) deve avere almeno un indirizzo IP disponibile per ogni istanza di Neptune. Ad esempio, se ci sono un'istanza di scrittura e due istanze di lettura nella sottorete 1 e due istanze di lettura nella sottorete 2, la sottorete 1 deve avere almeno 3 indirizzi IP liberi e la sottorete 2 deve avere almeno 2 indirizzi IP liberi prima di avviare l'aggiornamento.
All'inizio dell'aggiornamento, Neptune genera uno snapshot con un nome composto da `preupgrade` seguito da un identificatore generato automaticamente in base alle informazioni del cluster database. Per lo snapshot non ti verrà addebitato alcun costo e potrai utilizzarlo per ripristinare il cluster database in caso di problemi durante il processo di aggiornamento.
La nuova versione del motore (una volta completato il relativo aggiornamento) rimane disponibile per un breve periodo di tempo sul vecchio sistema operativo, ma in meno di 5 minuti tutte le istanze del cluster avviano contemporaneamente un aggiornamento del sistema operativo. A questo punto, il cluster database non sarà disponibile per alcuni minuti. Puoi riprendere i carichi di lavoro in scrittura al termine dell'aggiornamento.
Questo processo genera i seguenti eventi:
Messaggi di evento per cluster:
`Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-(autogenerated snapshot ID)]`
`Database cluster major version has been upgraded`
Messaggi di evento per istanza:
`Applying off-line patches to DB instance`
`DB instance shutdown`
`Finished applying off-line patches to DB instance`
`DB instance restarted`
**Nota**
In questo rilascio è presente una modifica radicale per il codice che usa openCypher con autenticazione IAM. Finora, la stringa host nella firma IAM includeva il protocollo, come `bolt://`, ad esempio:
```
"Host":"bolt://(host URL):(port)"
```
A partire dal rilascio del motore `1.1.1.0`, il protocollo deve essere omesso:
```
"Host":"(host URL):(port)"
```
Per esempi, consulta [Utilizzo del protocollo Bolt](access-graph-opencypher-bolt.md).
## Miglioramenti in questo rilascio del motore
+ Sono stati apportati miglioramenti per supportare il rilevamento dei deadlock.
## Difetti corretti in questo rilascio del motore
+ È stato corretto un bug che impediva l'arresto pulito dei cluster database in determinate condizioni.
## Versioni di linguaggio di query supportate in questo rilascio
Prima di aggiornare un cluster database alla versione 1.1.1.0.R5, assicurati che il tuo progetto sia compatibile con queste versioni di linguaggio di query:
+ *Versione meno recente di Gremlin supportata:* `3.5.2`
+ *Versione più recente di Gremlin supportata:* `3.5.4`
+ *Versione openCypher:* `Neptune-9.0.20190305-1.0`
+ *Versione di SPARQL:* `1.1`
## Percorsi di aggiornamento al rilascio del motore 1.1.1.0.R5
Se si esegue la versione del motore `1.1.1.0`, il cluster verrà aggiornato automaticamente a questo rilascio di patch durante la finestra di manutenzione successiva.
## Aggiornamento a questo rilascio
**Importante**
**L'aggiornamento a questo rilascio del motore da qualsiasi versione precedente alla `1.1.0.0` attiva anche un aggiornamento del sistema operativo su tutte le istanze del cluster database. Poiché le richieste di scrittura attive che si verificano durante l'aggiornamento del sistema operativo non vengono elaborate, è necessario sospendere tutti i carichi di lavoro in scrittura sul cluster da aggiornare, compresi i caricamenti di dati in blocco, prima di avviare l'aggiornamento.**
All'inizio dell'aggiornamento, Neptune genera uno snapshot con un nome composto da `preupgrade` seguito da un identificatore generato automaticamente in base alle informazioni del cluster database. Per lo snapshot non ti verrà addebitato alcun costo e potrai utilizzarlo per ripristinare il cluster database in caso di problemi durante il processo di aggiornamento.
La nuova versione del motore (una volta completato il relativo aggiornamento) rimane disponibile per un breve periodo di tempo sul vecchio sistema operativo, ma in meno di 5 minuti tutte le istanze del cluster avviano contemporaneamente un aggiornamento del sistema operativo. A questo punto, il cluster database non sarà disponibile per circa 6 minuti. Puoi riprendere i carichi di lavoro in scrittura al termine dell'aggiornamento.
Questo processo genera i seguenti eventi:
Messaggi di evento per cluster:
`Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-(autogenerated snapshot ID)]`
`Database cluster major version has been upgraded`
Messaggi di evento per istanza:
`Applying off-line patches to DB instance`
`DB instance shutdown`
`Finished applying off-line patches to DB instance`
`DB instance restarted`
Se un cluster database utilizza una versione del motore dalla quale esiste un percorso di aggiornamento a questo rilascio, ora è idoneo all'aggiornamento. È possibile aggiornare qualsiasi cluster idoneo utilizzando le operazioni del cluster database sulla console o utilizzando SDK. Il seguente comando CLI aggiornerà immediatamente un cluster idoneo:
Per Linux, OS X o Unix:
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.1.1.0 \
4. --apply-immediately
```
Per Windows:
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.1.1.0 ^
4. --apply-immediately
```
Gli aggiornamenti vengono applicati contemporaneamente a tutte le istanze in un cluster di database. Un aggiornamento richiede il riavvio del database su queste istanze, quindi si verificheranno tempi di inattività che vanno da 20-30 secondi a diversi minuti, dopodiché si potrà riprendere a usare il cluster database.
### Eseguire sempre un test prima dell'aggiornamento
Quando viene rilasciata una nuova versione principale o secondaria del motore Neptune, testa sempre le applicazioni Neptune su di essa prima di procedere all'aggiornamento. Anche un aggiornamento secondario potrebbe introdurre nuove funzionalità o comportamenti che possono influire sul codice.
Inizia confrontando le pagine delle note di rilascio della versione corrente con quelle della versione di destinazione per valutare se verranno modificate le versioni del linguaggio di query o verranno introdotte altre modifiche che causano interruzioni.
Il modo migliore per testare una nuova versione prima di aggiornare il cluster database di produzione è clonare il cluster di produzione affinché il clone esegua la nuova versione del motore. È quindi possibile eseguire query sul clone senza influire sul cluster database di produzione.
### Creare sempre uno snapshot manuale prima dell'aggiornamento
Prima di procedere a un aggiornamento, è consigliabile creare sempre uno snapshot manuale del cluster database. Uno snapshot automatico offre solo una protezione a breve termine, mentre uno snapshot manuale rimane disponibile fino a quando non lo elimini esplicitamente.
In alcuni casi Neptune crea automaticamente uno snapshot manuale come parte del processo di aggiornamento, ma non è consigliabile farvi affidamento ed è comunque opportuno creare sempre il proprio snapshot manuale.
Quando hai la certezza che non sarà necessario ripristinare lo stato precedente all'aggiornamento del cluster di database, puoi eliminare in modo esplicito lo snapshot manuale che hai creato, così come lo snapshot manuale eventualmente creato da Neptune. Se Neptune crea uno snapshot manuale, questo avrà un nome che inizia con `preupgrade`, seguito dal nome del cluster database, dalla versione del motore di origine, dalla versione del motore di destinazione e dalla data.
**Nota**
Se stai tentando di eseguire l'aggiornamento mentre [è in corso un'azione in sospeso](manage-console-maintaining), potrebbe verificarsi un errore come il seguente:
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Se riscontri questo errore, attendi il completamento dell'azione in sospeso o attiva immediatamente una finestra di manutenzione per completare l'aggiornamento precedente.
Per ulteriori informazioni sull'aggiornamento della versione del motore, consulta [Gestione del cluster di database Amazon Neptune](cluster-maintenance.md). In caso di domande o dubbi, il team di AWS supporto è disponibile nei forum della community e tramite [AWS Premium Support](https://aws.amazon.com/support).
# Motore Amazon Neptune versione 1.1.1.0.R4 (23/06/2022)
A partire dal 23 giugno 2022, viene implementata a livello generale la versione del motore 1.1.1.0.R4. Tieni presente che occorrono diversi giorni prima che una nuova versione diventi disponibile in ogni regione.
**Importante**
**L'aggiornamento a questo rilascio del motore da una versione precedente alla `1.1.0.0` attiva anche un aggiornamento del sistema operativo su tutte le istanze del cluster database. Poiché le richieste di scrittura attive che si verificano durante l'aggiornamento del sistema operativo non vengono elaborate, è necessario sospendere tutti i carichi di lavoro in scrittura sul cluster da aggiornare, compresi i caricamenti di dati in blocco, prima di avviare l'aggiornamento.**
Per completare correttamente l'aggiornamento, ogni sottorete in ciascuna zona di disponibilità (AZ) deve avere almeno un indirizzo IP disponibile per ogni istanza di Neptune. Ad esempio, se ci sono un'istanza di scrittura e due istanze di lettura nella sottorete 1 e due istanze di lettura nella sottorete 2, la sottorete 1 deve avere almeno 3 indirizzi IP liberi e la sottorete 2 deve avere almeno 2 indirizzi IP liberi prima di avviare l'aggiornamento.
All'inizio dell'aggiornamento, Neptune genera uno snapshot con un nome composto da `preupgrade` seguito da un identificatore generato automaticamente in base alle informazioni del cluster database. Per lo snapshot non ti verrà addebitato alcun costo e potrai utilizzarlo per ripristinare il cluster database in caso di problemi durante il processo di aggiornamento.
La nuova versione del motore (una volta completato il relativo aggiornamento) rimane disponibile per un breve periodo di tempo sul vecchio sistema operativo, ma in meno di 5 minuti tutte le istanze del cluster avviano contemporaneamente un aggiornamento del sistema operativo. A questo punto, il cluster database non sarà disponibile per alcuni minuti. Puoi riprendere i carichi di lavoro in scrittura al termine dell'aggiornamento.
Questo processo genera i seguenti eventi:
Messaggi di evento per cluster:
`Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-(autogenerated snapshot ID)]`
`Database cluster major version has been upgraded`
Messaggi di evento per istanza:
`Applying off-line patches to DB instance`
`DB instance shutdown`
`Finished applying off-line patches to DB instance`
`DB instance restarted`
**Nota**
In questo rilascio è presente una modifica radicale per il codice che usa openCypher con autenticazione IAM. Finora, la stringa host nella firma IAM includeva il protocollo, come `bolt://`, ad esempio:
```
"Host":"bolt://(host URL):(port)"
```
A partire dal rilascio del motore `1.1.1.0`, il protocollo deve essere omesso:
```
"Host":"(host URL):(port)"
```
Per esempi, consulta [Utilizzo del protocollo Bolt](access-graph-opencypher-bolt.md).
## Miglioramenti in questo rilascio del motore
+ È stata aggiornata la configurazione dell'istanza per i tipi di istanza `x2g`.
+ Sono state migliorate le prestazioni di rimozione dei vertici.
## Difetti corretti in questo rilascio del motore
+ È stato corretto un bug di Gremlin a causa del quale le soluzioni non mantenevano un ordine stabile per una query chiamata più volte o tra più istanze di lettura per determinati tipi di join ASK.
+ Inoltre, è stato ristretto l'ambito di una modifica apportata nel rilascio precedente che causava regressioni delle prestazioni per alcuni tipi di join ASK in Gremlin.
+ È stato corretto un bug di Gremlin nella fase `union()` che si verificava quando c'era un input di arco e un attraversamento verso un vertice all'interno degli attraversamenti figlio.
+ È stato corretto un bug del profilo di Gremlin per cui alcune fasi venivano segnalate come non ottimizzate quando in realtà lo erano.
+ È stato corretto un bug di SPARQL a causa del quale alle variabili utilizzate all'interno delle espressioni `FILTER` annidate nelle clausole `UNION` venivano assegnate informazioni di ambito non valide.
## Versioni di linguaggio di query supportate in questo rilascio
Prima di aggiornare un cluster database alla versione 1.1.1.0.R4, assicurati che il tuo progetto sia compatibile con queste versioni di linguaggio di query:
+ *Versione meno recente di Gremlin supportata:* `3.5.2`
+ *Versione più recente di Gremlin supportata:* `3.5.4`
+ *Versione openCypher:* `Neptune-9.0.20190305-1.0`
+ *Versione di SPARQL:* `1.1`
## Percorsi di aggiornamento al rilascio del motore 1.1.1.0.R4
Se si esegue la versione del motore `1.1.1.0`, il cluster verrà aggiornato automaticamente a questo rilascio di patch durante la finestra di manutenzione successiva.
## Aggiornamento a questo rilascio
**Importante**
**L'aggiornamento a questo rilascio del motore da qualsiasi versione precedente alla `1.1.0.0` attiva anche un aggiornamento del sistema operativo su tutte le istanze del cluster database. Poiché le richieste di scrittura attive che si verificano durante l'aggiornamento del sistema operativo non vengono elaborate, è necessario sospendere tutti i carichi di lavoro in scrittura sul cluster da aggiornare, compresi i caricamenti di dati in blocco, prima di avviare l'aggiornamento.**
All'inizio dell'aggiornamento, Neptune genera uno snapshot con un nome composto da `preupgrade` seguito da un identificatore generato automaticamente in base alle informazioni del cluster database. Per lo snapshot non ti verrà addebitato alcun costo e potrai utilizzarlo per ripristinare il cluster database in caso di problemi durante il processo di aggiornamento.
La nuova versione del motore (una volta completato il relativo aggiornamento) rimane disponibile per un breve periodo di tempo sul vecchio sistema operativo, ma in meno di 5 minuti tutte le istanze del cluster avviano contemporaneamente un aggiornamento del sistema operativo. A questo punto, il cluster database non sarà disponibile per circa 6 minuti. Puoi riprendere i carichi di lavoro in scrittura al termine dell'aggiornamento.
Questo processo genera i seguenti eventi:
Messaggi di evento per cluster:
`Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-(autogenerated snapshot ID)]`
`Database cluster major version has been upgraded`
Messaggi di evento per istanza:
`Applying off-line patches to DB instance`
`DB instance shutdown`
`Finished applying off-line patches to DB instance`
`DB instance restarted`
Se un cluster database utilizza una versione del motore dalla quale esiste un percorso di aggiornamento a questo rilascio, ora è idoneo all'aggiornamento. È possibile aggiornare qualsiasi cluster idoneo utilizzando le operazioni del cluster database sulla console o utilizzando SDK. Il seguente comando CLI aggiornerà immediatamente un cluster idoneo:
Per Linux, OS X o Unix:
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.1.1.0 \
4. --apply-immediately
```
Per Windows:
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.1.1.0 ^
4. --apply-immediately
```
Gli aggiornamenti vengono applicati contemporaneamente a tutte le istanze in un cluster di database. Un aggiornamento richiede il riavvio del database su queste istanze, quindi si verificheranno tempi di inattività che vanno da 20-30 secondi a diversi minuti, dopodiché si potrà riprendere a usare il cluster database.
### Eseguire sempre un test prima dell'aggiornamento
Quando viene rilasciata una nuova versione principale o secondaria del motore Neptune, testa sempre le applicazioni Neptune su di essa prima di procedere all'aggiornamento. Anche un aggiornamento secondario potrebbe introdurre nuove funzionalità o comportamenti che possono influire sul codice.
Inizia confrontando le pagine delle note di rilascio della versione corrente con quelle della versione di destinazione per valutare se verranno modificate le versioni del linguaggio di query o verranno introdotte altre modifiche che causano interruzioni.
Il modo migliore per testare una nuova versione prima di aggiornare il cluster database di produzione è clonare il cluster di produzione affinché il clone esegua la nuova versione del motore. È quindi possibile eseguire query sul clone senza influire sul cluster database di produzione.
### Creare sempre uno snapshot manuale prima dell'aggiornamento
Prima di procedere a un aggiornamento, è consigliabile creare sempre uno snapshot manuale del cluster database. Uno snapshot automatico offre solo una protezione a breve termine, mentre uno snapshot manuale rimane disponibile fino a quando non lo elimini esplicitamente.
In alcuni casi Neptune crea automaticamente uno snapshot manuale come parte del processo di aggiornamento, ma non è consigliabile farvi affidamento ed è comunque opportuno creare sempre il proprio snapshot manuale.
Quando hai la certezza che non sarà necessario ripristinare lo stato precedente all'aggiornamento del cluster di database, puoi eliminare in modo esplicito lo snapshot manuale che hai creato, così come lo snapshot manuale eventualmente creato da Neptune. Se Neptune crea uno snapshot manuale, questo avrà un nome che inizia con `preupgrade`, seguito dal nome del cluster database, dalla versione del motore di origine, dalla versione del motore di destinazione e dalla data.
**Nota**
Se stai tentando di eseguire l'aggiornamento mentre [è in corso un'azione in sospeso](manage-console-maintaining), potrebbe verificarsi un errore come il seguente:
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Se riscontri questo errore, attendi il completamento dell'azione in sospeso o attiva immediatamente una finestra di manutenzione per completare l'aggiornamento precedente.
Per ulteriori informazioni sull'aggiornamento della versione del motore, consulta [Gestione del cluster di database Amazon Neptune](cluster-maintenance.md). In caso di domande o dubbi, il team di AWS supporto è disponibile nei forum della community e tramite [AWS Premium Support](https://aws.amazon.com/support).
# Motore Amazon Neptune versione 1.1.1.0.R3 (07/06/2022)
A partire dal 7 giugno 2022, viene implementata a livello generale la versione del motore 1.1.1.0.R3. Tieni presente che occorrono diversi giorni prima che una nuova versione diventi disponibile in ogni regione.
**Importante**
**L'aggiornamento a questo rilascio del motore da una versione precedente alla `1.1.0.0` attiva anche un aggiornamento del sistema operativo su tutte le istanze del cluster database. Poiché le richieste di scrittura attive che si verificano durante l'aggiornamento del sistema operativo non vengono elaborate, è necessario sospendere tutti i carichi di lavoro in scrittura sul cluster da aggiornare, compresi i caricamenti di dati in blocco, prima di avviare l'aggiornamento.**
All'inizio dell'aggiornamento, Neptune genera uno snapshot con un nome composto da `preupgrade` seguito da un identificatore generato automaticamente in base alle informazioni del cluster database. Per lo snapshot non ti verrà addebitato alcun costo e potrai utilizzarlo per ripristinare il cluster database in caso di problemi durante il processo di aggiornamento.
La nuova versione del motore (una volta completato il relativo aggiornamento) rimane disponibile per un breve periodo di tempo sul vecchio sistema operativo, ma in meno di 5 minuti tutte le istanze del cluster avviano contemporaneamente un aggiornamento del sistema operativo. A questo punto, il cluster database non sarà disponibile per alcuni minuti. Puoi riprendere i carichi di lavoro in scrittura al termine dell'aggiornamento.
Questo processo genera i seguenti eventi:
Messaggi di evento per cluster:
`Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-(autogenerated snapshot ID)]`
`Database cluster major version has been upgraded`
Messaggi di evento per istanza:
`Applying off-line patches to DB instance`
`DB instance shutdown`
`Finished applying off-line patches to DB instance`
`DB instance restarted`
**Nota**
In questo rilascio è presente una modifica radicale per il codice che usa openCypher con autenticazione IAM. Finora, la stringa host nella firma IAM includeva il protocollo, come `bolt://`, ad esempio:
```
"Host":"bolt://(host URL):(port)"
```
A partire dal rilascio del motore `1.1.1.0`, il protocollo deve essere omesso:
```
"Host":"(host URL):(port)"
```
Per esempi, consulta [Utilizzo del protocollo Bolt](access-graph-opencypher-bolt.md).
## Miglioramenti in questo rilascio del motore
+ Aggiunto il supporto per i tipi di istanza `x2g` basati su Graviton2, ottimizzati per carichi di lavoro che richiedono molta memoria. Inizialmente sono disponibili solo in quattro versioni Regioni AWS:
+ Stati Uniti orientali (Virginia settentrionale) (`us-east-1`)
+ Stati Uniti orientali (Ohio) (`us-east-2`)
+ Stati Uniti occidentali (Oregon) (`us-west-2`)
+ Europa (Irlanda) (`eu-west-1`)
Per ulteriori informazioni, consulta la [pagina dei prezzi di Neptune](https://aws.amazon.com/neptune/pricing/).
+ Sono state migliorate le prestazioni delle fasi di Gremlin in cui sono coinvolti più attraversamenti di archi o vertici, ricerche di proprietà o ricerche di etichette.
## Difetti corretti in questo rilascio del motore
+ È stato corretto un bug di Gremlin nell'elaborazione della fase `otherV()` all'interno di un attraversamento figlio.
+ È stato corretto un bug di Gremlin nelle query con `union` che hanno come elemento figlio solo fasi di filtro. Per esempio:
```
g.V().union(has("name"), out("knows")).out()
```
+ È stato corretto un bug di SPARQL a causa del quale alle variabili utilizzate all'interno delle espressioni `FILTER` annidate nelle clausole `UNION` venivano assegnate informazioni di ambito non valide.
## Versioni di linguaggio di query supportate in questo rilascio
Prima di aggiornare un cluster database alla versione 1.1.1.0.R3, assicurati che il tuo progetto sia compatibile con queste versioni di linguaggio di query:
+ *Versione meno recente di Gremlin supportata:* `3.5.2`
+ *Versione più recente di Gremlin supportata:* `3.5.4`
+ *Versione openCypher:* `Neptune-9.0.20190305-1.0`
+ *Versione di SPARQL:* `1.1`
## Percorsi di aggiornamento al rilascio del motore 1.1.1.0.R3
Se si esegue la versione del motore `1.1.1.0`, il cluster verrà aggiornato automaticamente a questo rilascio di patch durante la finestra di manutenzione successiva.
## Aggiornamento a questo rilascio
**Importante**
**L'aggiornamento a questo rilascio del motore da qualsiasi versione precedente alla `1.1.0.0` attiva anche un aggiornamento del sistema operativo su tutte le istanze del cluster database. Poiché le richieste di scrittura attive che si verificano durante l'aggiornamento del sistema operativo non vengono elaborate, è necessario sospendere tutti i carichi di lavoro in scrittura sul cluster da aggiornare, compresi i caricamenti di dati in blocco, prima di avviare l'aggiornamento.**
All'inizio dell'aggiornamento, Neptune genera uno snapshot con un nome composto da `preupgrade` seguito da un identificatore generato automaticamente in base alle informazioni del cluster database. Per lo snapshot non ti verrà addebitato alcun costo e potrai utilizzarlo per ripristinare il cluster database in caso di problemi durante il processo di aggiornamento.
La nuova versione del motore (una volta completato il relativo aggiornamento) rimane disponibile per un breve periodo di tempo sul vecchio sistema operativo, ma in meno di 5 minuti tutte le istanze del cluster avviano contemporaneamente un aggiornamento del sistema operativo. A questo punto, il cluster database non sarà disponibile per circa 6 minuti. Puoi riprendere i carichi di lavoro in scrittura al termine dell'aggiornamento.
Questo processo genera i seguenti eventi:
Messaggi di evento per cluster:
`Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-(autogenerated snapshot ID)]`
`Database cluster major version has been upgraded`
Messaggi di evento per istanza:
`Applying off-line patches to DB instance`
`DB instance shutdown`
`Finished applying off-line patches to DB instance`
`DB instance restarted`
Se un cluster database utilizza una versione del motore dalla quale esiste un percorso di aggiornamento a questo rilascio, ora è idoneo all'aggiornamento. È possibile aggiornare qualsiasi cluster idoneo utilizzando le operazioni del cluster database sulla console o utilizzando SDK. Il seguente comando CLI aggiornerà immediatamente un cluster idoneo:
Per Linux, OS X o Unix:
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.1.1.0 \
4. --apply-immediately
```
Per Windows:
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.1.1.0 ^
4. --apply-immediately
```
Gli aggiornamenti vengono applicati contemporaneamente a tutte le istanze in un cluster di database. Un aggiornamento richiede il riavvio del database su queste istanze, quindi si verificheranno tempi di inattività che vanno da 20-30 secondi a diversi minuti, dopodiché si potrà riprendere a usare il cluster database.
### Eseguire sempre un test prima dell'aggiornamento
Quando viene rilasciata una nuova versione principale o secondaria del motore Neptune, testa sempre le applicazioni Neptune su di essa prima di procedere all'aggiornamento. Anche un aggiornamento secondario potrebbe introdurre nuove funzionalità o comportamenti che possono influire sul codice.
Inizia confrontando le pagine delle note di rilascio della versione corrente con quelle della versione di destinazione per valutare se verranno modificate le versioni del linguaggio di query o verranno introdotte altre modifiche che causano interruzioni.
Il modo migliore per testare una nuova versione prima di aggiornare il cluster database di produzione è clonare il cluster di produzione affinché il clone esegua la nuova versione del motore. È quindi possibile eseguire query sul clone senza influire sul cluster database di produzione.
### Creare sempre uno snapshot manuale prima dell'aggiornamento
Prima di procedere a un aggiornamento, è consigliabile creare sempre uno snapshot manuale del cluster database. Uno snapshot automatico offre solo una protezione a breve termine, mentre uno snapshot manuale rimane disponibile fino a quando non lo elimini esplicitamente.
In alcuni casi Neptune crea automaticamente uno snapshot manuale come parte del processo di aggiornamento, ma non è consigliabile farvi affidamento ed è comunque opportuno creare sempre il proprio snapshot manuale.
Quando hai la certezza che non sarà necessario ripristinare lo stato precedente all'aggiornamento del cluster di database, puoi eliminare in modo esplicito lo snapshot manuale che hai creato, così come lo snapshot manuale eventualmente creato da Neptune. Se Neptune crea uno snapshot manuale, questo avrà un nome che inizia con `preupgrade`, seguito dal nome del cluster database, dalla versione del motore di origine, dalla versione del motore di destinazione e dalla data.
**Nota**
Se stai tentando di eseguire l'aggiornamento mentre [è in corso un'azione in sospeso](manage-console-maintaining), potrebbe verificarsi un errore come il seguente:
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Se riscontri questo errore, attendi il completamento dell'azione in sospeso o attiva immediatamente una finestra di manutenzione per completare l'aggiornamento precedente.
Per ulteriori informazioni sull'aggiornamento della versione del motore, consulta [Gestione del cluster di database Amazon Neptune](cluster-maintenance.md). In caso di domande o dubbi, il team di AWS supporto è disponibile nei forum della community e tramite [AWS Premium Support](https://aws.amazon.com/support).
# Rilascio di manutenzione di Amazon Neptune, versione 1.1.1.0.R2 (16/05/2022)
A partire dal 16 maggio 2022, viene implementata a livello generale la versione del motore 1.1.1.0.R2. Tieni presente che occorrono diversi giorni prima che una nuova versione diventi disponibile in ogni regione.
**Importante**
**L'aggiornamento a questo rilascio del motore da una versione precedente alla `1.1.0.0` attiva anche un aggiornamento del sistema operativo su tutte le istanze del cluster database. Poiché le richieste di scrittura attive che si verificano durante l'aggiornamento del sistema operativo non vengono elaborate, è necessario sospendere tutti i carichi di lavoro in scrittura sul cluster da aggiornare, compresi i caricamenti di dati in blocco, prima di avviare l'aggiornamento.**
Per completare correttamente l'aggiornamento, ogni sottorete in ciascuna zona di disponibilità (AZ) deve avere almeno un indirizzo IP disponibile per ogni istanza di Neptune. Ad esempio, se ci sono un'istanza di scrittura e due istanze di lettura nella sottorete 1 e due istanze di lettura nella sottorete 2, la sottorete 1 deve avere almeno 3 indirizzi IP liberi e la sottorete 2 deve avere almeno 2 indirizzi IP liberi prima di avviare l'aggiornamento.
All'inizio dell'aggiornamento, Neptune genera uno snapshot con un nome composto da `preupgrade` seguito da un identificatore generato automaticamente in base alle informazioni del cluster database. Per lo snapshot non ti verrà addebitato alcun costo e potrai utilizzarlo per ripristinare il cluster database in caso di problemi durante il processo di aggiornamento.
La nuova versione del motore (una volta completato il relativo aggiornamento) rimane disponibile per un breve periodo di tempo sul vecchio sistema operativo, ma in meno di 5 minuti tutte le istanze del cluster avviano contemporaneamente un aggiornamento del sistema operativo. A questo punto, il cluster database non sarà disponibile per alcuni minuti. Puoi riprendere i carichi di lavoro in scrittura al termine dell'aggiornamento.
Questo processo genera i seguenti eventi:
Messaggi di evento per cluster:
`Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-(autogenerated snapshot ID)]`
`Database cluster major version has been upgraded`
Messaggi di evento per istanza:
`Applying off-line patches to DB instance`
`DB instance shutdown`
`Finished applying off-line patches to DB instance`
`DB instance restarted`
**Nota**
In questo rilascio è presente una modifica radicale per il codice che usa openCypher con autenticazione IAM. Finora, la stringa host nella firma IAM includeva il protocollo, come `bolt://`, ad esempio:
```
"Host":"bolt://(host URL):(port)"
```
A partire dal rilascio del motore `1.1.1.0`, il protocollo deve essere omesso:
```
"Host":"(host URL):(port)"
```
Per esempi, consulta [Utilizzo del protocollo Bolt](access-graph-opencypher-bolt.md).
## Versioni di linguaggio di query supportate in questo rilascio
Prima di aggiornare un cluster database alla versione 1.1.1.0.R2, assicurati che il tuo progetto sia compatibile con queste versioni di linguaggio di query:
+ *Versione meno recente di Gremlin supportata:* `3.5.2`
+ *Versione più recente di Gremlin supportata:* `3.5.4`
+ *Versione openCypher:* `Neptune-9.0.20190305-1.0`
+ *Versione di SPARQL:* `1.1`
## Percorsi di aggiornamento al rilascio del motore 1.1.1.0.R2
Se si esegue la versione del motore `1.1.1.0`, il cluster viene aggiornato automaticamente a questo rilascio di patch di manutenzione durante la finestra di manutenzione successiva.
È possibile aggiornare manualmente qualsiasi rilascio del motore Neptune precedente a questo rilascio.
## Aggiornamento a questo rilascio
**Importante**
**L'aggiornamento a questo rilascio del motore da qualsiasi versione precedente alla `1.1.0.0` attiva anche un aggiornamento del sistema operativo su tutte le istanze del cluster database. Poiché le richieste di scrittura attive che si verificano durante l'aggiornamento del sistema operativo non vengono elaborate, è necessario sospendere tutti i carichi di lavoro in scrittura sul cluster da aggiornare, compresi i caricamenti di dati in blocco, prima di avviare l'aggiornamento.**
All'inizio dell'aggiornamento, Neptune genera uno snapshot con un nome composto da `preupgrade` seguito da un identificatore generato automaticamente in base alle informazioni del cluster database. Per lo snapshot non ti verrà addebitato alcun costo e potrai utilizzarlo per ripristinare il cluster database in caso di problemi durante il processo di aggiornamento.
La nuova versione del motore (una volta completato il relativo aggiornamento) rimane disponibile per un breve periodo di tempo sul vecchio sistema operativo, ma in meno di 5 minuti tutte le istanze del cluster avviano contemporaneamente un aggiornamento del sistema operativo. A questo punto, il cluster database non sarà disponibile per circa 6 minuti. Puoi riprendere i carichi di lavoro in scrittura al termine dell'aggiornamento.
Questo processo genera i seguenti eventi:
Messaggi di evento per cluster:
`Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-(autogenerated snapshot ID)]`
`Database cluster major version has been upgraded`
Messaggi di evento per istanza:
`Applying off-line patches to DB instance`
`DB instance shutdown`
`Finished applying off-line patches to DB instance`
`DB instance restarted`
Se un cluster database utilizza una versione del motore dalla quale esiste un percorso di aggiornamento a questo rilascio, ora è idoneo all'aggiornamento. È possibile aggiornare qualsiasi cluster idoneo utilizzando le operazioni del cluster database sulla console o utilizzando SDK. Il seguente comando CLI aggiornerà immediatamente un cluster idoneo:
Per Linux, OS X o Unix:
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.1.1.0 \
4. --apply-immediately
```
Per Windows:
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.1.1.0 ^
4. --apply-immediately
```
Gli aggiornamenti vengono applicati contemporaneamente a tutte le istanze in un cluster di database. Un aggiornamento richiede il riavvio del database su queste istanze, quindi si verificheranno tempi di inattività che vanno da 20-30 secondi a diversi minuti, dopodiché si potrà riprendere a usare il cluster database.
### Eseguire sempre un test prima dell'aggiornamento
Quando viene rilasciata una nuova versione principale o secondaria del motore Neptune, testa sempre le applicazioni Neptune su di essa prima di procedere all'aggiornamento. Anche un aggiornamento secondario potrebbe introdurre nuove funzionalità o comportamenti che possono influire sul codice.
Inizia confrontando le pagine delle note di rilascio della versione corrente con quelle della versione di destinazione per valutare se verranno modificate le versioni del linguaggio di query o verranno introdotte altre modifiche che causano interruzioni.
Il modo migliore per testare una nuova versione prima di aggiornare il cluster database di produzione è clonare il cluster di produzione affinché il clone esegua la nuova versione del motore. È quindi possibile eseguire query sul clone senza influire sul cluster database di produzione.
### Creare sempre uno snapshot manuale prima dell'aggiornamento
Prima di procedere a un aggiornamento, è consigliabile creare sempre uno snapshot manuale del cluster database. Uno snapshot automatico offre solo una protezione a breve termine, mentre uno snapshot manuale rimane disponibile fino a quando non lo elimini esplicitamente.
In alcuni casi Neptune crea automaticamente uno snapshot manuale come parte del processo di aggiornamento, ma non è consigliabile farvi affidamento ed è comunque opportuno creare sempre il proprio snapshot manuale.
Quando hai la certezza che non sarà necessario ripristinare lo stato precedente all'aggiornamento del cluster di database, puoi eliminare in modo esplicito lo snapshot manuale che hai creato, così come lo snapshot manuale eventualmente creato da Neptune. Se Neptune crea uno snapshot manuale, questo avrà un nome che inizia con `preupgrade`, seguito dal nome del cluster database, dalla versione del motore di origine, dalla versione del motore di destinazione e dalla data.
**Nota**
Se stai tentando di eseguire l'aggiornamento mentre [è in corso un'azione in sospeso](manage-console-maintaining), potrebbe verificarsi un errore come il seguente:
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Se riscontri questo errore, attendi il completamento dell'azione in sospeso o attiva immediatamente una finestra di manutenzione per completare l'aggiornamento precedente.
Per ulteriori informazioni sull'aggiornamento della versione del motore, consulta [Gestione del cluster di database Amazon Neptune](cluster-maintenance.md). In caso di domande o dubbi, il team di AWS supporto è disponibile nei forum della community e tramite [AWS Premium Support](https://aws.amazon.com/support).