

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.0.2.2 (09/03/2020)
<a name="engine-releases-1.0.2.2"></a>

A partire dal 9 marzo 2020, viene implementata a livello generale la versione del motore 1.0.2.2. Tieni presente che occorrono diversi giorni prima che una nuova versione diventi disponibile in ogni regione.

## Rilascio di patch successive per questa versione
<a name="engine-releases-1.0.2.2-patches"></a>
+ [Rilascio: 1.0.2.2.R2 (02/04/2020)](engine-releases-1.0.2.2.R2.md) 
+ [Rilascio: 1.0.2.2.R3 (22/07/2020)](engine-releases-1.0.2.2.R3.md) 
+ [Rilascio: 1.0.2.2.R4 (23/07/2020)](engine-releases-1.0.2.2.R4.md) 
+ [Rilascio: 1.0.2.2.R5 (12/10/2020)](engine-releases-1.0.2.2.R5.md) 
+ [Rilascio: 1.0.2.2.R6 (19/02/2021)](engine-releases-1.0.2.2.R6.md) 

## Miglioramenti in questo rilascio del motore
<a name="engine-releases-1.0.2.2-improvements"></a>
+ Aggiunte informazioni all'API di stato sulle transazioni che vengono ripristinate. Consultare [Stato dell'istanza](access-graph-status.md).
+ Aggiornata la versione di Apache TinkerPop alla 3.4.3.

  La versione 3.4.3 è retrocompatibile con la versione precedente supportata da Neptune (3.4.1). Introduce una modifica minore nel comportamento: Gremlin non restituisce più un errore quando si tenta di chiudere una sessione che non esiste (vedere [Impedire l'insorgere di un errore quando si chiudono sessioni che non esistono](https://issues.apache.org/jira/browse/TINKERPOP-2237)).
+ Rimossi i colli di bottiglia delle prestazioni durante l'esecuzione dei passaggi di ricerca full-text di Gremlin.

## Difetti corretti in questo rilascio del motore
<a name="engine-releases-1.0.2.2-defects"></a>
+ Corretto un bug di SPARQL nella gestione di schemi grafici vuoti nelle query.
+ Corretto un bug di SPARQL nella gestione di punti e virgola non codificati nelle query con codifica URL.
+ Corretto un bug di Gremlin nella gestione dei vertici ripetuti nel passaggio `Union`.
+ Corretto un bug Gremlin che portava alcune query con un `.simplePath()` o `.cyclicPath()` all'interno di un `.repeat()` a restituire risultati errati.
+ Corretto un bug di Gremlin che portava `.project()` a restituire risultati errati se il suo attraversamento figlio non restituiva alcuna soluzione.
+ Corretto un bug di Gremlin in cui gli errori da conflitti di lettura-scrittura sollevavano `InternalFailureException` piuttosto che `ConcurrentModificationException`.
+ Corretto un bug di Gremlin che causava errori `.group().by(...).by(values("property"))`.
+ Sono stati corretti i bug di Gremlin nell'output del profilo per i passaggi. full-text-search
+ Corretta una perdita di risorse nelle sessioni di Gremlin.
+ Corretto un bug che impediva all'API di stato di segnalare la versione ordinabile corretta in alcuni casi.
+ Corretto un bug dello strumento di caricamento in blocco che consentiva di utilizzare un URL a una posizione diversa da Amazon S3 come origine in una richiesta di caricamento in blocco.
+ Corretto un bug dello strumento di caricamento in blocco nello stato di caricamento dettagliato.

## Versioni di linguaggio di query supportate in questo rilascio
<a name="engine-releases-1.0.2.2-query-versions"></a>

Prima di aggiornare un cluster database alla versione 1.0.2.2, assicurati che il tuo progetto sia compatibile con queste versioni di linguaggio di query:
+ *Versione di Gremlin:* `3.4.3`
+ *Versione di SPARQL:* `1.1`

## Percorsi di aggiornamento al rilascio del motore 1.0.2.2
<a name="engine-releases-1.0.2.2-upgrade-paths"></a>

È possibile aggiornare manualmente qualsiasi rilascio del motore Neptune precedente a questo rilascio.

Se il cluster ha il parametro `AutoMinorVersionUpgrade` impostato su `True`, il cluster verrà aggiornato automaticamente a questo rilascio del motore due o tre settimane dopo la data di questa versione, nel corso di una finestra di manutenzione.

## Aggiornamento a questo rilascio
<a name="engine-releases-1.0.2.2-upgrading"></a>

Amazon Neptune 1.0.2.2 è ora disponibile a livello generale.

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.0.2.2 \
4.     --apply-immediately
```

Per Windows:

```
1. aws neptune modify-db-cluster ^
2.     --db-cluster-identifier (your-neptune-cluster) ^
3.     --engine-version 1.0.2.2 ^
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
<a name="engine-1.0.2.2-test-before-upgrading"></a>

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
<a name="engine-1.0.2.2-snapshot-before-upgrading"></a>

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.0.2.2.R6 (19/02/2021)
<a name="engine-releases-1.0.2.2.R6"></a>

A partire dal 19 febbraio 2021, viene implementata a livello generale la versione del motore 1.0.2.2.R6. Tieni presente che occorrono diversi giorni prima che una nuova versione diventi disponibile in ogni regione.

## Difetti corretti in questo rilascio del motore
<a name="engine-releases-1.0.2.2.R6-defects"></a>
+ Corretto un bug di Gremlin in cui `InternalFailureException` veniva impostata come codice di risposta in determinate circostanze quando si verificava un'`ConcurrentModificationException`.
+ Corretto un bug di Gremlin che, in determinate condizioni, aggiornando edge o vertici poteva causare un'`InternalFailureException` transitoria.

## Versioni di linguaggio di query supportate in questo rilascio
<a name="engine-releases-1.0.2.2.R6-query-versions"></a>

Prima di aggiornare un cluster database alla versione 1.0.2.2.R6, assicurati che il tuo progetto sia compatibile con queste versioni di linguaggio di query:
+ *Versione di Gremlin:* `3.4.8`
+ *Versione di SPARQL:* `1.1`

## Percorsi di aggiornamento al rilascio del motore 1.0.2.2.R6
<a name="engine-releases-1.0.2.2.R6-upgrade-paths"></a>

Se si esegue la versione del motore `1.0.2.2`, il cluster verrà aggiornato automaticamente a questo rilascio di patch durante la finestra di manutenzione successiva.

È possibile aggiornare manualmente qualsiasi rilascio del motore Neptune precedente a questo rilascio.

## Aggiornamento a questo rilascio
<a name="engine-releases-1.0.2.2.R6-upgrading"></a>

Amazon Neptune 1.0.2.2.R6 è ora disponibile a livello generale.

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.0.2.2 \
4.     --apply-immediately
```

Per Windows:

```
1. aws neptune modify-db-cluster ^
2.     --db-cluster-identifier (your-neptune-cluster) ^
3.     --engine-version 1.0.2.2 ^
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
<a name="engine-1.0.2.2.R6-test-before-upgrading"></a>

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
<a name="engine-1.0.2.2.R6-snapshot-before-upgrading"></a>

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.0.2.2.R5 (12/10/2020)
<a name="engine-releases-1.0.2.2.R5"></a>

A partire dal 12 ottobre 2020, viene implementata a livello generale la versione del motore 1.0.2.2.R5. Tieni presente che occorrono diversi giorni prima che una nuova versione diventi disponibile in ogni regione.

## Miglioramenti in questo rilascio del motore
<a name="engine-releases-1.0.2.2.R5-improvements"></a>
+ Miglioramento delle prestazioni per il passaggio `properties()` di Gremlin.
+ Aggiunti dettagli su `BindOp` e `MultiplexerOp` nei rapporti esplicativi e di profilo.
+ Per le risposte alle query SPARQL, aggiunto `charset` all'intestazione Content-Type, per consentire ai client HTTP di riconoscere automaticamente il set di caratteri utilizzato.

## Difetti corretti in questo rilascio del motore
<a name="engine-releases-1.0.2.2.R5-defects"></a>
+ Corretto un bug di SPARQL a causa del quale `CancellationException` non veniva gestita.
+ Corretto un bug di SPARQL a causa del quale le query contenenti opzioni nidificate non funzionavano correttamente.
+ Corretto un bug di SPARQL in LOAD in cui un'`ConcurrentModificationException` poteva causare il blocco di una query.
+ Corretto un bug di SPARQL che impediva di comprimere le risposte alle query con gzip.
+ Corretto un bug di Gremlin nel passaggio `groupBy()`.
+ Corretto un bug di Gremlin relativo all'uso di un passaggio `aggregate()` all'interno di un passaggio `local()`.
+ Corretto un bug di Gremlin relativo all'utilizzo di `bothE()` seguito da un predicato che utilizza valori aggregati.
+ Corretto un bug di Gremlin relativo all'utilizzo del passaggio `bothE()` con il passaggio `repeat()`.
+ Corretta una potenziale perdita di memoria di Gremlin relativa al passaggio `both()`.
+ Corretto un bug in cui mancavano le metriche di richiesta perché un endpoint che terminava con '/' non veniva gestito correttamente.
+ Corretto un bug che poteva generare un'`ThrottlingException` anche quando la coda delle richieste non era piena.
+ Corretto un bug nel recupero dello stato del caricamento quando un caricamento non riesce per un motivo come `LOAD_DATA_FAILED_DUE_TO_FEED_MODIFIED_OR_DELETE`.

## Versioni di linguaggio di query supportate in questo rilascio
<a name="engine-releases-1.0.2.2.R5-query-versions"></a>

Prima di aggiornare un cluster database alla versione 1.0.2.2.R5, assicurati che il tuo progetto sia compatibile con queste versioni di linguaggio di query:
+ *Versione di Gremlin:* `3.4.3`
+ *Versione di SPARQL:* `1.1`

## Percorsi di aggiornamento al rilascio del motore 1.0.2.2.R5
<a name="engine-releases-1.0.2.2.R5-upgrade-paths"></a>

Se si esegue la versione del motore `1.0.2.2`, il cluster verrà aggiornato automaticamente a questo rilascio di patch durante la finestra di manutenzione successiva.

È possibile aggiornare manualmente qualsiasi rilascio del motore Neptune precedente a questo rilascio.

## Aggiornamento a questo rilascio
<a name="engine-releases-1.0.2.2.R5-upgrading"></a>

Amazon Neptune 1.0.2.2.R5 è ora disponibile a livello generale.

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.0.2.2 \
4.     --apply-immediately
```

Per Windows:

```
1. aws neptune modify-db-cluster ^
2.     --db-cluster-identifier (your-neptune-cluster) ^
3.     --engine-version 1.0.2.2 ^
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
<a name="engine-1.0.2.2.R5-test-before-upgrading"></a>

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
<a name="engine-1.0.2.2.R5-snapshot-before-upgrading"></a>

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.0.2.2.R4 (23/07/2020)
<a name="engine-releases-1.0.2.2.R4"></a>

A partire dal 23 luglio 2020, viene implementata a livello generale la versione del motore 1.0.2.2.R4. Tieni presente che occorrono diversi giorni prima che una nuova versione diventi disponibile in ogni regione.

## Miglioramenti in questo rilascio del motore
<a name="engine-releases-1.0.2.2.R4-improvements"></a>
+ Utilizzo della memoria ottimizzato grazie al rilascio più frequente della memoria inutilizzata al sistema operativo.
+ Inoltre, è stato migliorato l'utilizzo della memoria per le query GROUP BY di SPARQL.
+ È stato aumentato il tempo massimo per cui una WebSocket connessione autenticata tramite IAM può rimanere aperta, da 36 ore a 10 giorni.
+ È stata aggiunta la `BufferCacheHitRatio` CloudWatch metrica, che può essere utile per diagnosticare la latenza delle query e ottimizzare i tipi di istanze. Consultare [Parametri di Neptune](cw-metrics.md#cw-metrics-available). 

## Difetti corretti in questo rilascio del motore
<a name="engine-releases-1.0.2.2.R4-defects"></a>
+ È stato corretto un bug nella chiusura di connessioni IAM inattive o scadute. WebSocket Neptune ora invia un frame di chiusura prima di chiudere la connessione.
+ È stato corretto un bug SPARQL nella valutazione delle query contenenti condizioni FILTER and/or EXISTS FILTER NOT EXISTS NOT EXISTS annidate.
+ Corretto un bug di terminazione delle query SPARQL che causava il blocco dei thread sul server in particolari condizioni critiche.
+ Corretto un bug di Gremlin che riguardava Edge pathType nel passaggio `hasLabel`.
+ Corretto un bug di Gremlin da gestire `toV` e `fromV` singolarmente per ogni direzione su `bothE`.
+ Corretto un bug di Gremlin che comportava la scomparsa di sideEffect.

## Versioni di linguaggio di query supportate in questo rilascio
<a name="engine-releases-1.0.2.2.R4-query-versions"></a>

Prima di aggiornare un cluster database alla versione 1.0.2.2.R4, assicurati che il tuo progetto sia compatibile con queste versioni di linguaggio di query:
+ *Versione di Gremlin:* `3.4.3`
+ *Versione di SPARQL:* `1.1`

## Percorsi di aggiornamento al rilascio del motore 1.0.2.2.R4
<a name="engine-releases-1.0.2.2.R4-upgrade-paths"></a>

Se si esegue la versione del motore `1.0.2.2`, il cluster verrà aggiornato automaticamente a questo rilascio di patch durante la finestra di manutenzione successiva.

È possibile aggiornare manualmente qualsiasi rilascio del motore Neptune precedente a questo rilascio.

## Aggiornamento a questo rilascio
<a name="engine-releases-1.0.2.2.R4-upgrading"></a>

Amazon Neptune 1.0.2.2.R4 è ora disponibile a livello generale.

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.0.2.2 \
4.     --apply-immediately
```

Per Windows:

```
1. aws neptune modify-db-cluster ^
2.     --db-cluster-identifier (your-neptune-cluster) ^
3.     --engine-version 1.0.2.2 ^
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
<a name="engine-1.0.2.2.R4-test-before-upgrading"></a>

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
<a name="engine-1.0.2.2.R4-snapshot-before-upgrading"></a>

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.0.2.2.R3 (22/07/2020)
<a name="engine-releases-1.0.2.2.R3"></a>

Il rilascio del motore 1.0.2.2.R3 è stato incorporato nel [rilascio del motore 1.0.2.2.R4](engine-releases-1.0.2.2.R4.md).

# Motore Amazon Neptune versione 1.0.2.2.R2 (02/04/2020)
<a name="engine-releases-1.0.2.2.R2"></a>

A partire dal 02 aprile 2020, viene implementata a livello generale la versione del motore 1.0.2.2.R2. Tieni presente che occorrono diversi giorni prima che una nuova versione diventi disponibile in ogni regione.

## Miglioramenti in questo rilascio del motore
<a name="engine-releases-1.0.2.2.R2-improvements"></a>
+ È ora possibile accodare fino a 64 attività bulk-load, anziché attendere il completamento di una prima di iniziare quella successiva. È inoltre possibile rendere l'esecuzione di una richiesta di caricamento in coda subordinata al completamento di una o più attività di caricamento precedentemente accodate utilizzando il parametro `dependencies` del comando `load`. Consultare [Comando dello strumento di caricamento Neptune](load-api-reference-load.md).
+ Full-text-search l'output può ora essere ordinato (vedi[Parametri per la ricerca full-text](full-text-search-parameters.md)).
+ È ora disponibile un parametro del cluster database per richiamare i flussi Neptune e la funzionalità è stata spostata fuori dalla modalità di laboratorio. Consultare [Abilitazione di Neptune Streams](streams-using-enabling.md).

## Difetti corretti in questo rilascio del motore
<a name="engine-releases-1.0.2.2.R2-defects"></a>
+ Corretto un errore stocastico all'avvio del server che ritardava la creazione dell'istanza.
+ Corretto un problema di ottimizzazione per il quale le istruzioni `BIND` nella query facevano partire l'ottimizzatore con modelli non selettivi nella pianificazione join-order.

## Versioni di linguaggio di query supportate in questo rilascio
<a name="engine-releases-1.0.2.2.R2-query-versions"></a>

Prima di aggiornare un cluster database alla versione 1.0.2.2.R2, assicurati che il tuo progetto sia compatibile con queste versioni di linguaggio di query:
+ *Versione di Gremlin:* `3.4.3`
+ *Versione di SPARQL:* `1.1`

## Percorsi di aggiornamento al rilascio del motore 1.0.2.2.R2
<a name="engine-releases-1.0.2.2.R2-upgrade-paths"></a>

Se si esegue la versione del motore `1.0.2.2`, il cluster verrà aggiornato automaticamente a questo rilascio di patch durante la finestra di manutenzione successiva.

È possibile aggiornare manualmente qualsiasi rilascio del motore Neptune precedente a questo rilascio.

## Aggiornamento a questo rilascio
<a name="engine-releases-1.0.2.2.R2-upgrading"></a>

Amazon Neptune 1.0.2.2.R2 è ora disponibile a livello generale.

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.0.2.2 \
4.     --apply-immediately
```

Per Windows:

```
1. aws neptune modify-db-cluster ^
2.     --db-cluster-identifier (your-neptune-cluster) ^
3.     --engine-version 1.0.2.2 ^
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
<a name="engine-1.0.2.2.R2-test-before-upgrading"></a>

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
<a name="engine-1.0.2.2.R2-snapshot-before-upgrading"></a>

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).