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.2.1.0 (08/03/2023)
A partire dall'8 marzo 2023, viene implementata a livello generale la versione del motore 1.2.1.0. Tieni presente che occorrono diversi giorni prima che una nuova versione diventi disponibile in ogni regione.
**Nota**
**Se si esegue l'aggiornamento da una versione del motore precedente alla 1.2.0.0:**
Il [rilascio del motore 1.2.0.0](engine-releases-1.2.0.0.md) ha introdotto un nuovo formato per i gruppi di parametri personalizzati e i gruppi di parametri del cluster personalizzati. Di conseguenza, se si esegue l'aggiornamento da una versione del motore precedente alla 1.2.0.0 alla versione del motore 1.2.0.0 o successiva, è necessario creare nuovamente tutti i gruppi di parametri personalizzati e i gruppi di parametri del cluster personalizzati esistenti utilizzando la famiglia di gruppi di parametri `neptune1.2`. I rilasci precedenti utilizzavano la famiglia di gruppi di parametri `neptune1` e tali gruppi di parametri non funzionano con il rilascio 1.2.0.0 e successivi. Per ulteriori informazioni, consulta [Gruppi di parametri di Amazon Neptune](parameter-groups.md).
Il rilascio del motore 1.2.0.0 ha inoltre introdotto un nuovo formato per i log di annullamento. Di conseguenza, tutti gli undo log creati da una versione precedente del motore devono essere eliminati e la [`UndoLogsListSize`](cw-metrics.md#cw-metrics-UndoLogListSize) CloudWatch metrica deve scendere a zero prima di poter iniziare qualsiasi aggiornamento da una versione precedente alla 1.2.0.0. Se sono presenti troppi record del log di annullamento (200.000 o più) quando si tenta di avviare un aggiornamento, il tentativo di aggiornamento può raggiungere il timeout in attesa del completamento della rimozione dei log di annullamento.
È possibile accelerare la velocità di rimozione aggiornando l'istanza di scrittura del cluster, ovvero dove si verifica la rimozione. Se si esegue questa operazione prima di provare a eseguire l'aggiornamento, è possibile ridurre il numero di log di annullamento prima dell'avvio. L'aumento delle dimensioni dell'istanza di scrittura a un tipo di istanza 24XL può aumentare la velocità di rimozione fino a oltre un milione di record all'ora.
Se la `UndoLogsListSize` CloudWatch metrica è estremamente ampia, l'apertura di un caso di supporto può aiutarti a esplorare strategie aggiuntive per ridurla.
Infine, nel rilascio 1.2.0.0 è stata introdotta una modifica radicale che influisce sul codice precedente che utilizzava il protocollo Bolt con l'autenticazione IAM. A partire dal rilascio 1.2.0.0, Bolt necessita di un percorso della risorsa per la firma IAM. In Java l'impostazione del percorso della risorsa ha un aspetto simile al seguente: `request.setResourcePath("/openCypher"));`. In altri linguaggi, è possibile aggiungere `/openCypher` all'URI dell'endpoint. Per esempi, consulta [Utilizzo del protocollo Bolt](access-graph-opencypher-bolt.md).
## Rilascio di patch successive per questa versione
+ [Rilascio: 1.2.1.0.R2 (02/05/2023)](engine-releases-1.2.1.0.R2.md)
+ [Rilascio: 1.2.1.0.R3 (13/06/2023)](engine-releases-1.2.1.0.R3.md)
+ [Rilascio: 1.2.1.0.R4 (10/08/2023)](engine-releases-1.2.1.0.R4.md)
+ [Rilascio: 1.2.1.0.R5 (02/09/2023)](engine-releases-1.2.1.0.R5.md)
+ [Rilascio: 1.2.1.0.R6 (12/09/2023)](engine-releases-1.2.1.0.R6.md)
+ [Rilascio: 1.2.1.0.R7 (06/10/2023)](engine-releases-1.2.1.0.R7.md)
## Nuove caratteristiche in questo rilascio del motore
+ È stato aggiunto il supporto per la [TinkerPop versione 3.6.2](https://tinkerpop.apache.org/docs/3.6.2-SNAPSHOT/dev/provider/), che aggiunge molte nuove funzionalità di Gremlin come le nuove funzionalità`mergeV()`,, `mergeE()` e steps. `element()` `fail()` Le fasi `mergeV()` e `mergeE()` sono particolarmente importanti in quanto offrono un'opzione dichiarativa lungamente attesa per l'esecuzione di operazioni di tipo upsert, che dovrebbero semplificare notevolmente i modelli di codice esistenti e rendere Gremlin più facile da leggere. La versione 3.6.x ha anche aggiunto i predicati regex, un nuovo sovraccarico per la fase `property()` che richiede un `Map` e una revisione significativa del comportamento di modulazione di `by()` che diventa molto più coerente in tutte le fasi che lo utilizzano.
Consulta il [registro delle TinkerPop modifiche](https://github.com/apache/tinkerpop/blob/3.6.0/CHANGELOG.asciidoc#release-3-6-0) e la [pagina di aggiornamento](https://tinkerpop.apache.org/docs/current/upgrade/) per informazioni sulle modifiche nella versione 3.6 e sugli aspetti da considerare durante l'aggiornamento.
Se usi `fold().coalesce(unfold(), )` per gli inserimenti condizionali, ti consigliamo di eseguire la migrazione alla nuova sintassi `mergeV/E()`, descritta [qui](https://tinkerpop.apache.org/docs/3.6.0/reference/#mergevertex-step) e [qui](https://tinkerpop.apache.org/docs/3.6.0/reference/#mergeedge-step). Neptune utilizza uno schema di blocco più stretto `Merge` per rispetto a for, che può ridurre le eccezioni di `Coalesce` modifica simultanee (). CMEs
Per ulteriori informazioni sulle nuove funzionalità disponibili in questa TinkerPop versione, consulta il blog di Stephen Mallette, [Exploring new features of Apache TinkerPop 3.6.x in](https://aws.amazon.com/blogs/database/exploring-new-features-of-apache-tinkerpop-3-6-x-in-amazon-neptune/) Amazon Neptune.
+ Aggiunto il supporto per i [tipi di istanza R6i](https://aws.amazon.com/ec2/instance-types/r6i/), basati sui processori Intel Xeon scalabili di terza generazione. Sono la soluzione ideale per carichi di lavoro che richiedono un uso intensivo della memoria e offrono compute/price prestazioni fino al 15% superiori e una larghezza di banda di memoria per vCPU fino al 20% superiore rispetto ai tipi di istanze R5 comparabili.
+ Sono stati aggiunti gli endpoint [API di riepilogo del grafo](neptune-graph-summary.md) sia per i grafi di proprietà che per i grafi RDF, che consentono di ottenere rapidamente un report sul grafico desiderato.
Per i grafi di proprietà (PG), l'API di riepilogo del grafo fornisce un elenco di sola lettura di etichette di nodi e archi, nonché di chiavi di proprietà, insieme al conteggio di nodi, archi e proprietà. Per i grafi RDF, fornisce un elenco di classi e chiavi di predicato, insieme al conteggio di quadruple, soggetti e predicati.
Le seguenti modifiche sono state apportate con la nuova API di riepilogo del grafo:
+ Aggiunta una nuova azione dataplane. [GetGraphSummary](iam-dp-actions.md#getgraphsummary)
+ È stato aggiunto un nuovo endpoint `rdf/statistics` in sostituzione dell'endpoint `sparql/statistics`, che ora è obsoleto.
+ Il nome del campo `summary` nella risposta di stato delle statistiche è stato modificato in `signatureInfo`, così da non confonderlo con le informazioni di riepilogo dei grafi. Le versioni precedenti del motore continuano a usare `summary` nella risposta JSON.
+ È stata modificata la precisione del campo `date` nella risposta di stato delle statistiche, da minuti a millisecondi. Il formato precedente era `2020-05-07T23:13Z` (precisione in minuti), mentre il nuovo formato è `2023-01-24T00:47:43.319Z` (precisione in millisecondi). Entrambi sono conformi allo standard ISO 8601, ma questa modifica può compromettere il codice esistente, a seconda di come viene analizzata la data.
+ È stato aggiunto un nuovo comando magic di riga [`%statistics`](notebooks-magics.md#notebooks-line-magics-statistics) nel Workbench che consente di recuperare le statistiche del motore DFE.
+ È stato aggiunto un nuovo comando magic di riga [`%summary`](notebooks-magics.md#notebooks-line-magics-summary) nel Workbench che consente di recuperare le informazioni di riepilogo dei grafi.
+ È stata aggiunta la [registrazione di log delle query lente](slow-query-logs.md) per registrare i log delle query che richiedono un tempo di esecuzione superiore a una soglia specificata. Puoi abilitare e controllare la registrazione di log delle query lente utilizzando due nuovi parametri dinamici, ossia [neptune\$1enable\$1slow\$1query\$1log](parameters.md#parameters-db-cluster-parameters-neptune_enable_slow_query_log) e [neptune\$1slow\$1query\$1log\$1threshold](parameters.md#parameters-db-cluster-parameters-neptune_slow_query_log_threshold).
+ Aggiunto il supporto per due [parametri dinamici](parameter-groups.md), ossia due nuovi parametri di cluster: [neptune\$1enable\$1slow\$1query\$1log](parameters.md#parameters-db-cluster-parameters-neptune_enable_slow_query_log) e [neptune\$1slow\$1query\$1log\$1threshold](parameters.md#parameters-db-cluster-parameters-neptune_slow_query_log_threshold). Quando si apporta una modifica a un parametro dinamico, questa diventa immediatamente effettiva, senza richiedere il riavvio dell'istanza.
+ Aggiunta una funzione OpenCypher [removeKeyFromMap () specifica per Neptune che rimuove una chiave specificata da una mappa](access-graph-opencypher-extensions.md#opencypher-compliance-removeKeyFromMap-function) e restituisce la nuova mappa risultante.
## Miglioramenti in questo rilascio del motore
+ È stato esteso il supporto Gremlin DFE alle fasi `limit` con ambito locale.
+ È stato aggiunto il supporto alla modulazione `by()` per `DedupGlobalStep` di Gremlin nel motore DFE.
+ È stato aggiunto il supporto DFE per `SelectStep` e `SelectOneStep` di Gremlin.
+ Miglioramenti delle prestazioni e correzioni della correttezza per vari operatori Gremlin, tra cui `repeat`, `coalesce`, `store` e `aggregate`.
+ 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
```
+ È stata aggiunta la possibilità di specificare l'IRI di base per le query SPARQL utilizzando l'istruzione BASE (consulta [IRI di base predefinito per query e aggiornamenti](feature-sparql-compliance.md#opencypher-compliance-default-iri)).
+ È stato ridotto il tempo di attesa per l'elaborazione del caricamento dei caricamenti in blocco edge-only su Gremlin e openCypher.
+ I caricamenti in blocco ora riprendono in modo asincrono al riavvio di Neptune per evitare lunghi tempi di attesa causati da problemi di connettività di Amazon S3 prima dei tentativi non riusciti di riprendere i caricamenti.
+ È stata migliorata la gestione delle query DESCRIBE di SPARQL che hanno l'hint di query [describeMode](sparql-query-hints-for-describe.md#sparql-query-hints-describeMode) impostato su `"CBD"` (descrizione limitata concisa) e che riguardano un numero elevato di nodi vuoti.
## Difetti corretti in questo rilascio del motore
+ È stato corretto un bug di openCypher per cui le query restituivano la stringa `"null"` anziché un valore nullo in Bolt and SPARQL-JSON.
+ È stato corretto un bug di openCypher nella comprensione degli elenchi che generava un valore nullo anziché i valori forniti per gli elementi dell'elenco.
+ È stato corretto un bug di openCypher a causa del quale i valori di byte non venivano serializzati correttamente.
+ È stato corretto un bug di Gremlin in `UnionStep` che si verificava quando un input era un arco che attraversava verso un vertice all'interno di un attraversamento figlio.
+ È stato corretto un bug di Gremlin che impediva la corretta propagazione di un'etichetta di fase associata a `UnionStep` all'ultima fase di ogni attraversamento figlio.
+ È stato corretto un bug di Gremlin relativo alla fase `dedup` con etichette dopo una fase `dedup`, per cui le etichette allegate alla fase `repeat` non erano disponibili per essere utilizzate ulteriormente nella query.
+ È stato corretto un bug di Gremlin a causa del quale la traduzione della fase `repeat` all'interno di una fase `union` non riusciva a causa di un errore interno.
+ Sono stati risolti i problemi di correttezza di Gremlin per le query DFE con `limit` come attraversamento figlio di fasi di non unione tramite ricorso a TinkerPop. Sono coinvolte le query con una forma simile a questa:
```
g.withSideEffect('Neptune#useDFE', true).V().as("a").select("a").by(out().limit(1))
```
+ È stato corretto un bug di SPARQL a causa del quale i modelli `SPARQL GRAPH` non consideravano il set di dati fornito da una clausola `FROM NAMED`.
+ Risolto un bug SPARQL in cui SPARQL `DESCRIBE` con alcune `FROM` and/or `FROM NAMED` clausole non utilizzava sempre correttamente i dati del grafico predefinito e talvolta generava un'eccezione. Consultare [Comportamento di SPARQL DESCRIBE rispetto al grafo predefinito](sparql-default-describe.md).
+ È stato corretto un bug di SPARQL in modo che venga restituito il messaggio di eccezione corretto quando i caratteri nulli vengono rifiutati.
+ Risolto un bug di [spiegazione](sparql-explain.md) in SPARQL che riguardava i piani contenenti un operatore. [PipelinedHashIndexJoin](sparql-explain-operators.md#sparql-explain-operator-pipeline-hash-index-join)
+ È stato corretto un bug che causava la generazione di un errore interno quando veniva inviata una query che restituiva un valore costante.
+ È stato risolto un problema relativo alla logica del rilevatore di deadlock che occasionalmente impediva al motore di rispondere.
## Versioni di linguaggio di query supportate in questo rilascio
Prima di aggiornare un cluster database alla versione 1.2.1.0, assicurati che il tuo progetto sia compatibile con queste versioni di linguaggio di query:
+ *Versione meno recente di Gremlin supportata:* `3.6.2`
+ *Versione più recente di Gremlin supportata:* `3.6.2`
+ *Versione openCypher:* `Neptune-9.0.20190305-1.1`
+ *Versione di SPARQL:* `1.1`
## Percorsi di aggiornamento al rilascio del motore 1.2.1.0
È possibile eseguire manualmente l'aggiornamento a questo rilascio da qualsiasi rilascio precedente del motore Neptune superiore o uguale a [1.1.0.0](engine-releases-1.1.0.0.md).
**Nota**
A partire dal [rilascio 1.2.0.0 del motore](engine-releases-1.2.0.0.md), tutti i gruppi di parametri personalizzati e i gruppi di parametri del cluster personalizzati utilizzati con le versioni del motore precedenti a `1.2.0.0` devono ora essere creati nuovamente utilizzando la famiglia di gruppi di parametri `neptune1.2`. Le versioni precedenti utilizzavano la famiglia di gruppi di parametri `neptune1` e tali gruppi di parametri non funzioneranno con le versioni successive alla `1.2.0.0`. Per ulteriori informazioni, consulta [Gruppi di parametri di Amazon Neptune](parameter-groups.md).
L'aggiornamento a questo rilascio della versione principale non viene eseguito automaticamente.
## Aggiornamento a questo rilascio
Amazon Neptune 1.2.1.0 è 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.2.1.0 \
4. --apply-immediately
```
Per Windows:
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.2.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.2.1.0.R7 (06/10/2023)
A partire dal 6 ottobre 2023, la versione del motore 1.2.1.0.R7 viene implementata a livello generale. Tieni presente che occorrono diversi giorni prima che una nuova versione diventi disponibile in ogni regione.
**Nota**
**Se si esegue l'aggiornamento da una versione del motore precedente alla 1.2.0.0:**
Il [rilascio del motore 1.2.0.0](engine-releases-1.2.0.0.md) ha introdotto un nuovo formato per i gruppi di parametri personalizzati e i gruppi di parametri del cluster personalizzati. Di conseguenza, se si esegue l'aggiornamento da una versione del motore precedente alla 1.2.0.0 alla versione del motore 1.2.0.0 o successiva, è necessario creare nuovamente tutti i gruppi di parametri personalizzati e i gruppi di parametri del cluster personalizzati esistenti utilizzando la famiglia di gruppi di parametri `neptune1.2`. I rilasci precedenti utilizzavano la famiglia di gruppi di parametri `neptune1` e tali gruppi di parametri non funzionano con il rilascio 1.2.0.0 e successivi. Per ulteriori informazioni, consulta [Gruppi di parametri di Amazon Neptune](parameter-groups.md).
Il rilascio del motore 1.2.0.0 ha inoltre introdotto un nuovo formato per i log di annullamento. Di conseguenza, tutti gli undo log creati da una versione precedente del motore devono essere eliminati e la [`UndoLogsListSize`](cw-metrics.md#cw-metrics-UndoLogListSize) CloudWatch metrica deve scendere a zero prima di poter iniziare qualsiasi aggiornamento da una versione precedente alla 1.2.0.0. Se sono presenti troppi record del log di annullamento (200.000 o più) quando si tenta di avviare un aggiornamento, il tentativo di aggiornamento può raggiungere il timeout in attesa del completamento della rimozione dei log di annullamento.
È possibile accelerare la velocità di rimozione aggiornando l'istanza di scrittura del cluster, ovvero dove si verifica la rimozione. Se si esegue questa operazione prima di provare a eseguire l'aggiornamento, è possibile ridurre il numero di log di annullamento prima dell'avvio. L'aumento delle dimensioni dell'istanza di scrittura a un tipo di istanza 24XL può aumentare la velocità di rimozione fino a oltre un milione di record all'ora.
Se la `UndoLogsListSize` CloudWatch metrica è estremamente ampia, l'apertura di un caso di supporto può aiutarti a esplorare strategie aggiuntive per ridurla.
Infine, nel rilascio 1.2.0.0 è stata introdotta una modifica radicale che influisce sul codice precedente che utilizzava il protocollo Bolt con l'autenticazione IAM. A partire dal rilascio 1.2.0.0, Bolt necessita di un percorso della risorsa per la firma IAM. In Java l'impostazione del percorso della risorsa ha un aspetto simile al seguente: `request.setResourcePath("/openCypher"));`. In altri linguaggi, è possibile aggiungere `/openCypher` all'URI dell'endpoint. Per esempi, consulta [Utilizzo del protocollo Bolt](access-graph-opencypher-bolt.md).
## Difetti corretti in questo rilascio del motore
+ È stato risolto un problema a causa del quale, in alcuni casi, una transazione non riuscita non veniva chiusa correttamente.
## Versioni di linguaggio di query supportate in questo rilascio
Prima di aggiornare un cluster database alla versione 1.2.1.0.R7, assicurati che il tuo progetto sia compatibile con queste versioni di linguaggio di query:
+ *Versione meno recente di Gremlin supportata:* `3.6.2`
+ *Versione più recente di Gremlin supportata:* `3.6.2`
+ *Versione openCypher:* `Neptune-9.0.20190305-1.0`
+ *Versione di SPARQL:* `1.1`
## Aggiornamento a questo rilascio
Amazon Neptune 1.2.1.0.R7 è 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.2.1.0 \
4. --apply-immediately
```
Per Windows:
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.2.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.2.1.0.R6 (12/09/2023)
A partire dal 12 settembre 2023, viene implementata a livello generale la versione del motore 1.2.1.0.R6. Tieni presente che occorrono diversi giorni prima che una nuova versione diventi disponibile in ogni regione.
**Nota**
**Se si esegue l'aggiornamento da una versione del motore precedente alla 1.2.0.0:**
Il [rilascio del motore 1.2.0.0](engine-releases-1.2.0.0.md) ha introdotto un nuovo formato per i gruppi di parametri personalizzati e i gruppi di parametri del cluster personalizzati. Di conseguenza, se si esegue l'aggiornamento da una versione del motore precedente alla 1.2.0.0 alla versione del motore 1.2.0.0 o successiva, è necessario creare nuovamente tutti i gruppi di parametri personalizzati e i gruppi di parametri del cluster personalizzati esistenti utilizzando la famiglia di gruppi di parametri `neptune1.2`. I rilasci precedenti utilizzavano la famiglia di gruppi di parametri `neptune1` e tali gruppi di parametri non funzionano con il rilascio 1.2.0.0 e successivi. Per ulteriori informazioni, consulta [Gruppi di parametri di Amazon Neptune](parameter-groups.md).
Il rilascio del motore 1.2.0.0 ha inoltre introdotto un nuovo formato per i log di annullamento. Di conseguenza, tutti gli undo log creati da una versione precedente del motore devono essere eliminati e la [`UndoLogsListSize`](cw-metrics.md#cw-metrics-UndoLogListSize) CloudWatch metrica deve scendere a zero prima di poter iniziare qualsiasi aggiornamento da una versione precedente alla 1.2.0.0. Se sono presenti troppi record del log di annullamento (200.000 o più) quando si tenta di avviare un aggiornamento, il tentativo di aggiornamento può raggiungere il timeout in attesa del completamento della rimozione dei log di annullamento.
È possibile accelerare la velocità di rimozione aggiornando l'istanza di scrittura del cluster, ovvero dove si verifica la rimozione. Se si esegue questa operazione prima di provare a eseguire l'aggiornamento, è possibile ridurre il numero di log di annullamento prima dell'avvio. L'aumento delle dimensioni dell'istanza di scrittura a un tipo di istanza 24XL può aumentare la velocità di rimozione fino a oltre un milione di record all'ora.
Se la `UndoLogsListSize` CloudWatch metrica è estremamente ampia, l'apertura di un caso di supporto può aiutarti a esplorare strategie aggiuntive per ridurla.
Infine, nel rilascio 1.2.0.0 è stata introdotta una modifica radicale che influisce sul codice precedente che utilizzava il protocollo Bolt con l'autenticazione IAM. A partire dal rilascio 1.2.0.0, Bolt necessita di un percorso della risorsa per la firma IAM. In Java l'impostazione del percorso della risorsa ha un aspetto simile al seguente: `request.setResourcePath("/openCypher"));`. In altri linguaggi, è possibile aggiungere `/openCypher` all'URI dell'endpoint. Per esempi, consulta [Utilizzo del protocollo Bolt](access-graph-opencypher-bolt.md).
## Nuove caratteristiche in questo rilascio del motore
+ È stata rilasciata l'[API dei dati di Neptune](data-api.md).
L'API dei dati di Amazon Neptune supporta gli SDK per il caricamento di dati, l'esecuzione di query, l'acquisizione di informazioni sui dati e l'esecuzione di operazioni di machine learning. Supporta i linguaggi di query Gremlin e openCypher in Neptune ed è disponibile in tutti i linguaggi degli SDK. Firma automaticamente le richieste delle API e semplifica enormemente l'integrazione di Neptune nelle applicazioni.
## Difetti corretti in questo rilascio del motore
+ È stato corretto un bug che poteva causare picchi della CPU in caso di carichi elevati quando i log delle query lente erano abilitati.
+ È stato corretto un bug di Gremlin a causa del quale l'aggiunta di un arco e delle relative proprietà seguiti da `inV()` o `outV()` generava una `InternalFailureException`.
+ Sono stati risolti diversi problemi relativi al concatenamento dei ruoli IAM che in alcuni casi causavano una riduzione delle prestazioni dello strumento di caricamento in blocco.
## Versioni di linguaggio di query supportate in questo rilascio
Prima di aggiornare un cluster database alla versione 1.2.1.0.R6, assicurati che il tuo progetto sia compatibile con queste versioni di linguaggio di query:
+ *Versione meno recente di Gremlin supportata:* `3.6.2`
+ *Versione più recente di Gremlin supportata:* `3.6.2`
+ *Versione openCypher:* `Neptune-9.0.20190305-1.0`
+ *Versione di SPARQL:* `1.1`
## Aggiornamento a questo rilascio
Amazon Neptune 1.2.1.0.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.2.1.0 \
4. --apply-immediately
```
Per Windows:
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.2.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.2.1.0.R5 (02/09/2023)
A partire dal 2 settembre 2023, viene implementata a livello generale la versione del motore 1.2.1.0.R5. Tieni presente che occorrono diversi giorni prima che una nuova versione diventi disponibile in ogni regione.
**Nota**
**Se si esegue l'aggiornamento da una versione del motore precedente alla 1.2.0.0:**
Il [rilascio del motore 1.2.0.0](engine-releases-1.2.0.0.md) ha introdotto un nuovo formato per i gruppi di parametri personalizzati e i gruppi di parametri del cluster personalizzati. Di conseguenza, se si esegue l'aggiornamento da una versione del motore precedente alla 1.2.0.0 alla versione del motore 1.2.0.0 o successiva, è necessario creare nuovamente tutti i gruppi di parametri personalizzati e i gruppi di parametri del cluster personalizzati esistenti utilizzando la famiglia di gruppi di parametri `neptune1.2`. I rilasci precedenti utilizzavano la famiglia di gruppi di parametri `neptune1` e tali gruppi di parametri non funzionano con il rilascio 1.2.0.0 e successivi. Per ulteriori informazioni, consulta [Gruppi di parametri di Amazon Neptune](parameter-groups.md).
Il rilascio del motore 1.2.0.0 ha inoltre introdotto un nuovo formato per i log di annullamento. Di conseguenza, tutti gli undo log creati da una versione precedente del motore devono essere eliminati e la [`UndoLogsListSize`](cw-metrics.md#cw-metrics-UndoLogListSize) CloudWatch metrica deve scendere a zero prima di poter iniziare qualsiasi aggiornamento da una versione precedente alla 1.2.0.0. Se sono presenti troppi record del log di annullamento (200.000 o più) quando si tenta di avviare un aggiornamento, il tentativo di aggiornamento può raggiungere il timeout in attesa del completamento della rimozione dei log di annullamento.
È possibile accelerare la velocità di rimozione aggiornando l'istanza di scrittura del cluster, ovvero dove si verifica la rimozione. Se si esegue questa operazione prima di provare a eseguire l'aggiornamento, è possibile ridurre il numero di log di annullamento prima dell'avvio. L'aumento delle dimensioni dell'istanza di scrittura a un tipo di istanza 24XL può aumentare la velocità di rimozione fino a oltre un milione di record all'ora.
Se la `UndoLogsListSize` CloudWatch metrica è estremamente ampia, l'apertura di un caso di supporto può aiutarti a esplorare strategie aggiuntive per ridurla.
Infine, nel rilascio 1.2.0.0 è stata introdotta una modifica radicale che influisce sul codice precedente che utilizzava il protocollo Bolt con l'autenticazione IAM. A partire dal rilascio 1.2.0.0, Bolt necessita di un percorso della risorsa per la firma IAM. In Java l'impostazione del percorso della risorsa ha un aspetto simile al seguente: `request.setResourcePath("/openCypher"));`. In altri linguaggi, è possibile aggiungere `/openCypher` all'URI dell'endpoint. Per esempi, consulta [Utilizzo del protocollo Bolt](access-graph-opencypher-bolt.md).
## Nuove caratteristiche in questo rilascio del motore
+ È stata rilasciata l'[API dei dati di Neptune](data-api.md).
L'API dei dati di Amazon Neptune supporta gli SDK per il caricamento di dati, l'esecuzione di query, l'acquisizione di informazioni sui dati e l'esecuzione di operazioni di machine learning. Supporta i linguaggi di query Gremlin e openCypher in Neptune ed è disponibile in tutti i linguaggi degli SDK. Firma automaticamente le richieste delle API e semplifica enormemente l'integrazione di Neptune nelle applicazioni.
## Difetti corretti in questo rilascio del motore
+ È stato corretto un bug di Gremlin a causa del quale l'aggiunta di un arco e delle relative proprietà seguiti da `inV()` o `outV()` generava una `InternalFailureException`.
+ Sono stati risolti diversi problemi relativi al concatenamento dei ruoli IAM che in alcuni casi causavano una riduzione delle prestazioni dello strumento di caricamento in blocco.
## Versioni di linguaggio di query supportate in questo rilascio
Prima di aggiornare un cluster database alla versione 1.2.1.0.R5, assicurati che il tuo progetto sia compatibile con queste versioni di linguaggio di query:
+ *Versione meno recente di Gremlin supportata:* `3.6.2`
+ *Versione più recente di Gremlin supportata:* `3.6.2`
+ *Versione openCypher:* `Neptune-9.0.20190305-1.0`
+ *Versione di SPARQL:* `1.1`
## Aggiornamento a questo rilascio
Amazon Neptune 1.2.1.0.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.2.1.0 \
4. --apply-immediately
```
Per Windows:
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.2.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.2.1.0.R4 (10/08/2023)
A partire dal 10 agosto 2023, viene implementata a livello generale la versione del motore 1.2.1.0.R4. Tieni presente che occorrono diversi giorni prima che una nuova versione diventi disponibile in ogni regione.
**Importante**
Le modifiche introdotte in questa versione del motore possono in alcuni casi causare un peggioramento delle prestazioni di caricamento in blocco. Di conseguenza, gli aggiornamenti a questo rilascio sono stati temporaneamente sospesi fino alla risoluzione del problema.
**Nota**
**Se si esegue l'aggiornamento da una versione del motore precedente alla 1.2.0.0:**
Il [rilascio del motore 1.2.0.0](engine-releases-1.2.0.0.md) ha introdotto un nuovo formato per i gruppi di parametri personalizzati e i gruppi di parametri del cluster personalizzati. Di conseguenza, se si esegue l'aggiornamento da una versione del motore precedente alla 1.2.0.0 alla versione del motore 1.2.0.0 o successiva, è necessario creare nuovamente tutti i gruppi di parametri personalizzati e i gruppi di parametri del cluster personalizzati esistenti utilizzando la famiglia di gruppi di parametri `neptune1.2`. I rilasci precedenti utilizzavano la famiglia di gruppi di parametri `neptune1` e tali gruppi di parametri non funzionano con il rilascio 1.2.0.0 e successivi. Per ulteriori informazioni, consulta [Gruppi di parametri di Amazon Neptune](parameter-groups.md).
Il rilascio del motore 1.2.0.0 ha inoltre introdotto un nuovo formato per i log di annullamento. Di conseguenza, tutti gli undo log creati da una versione precedente del motore devono essere eliminati e la [`UndoLogsListSize`](cw-metrics.md#cw-metrics-UndoLogListSize) CloudWatch metrica deve scendere a zero prima di poter iniziare qualsiasi aggiornamento da una versione precedente alla 1.2.0.0. Se sono presenti troppi record del log di annullamento (200.000 o più) quando si tenta di avviare un aggiornamento, il tentativo di aggiornamento può raggiungere il timeout in attesa del completamento della rimozione dei log di annullamento.
È possibile accelerare la velocità di rimozione aggiornando l'istanza di scrittura del cluster, ovvero dove si verifica la rimozione. Se si esegue questa operazione prima di provare a eseguire l'aggiornamento, è possibile ridurre il numero di log di annullamento prima dell'avvio. L'aumento delle dimensioni dell'istanza di scrittura a un tipo di istanza 24XL può aumentare la velocità di rimozione fino a oltre un milione di record all'ora.
Se la `UndoLogsListSize` CloudWatch metrica è estremamente ampia, l'apertura di un caso di supporto può aiutarti a esplorare strategie aggiuntive per ridurla.
Infine, nel rilascio 1.2.0.0 è stata introdotta una modifica radicale che influisce sul codice precedente che utilizzava il protocollo Bolt con l'autenticazione IAM. A partire dal rilascio 1.2.0.0, Bolt necessita di un percorso della risorsa per la firma IAM. In Java l'impostazione del percorso della risorsa ha un aspetto simile al seguente: `request.setResourcePath("/openCypher"));`. In altri linguaggi, è possibile aggiungere `/openCypher` all'URI dell'endpoint. Per esempi, consulta [Utilizzo del protocollo Bolt](access-graph-opencypher-bolt.md).
## Miglioramenti in questo rilascio del motore
+ È stato aggiunto il supporto di [GraphSON-1.0](https://tinkerpop.apache.org/docs/3.4.1/dev/io/#graphson) per Gremlin. Per usare GraphSON-1.0, passa `Accept header` con un valore di:
```
application/vnd.gremlin-v1.0+json;types=false
```
## Difetti corretti in questo rilascio del motore
+ È stato corretto un bug di Gremlin a causa del quale si verificava una perdita di transazioni durante il controllo dell'endpoint di stato delle query Gremlin per le query con predicati in attraversamenti figlio per le fasi che non sono elaborate in modo nativo.
+ È stato corretto un bug di openCypher nella gestione delle transazioni Bolt.
+ È stato risolto un problema di simultaneità sul livello di archiviazione che poteva causare un arresto anomalo.
+ È stato corretto un bug nei log delle query lente per assicurarsi che non siano attivi quando sono disabilitati.
## Versioni di linguaggio di query supportate in questo rilascio
Prima di aggiornare un cluster database alla versione 1.2.1.0.R4, assicurati che il tuo progetto sia compatibile con queste versioni di linguaggio di query:
+ *Versione meno recente di Gremlin supportata:* `3.6.2`
+ *Versione più recente di Gremlin supportata:* `3.6.5`
+ *Versione openCypher:* `Neptune-9.0.20190305-1.0`
+ *Versione di SPARQL:* `1.1`
## Percorsi di aggiornamento al rilascio del motore 1.2.1.0.R4
## Aggiornamento a questo rilascio
Amazon Neptune 1.2.1.0.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.2.1.0 \
4. --apply-immediately
```
Per Windows:
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.2.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.2.1.0.R3 (13/06/2023)
A partire dal 13 giugno 2023, viene implementata a livello generale la versione del motore 1.2.1.0.R3. Tieni presente che occorrono diversi giorni prima che una nuova versione diventi disponibile in ogni regione.
**Importante**
Le modifiche introdotte in questa versione del motore possono in alcuni casi causare un peggioramento delle prestazioni di caricamento in blocco. Di conseguenza, gli aggiornamenti a questo rilascio sono stati temporaneamente sospesi fino alla risoluzione del problema.
**Nota**
**Se si esegue l'aggiornamento da una versione del motore precedente alla 1.2.0.0:**
Il [rilascio del motore 1.2.0.0](engine-releases-1.2.0.0.md) ha introdotto un nuovo formato per i gruppi di parametri personalizzati e i gruppi di parametri del cluster personalizzati. Di conseguenza, se si esegue l'aggiornamento da una versione del motore precedente alla 1.2.0.0 alla versione del motore 1.2.0.0 o successiva, è necessario creare nuovamente tutti i gruppi di parametri personalizzati e i gruppi di parametri del cluster personalizzati esistenti utilizzando la famiglia di gruppi di parametri `neptune1.2`. I rilasci precedenti utilizzavano la famiglia di gruppi di parametri `neptune1` e tali gruppi di parametri non funzionano con il rilascio 1.2.0.0 e successivi. Per ulteriori informazioni, consulta [Gruppi di parametri di Amazon Neptune](parameter-groups.md).
Il rilascio del motore 1.2.0.0 ha inoltre introdotto un nuovo formato per i log di annullamento. Di conseguenza, tutti gli undo log creati da una versione precedente del motore devono essere eliminati e la [`UndoLogsListSize`](cw-metrics.md#cw-metrics-UndoLogListSize) CloudWatch metrica deve scendere a zero prima di poter iniziare qualsiasi aggiornamento da una versione precedente alla 1.2.0.0. Se sono presenti troppi record del log di annullamento (200.000 o più) quando si tenta di avviare un aggiornamento, il tentativo di aggiornamento può raggiungere il timeout in attesa del completamento della rimozione dei log di annullamento.
È possibile accelerare la velocità di rimozione aggiornando l'istanza di scrittura del cluster, ovvero dove si verifica la rimozione. Se si esegue questa operazione prima di provare a eseguire l'aggiornamento, è possibile ridurre il numero di log di annullamento prima dell'avvio. L'aumento delle dimensioni dell'istanza di scrittura a un tipo di istanza 24XL può aumentare la velocità di rimozione fino a oltre un milione di record all'ora.
Se la `UndoLogsListSize` CloudWatch metrica è estremamente ampia, l'apertura di un caso di supporto può aiutarti a esplorare strategie aggiuntive per ridurla.
Infine, nel rilascio 1.2.0.0 è stata introdotta una modifica radicale che influisce sul codice precedente che utilizzava il protocollo Bolt con l'autenticazione IAM. A partire dal rilascio 1.2.0.0, Bolt necessita di un percorso della risorsa per la firma IAM. In Java l'impostazione del percorso della risorsa ha un aspetto simile al seguente: `request.setResourcePath("/openCypher"));`. In altri linguaggi, è possibile aggiungere `/openCypher` all'URI dell'endpoint. Per esempi, consulta [Utilizzo del protocollo Bolt](access-graph-opencypher-bolt.md).
## Nuove caratteristiche in questo rilascio del motore
+ Aggiunto il supporto per il caricamento in blocco tra più account utilizzando il [concatenamento dei ruoli IAM](bulk-load-tutorial-chain-roles.md).
## Miglioramenti in questo rilascio del motore
+ È stata migliorata la fase `fail()` di Gremlin volta a distinguere l'eccezione generata a partire da una `InternalFailureException` generica e a garantire che qualsiasi messaggio fornito dall'utente venisse propagato di nuovo al chiamante.
+ Sono state migliorate le ottimizzazioni del motore di query di Gremlin per `store`, `aggregate`, `cap`, `limit` e `hasLabel`.
+ Aggiunto il supporto per le funzioni trigonometriche di openCypher:
+ `acos()`
+ `asin()`
+ `atan()`
+ `atan2()`
+ `cos()`
+ `cot()`
+ `degrees()`
+ `pi()`
+ `radians()`
+ `sin()`
+ `tan()`
+ Aggiunto il supporto per diverse funzioni di aggregazione openCypher:
+ `percentileDisc()`
+ `stDev()`
+ Aggiunto il supporto per la funzione `epochmillis()` di openCypher che converte un `datetime` in `epochmillis`. Per esempio:
```
MATCH (n) RETURN epochMillis(n.someDateTime)
1698972364782
```
+ Aggiunto il supporto per l'operatore modulo di openCypher (`%`).
+ Aggiunto il supporto per lo strumento Static Debug Explain di openCypher.
+ Aggiunto il supporto per la funzione `randomUUID()` di openCypher.
+ Sono state migliorate le prestazioni di openCypher:
+ Sono stati migliorati il parser e il pianificatore di query.
+ È stato migliorato l'utilizzo della CPU nel motore DFE.
+ Sono state migliorate le prestazioni delle query contenenti più clausole di aggiornamento che riutilizzano le stesse variabili. Alcuni esempi sono:
```
MERGE (n {name: 'John'})
or
MERGE (m {name: 'Jim'})
or
MERGE (n)-[:knows {since: 2023}]→(m)
```
+ Sono stati ottimizzati i piani di query per modelli di query multi-hop come:
```
MATCH (n)-->()-->()-->(m)
RETURN n m
```
+ Sono state migliorate le prestazioni dell'inserimento di elenchi e mappe tramite query parametrizzate. Per esempio:
```
UNWIND $idList as id MATCH (n {`~id`: id})
RETURN n.name
```
+ È stata migliorata l'esecuzione delle query contenenti `WITH` facendone una barriera appropriata.
+ È stata eseguita l'ottimizzazione per evitare la materializzazione ridondante dei valori nelle funzioni `Unfold` e di aggregazione.
+ Sono state migliorate le prestazioni delle query SPARQL che contengono un numero elevato di input statici nella clausola `VALUES`, come:
```
SELECT ?n WHERE { VALUES (?name) { ("John") ("Jim") ... many values ... } ?n a ?n_type . ?n ?name . }
```
+ Sono state migliorate le prestazioni delle query CBD SPARQL.
## Difetti corretti in questo rilascio del motore
+ È stato corretto un bug di Gremlin a causa del quale le query di lunga durata con deep nesting causavano un elevato utilizzo della CPU e timeout delle query durante la fase di pianificazione delle query.
+ È stato risolto un bug di Gremlin a causa del quale una `NullPointerException` non valida poteva essere generata quando si utilizzava `mergeV` e `mergeE`.
## Versioni di linguaggio di query supportate in questo rilascio
Prima di aggiornare un cluster database alla versione 1.2.1.0.R3, assicurati che il tuo progetto sia compatibile con queste versioni di linguaggio di query:
+ *Versione meno recente di Gremlin supportata:* `3.6.2`
+ *Versione più recente di Gremlin supportata:* `3.6.2`
+ *Versione openCypher:* `Neptune-9.0.20190305-1.0`
+ *Versione di SPARQL:* `1.1`
## Percorsi di aggiornamento al rilascio del motore 1.2.1.0.R3
## Aggiornamento a questo rilascio
Amazon Neptune 1.2.1.0.R3 è 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.2.1.0 \
4. --apply-immediately
```
Per Windows:
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.2.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.2.1.0.R2 (02/05/2023)
A partire dal 2 maggio 2023, viene implementata a livello generale la versione del motore 1.2.1.0.R2. Tieni presente che occorrono diversi giorni prima che una nuova versione diventi disponibile in ogni regione.
**Nota**
**Se si esegue l'aggiornamento da una versione del motore precedente alla 1.2.0.0:**
Il [rilascio del motore 1.2.0.0](engine-releases-1.2.0.0.md) ha introdotto un nuovo formato per i gruppi di parametri personalizzati e i gruppi di parametri del cluster personalizzati. Di conseguenza, se si esegue l'aggiornamento da una versione del motore precedente alla 1.2.0.0 alla versione del motore 1.2.0.0 o successiva, è necessario creare nuovamente tutti i gruppi di parametri personalizzati e i gruppi di parametri del cluster personalizzati esistenti utilizzando la famiglia di gruppi di parametri `neptune1.2`. I rilasci precedenti utilizzavano la famiglia di gruppi di parametri `neptune1` e tali gruppi di parametri non funzionano con il rilascio 1.2.0.0 e successivi. Per ulteriori informazioni, consulta [Gruppi di parametri di Amazon Neptune](parameter-groups.md).
Il rilascio del motore 1.2.0.0 ha inoltre introdotto un nuovo formato per i log di annullamento. Di conseguenza, tutti gli undo log creati da una versione precedente del motore devono essere eliminati e la [`UndoLogsListSize`](cw-metrics.md#cw-metrics-UndoLogListSize) CloudWatch metrica deve scendere a zero prima di poter iniziare qualsiasi aggiornamento da una versione precedente alla 1.2.0.0. Se sono presenti troppi record del log di annullamento (200.000 o più) quando si tenta di avviare un aggiornamento, il tentativo di aggiornamento può raggiungere il timeout in attesa del completamento della rimozione dei log di annullamento.
È possibile accelerare la velocità di rimozione aggiornando l'istanza di scrittura del cluster, ovvero dove si verifica la rimozione. Se si esegue questa operazione prima di provare a eseguire l'aggiornamento, è possibile ridurre il numero di log di annullamento prima dell'avvio. L'aumento delle dimensioni dell'istanza di scrittura a un tipo di istanza 24XL può aumentare la velocità di rimozione fino a oltre un milione di record all'ora.
Se la `UndoLogsListSize` CloudWatch metrica è estremamente ampia, l'apertura di un caso di supporto può aiutarti a esplorare strategie aggiuntive per ridurla.
Infine, nel rilascio 1.2.0.0 è stata introdotta una modifica radicale che influisce sul codice precedente che utilizzava il protocollo Bolt con l'autenticazione IAM. A partire dal rilascio 1.2.0.0, Bolt necessita di un percorso della risorsa per la firma IAM. In Java l'impostazione del percorso della risorsa ha un aspetto simile al seguente: `request.setResourcePath("/openCypher"));`. In altri linguaggi, è possibile aggiungere `/openCypher` all'URI dell'endpoint. Per esempi, consulta [Utilizzo del protocollo Bolt](access-graph-opencypher-bolt.md).
## Miglioramenti in questo rilascio del motore
+ È stato aggiunto un `enableInterContainerTrafficEncryption` parametro a tutti i [Neptune APIs](machine-learning-api-reference.md) ML, che è possibile utilizzare per abilitare e disabilitare la crittografia del traffico tra container durante i lavori di formazione o di ottimizzazione degli iperparametri.
+ È stato aggiunto il supporto multietichetta per le fasi `mergeV()` e `mergeE()` di Gremlin.
## Difetti corretti in questo rilascio del motore
+ È stato corretto un bug di openCypher a causa del quale le query di aggiornamento e restituzione non gestivano `orderBy`, `limit` o `skip` correttamente.
+ È stato corretto un bug di openCypher che consentiva ai parametri contenuti in una richiesta di essere sovrascritti dai parametri contenuti in un'altra richiesta simultanea.
+ È stato corretto un bug di openCypher in cui i log delle query lente non contenevano i tempi di query corretti.
+ È stato corretto un bug di Gremlin a causa del quale poteva verificarsi una perdita di transazioni quando una query contenente `GroupCountStep` veniva inviata come una stringa.
+ È stato corretto un bug di Gremlin a causa del quale le query non funzionavano quando erano abilitati i log delle WebSocket query lente.
+ È stato corretto un bug di Gremlin a causa del quale i log di debug dello storage-counter mancavano nei log delle query lente per le richieste. WebSocket
+ Sono stati corretti diversi bug di Gremlin che coinvolgevano `mergeV()` e `mergeE()`.
+ È stato corretto un bug SPARQL a causa del quale i costi delle query con grafici denominati venivano erroneamente stimati, con conseguenti errori e piani di interrogazione non ottimali. out-of-memory
+ È stato corretto un bug che influiva sull'autorizzazione per le query Gremlin e openCypher su un cluster abilitato per IAM.
## Versioni di linguaggio di query supportate in questo rilascio
Prima di aggiornare un cluster database alla versione 1.2.1.0.R2, assicurati che il tuo progetto sia compatibile con queste versioni di linguaggio di query:
+ *Versione meno recente di Gremlin supportata:* `3.6.2`
+ *Versione più recente di Gremlin supportata:* `3.6.2`
+ *Versione openCypher:* `Neptune-9.0.20190305-1.0`
+ *Versione di SPARQL:* `1.1`
## Percorsi di aggiornamento al rilascio del motore 1.2.1.0.R2
## Aggiornamento a questo rilascio
Amazon Neptune 1.2.1.0.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.2.1.0 \
4. --apply-immediately
```
Per Windows:
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.2.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).