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.0.0 (21/07/2022) A partire dal 21 luglio 2022, viene implementata a livello generale la versione del motore 1.2.0.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) 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.0.0.R2 (14/10/2022)](engine-releases-1.2.0.0.R2.md) + [Rilascio: 1.2.0.0.R3 (15/12/2022)](engine-releases-1.2.0.0.R3.md) + [Rilascio: 1.2.0.0.R4 (29/09/2023)](engine-releases-1.2.0.0.R4.md) ## Nuove caratteristiche in questo rilascio del motore + Aggiunto il supporto per i [database globali](neptune-global-database.md). Un database globale Neptune si estende Regioni AWS su più database ed è costituito da un cluster DB primario in una regione e fino a cinque cluster DB secondari in altre regioni. + Aggiunto il supporto per un controllo degli accessi più granulare nelle policy IAM di Neptune rispetto a quello disponibile in precedenza, sulla base delle azioni del piano dati. Si tratta di un cambiamento radicale in quanto le policy IAM esistenti basate sull'azione `connect` obsoleta devono essere adattate per utilizzare le azioni più granulari del piano dati. Consultare [Tipi di policy IAM](security-iam-access-manage.md#iam-auth-policy). + Maggiore disponibilità delle istanze di lettura In precedenza, al riavvio di un'istanza di scrittura, anche tutte le istanze di lettura nel cluster Neptune venivano riavviate automaticamente. A partire dal rilascio 1.2.0.0 del motore, le istanze di lettura rimangono attive dopo il riavvio di un'istanza di scrittura, il che migliora la disponibilità delle istanze di lettura. Le istanze di lettura possono essere riavviate separatamente per rendere effettive le modifiche ai gruppi di parametri. Consultare [Riavvio di un'istanza database in Amazon Neptune](manage-console-instances-reboot.md). + È stato aggiunto un nuovo parametro del cluster database [neptune\$1streams\$1expiry\$1days](parameters.md#parameters-db-cluster-parameters-neptune_streams_expiry_days) che consente di impostare il numero di giorni in cui i record di flusso vengono conservati sul server prima di essere eliminati. L'intervallo è compreso tra 1 e 90 e il valore predefinito è 7. ## Miglioramenti in questo rilascio del motore + Prestazioni di serializzazione Gremlin migliorate per le query. ByteCode + Neptune ora elabora i predicati di testo utilizzando il motore DFE, per migliorare le prestazioni. + Neptune ora elabora le fasi `limit()` di Gremlin utilizzando il motore DFE, compresi i limiti di attraversamento non terminali e figlio. + È stata modificata la gestione DFE della fase `union()` di Gremlin per integrarlo con altre nuove funzionalità, il che significa che i nodi di riferimento vengono visualizzati nei profili di query come previsto. + Le prestazioni di alcune costose operazioni join all'interno di DFE sono state migliorate fino a un fattore massimo di 5 tramite parallelizzazione. + È stato aggiunto il supporto alla modulazione `by()` per `OrderGlobalStep order(global)` per il motore DFE di Gremlin. + È stata aggiunta la visualizzazione dei valori statici inseriti nei dettagli esplicativi per DFE. + Prestazioni migliorate durante la rimozione dei modelli duplicati. + È stato aggiunto il supporto per la conservazione dell'ordine nel motore DFE di Gremlin. + Sono state migliorate le prestazioni delle query Gremlin con filtri vuoti, come questi: ``` g.V().hasId(P.within([])) ``` ``` g.V().hasId([]) ``` + È stata migliorata la messaggistica di errore nei casi in cui una query SPARQL usa un valore numerico troppo grande affinché Neptune possa rappresentarlo internamente. + Sono state migliorate le prestazioni per l'eliminazione dei vertici con archi associati tramite riduzione delle ricerche negli indici quando i flussi sono disabilitati. + Supporto DFE esteso a più varianti della `has()` fase, in particolare a `hasKey()``hasLabel()`, e ai predicati di range for within. strings/URIs `has()` Questo influisce su query come le seguenti: ``` // hasKey() on properties g.V().properties().hasKey("name") g.V().properties().has(T.key, TextP.startingWith("a")) g.E().properties().hasKey("weight") g.E().properties().hasKey(TextP.containing("t")) // hasLabel() on vertex properties g.V().properties().hasLabel("name") // range predicates on ID and Label fields g.V().has(T.label, gt("person")) g.E().has(T.id, lte("(an ID value)")) ``` + È stata aggiunta una funzione [`join()`](access-graph-opencypher-extensions.md#opencypher-compliance-join-function) di openCypher specifica per Neptune che concatena le stringhe di un elenco in un'unica stringa. + Sono state aggiornate le politiche [gestite da Neptune](security-iam-access-managed-policies.md) per includere le autorizzazioni di accesso ai dati e le autorizzazioni per il nuovo database globale. APIs ## Difetti corretti in questo rilascio del motore + È stato corretto un bug a causa del quale una richiesta HTTP senza un tipo di contenuto specificato aveva automaticamente un esito negativo. + È stato corretto un bug di SPARQL nel sistema di ottimizzazione delle query che impediva l'uso di una chiamata di servizio all'interno di una query. + È stato corretto un bug di SPARQL nel parser Turtle RDF a causa del quale una particolare combinazione di dati Unicode causava un errore. + È stato corretto un bug di SPARQL a causa del quale una particolare combinazione di clausole `GRAPH` e `SELECT` generava risultati delle query errati. + È stato corretto un bug di Gremlin che causava un problema di correttezza per le query che utilizzavano qualsiasi fase di filtro all'interno di una fase di unione, come la seguente: ``` g.V("1").union(hasLabel("person"), out()) ``` + È stato corretto un bug di Gremlin a causa del quale `count()` di `both().simplePath()` comportava il doppio del numero effettivo di risultati restituiti senza `count()`. + È stato corretto un bug di openCypher a causa del quale il server generava un'eccezione di errore per mancata corrispondenza della firma per le richieste Bolt ai cluster con l'autenticazione IAM abilitata. + È stato corretto un bug di openCypher a causa del quale una query che utilizzava HTTP keep-alive poteva essere chiusa erroneamente se inviata dopo una richiesta non riuscita. + È stato corretto un bug di openCypher che poteva causare la generazione di un errore interno quando veniva inviata una query che restituiva un valore costante. + È stato corretto un bug nei dettagli di spiegazione in modo che la sottoquery `Time(ms)` di DFE sommi correttamente i tempi della CPU degli operatori all'interno della sottoquery di DFE. Consulta il seguente di output esplicativo a titolo di esempio: ``` subQuery1 ╔════╤════════╤════════╤═══════════════════════╤═══════════════════════════════════╤══════╤══════════╤═══════════╤═══════╤═══════════╗ ║ ID │ Out #1 │ Out #2 │ Name │ Arguments │ Mode │ Units In │ Units Out │ Ratio │ Time (ms) ║ ╠════╪════════╪════════╪═══════════════════════╪═══════════════════════════════════╪══════╪══════════╪═══════════╪═══════╪═══════════╣ ... ╟────┼────────┼────────┼───────────────────────┼───────────────────────────────────┼──────┼──────────┼───────────┼───────┼───────────╢ ║ 1 │ 2 │ - │ DFEChunkLocalSubQuery │ subQuery=...graph#336e.../graph_1 │ - │ 1 │ 1 │ 1.00 │ 0.38 ║ ║ │ │ │ │ coordinationTime(ms)=0.026 │ │ │ │ │ ║ ╟────┼────────┼────────┼───────────────────────┼───────────────────────────────────┼──────┼──────────┼───────────┼───────┼───────────╢ ... subQuery=...graph#336e.../graph_1 ╔════╤════════╤════════╤═══════════════════════╤═══════════════════════════════════╤══════╤══════════╤═══════════╤═══════╤═══════════╗ ║ ID │ Out #1 │ Out #2 │ Name │ Arguments │ Mode │ Units In │ Units Out │ Ratio │ Time (ms) ║ ╠════╪════════╪════════╪═══════════════════════╪═══════════════════════════════════╪══════╪══════════╪═══════════╪═══════╪═══════════╣ ║ 0 │ 1 │ - │ DFESolutionInjection │ solutions=[?100 -> [-10^^]] │ - │ 0 │ 1 │ 0.00 │ 0.04 ║ ║ │ │ │ │ outSchema=[?100] │ │ │ │ │ ║ ╟────┼────────┼────────┼───────────────────────┼───────────────────────────────────┼──────┼──────────┼───────────┼───────┼───────────╢ ║ 1 │ 3 │ - │ DFERelationalJoin │ joinVars=[] │ - │ 2 │ 1 │ 0.50 │ 0.29 ║ ╟────┼────────┼────────┼───────────────────────┼───────────────────────────────────┼──────┼──────────┼───────────┼───────┼───────────╢ ║ 2 │ 1 │ - │ DFESolutionInjection │ outSchema=[] │ - │ 0 │ 1 │ 0.00 │ 0.01 ║ ╟────┼────────┼────────┼───────────────────────┼───────────────────────────────────┼──────┼──────────┼───────────┼───────┼───────────╢ ║ 3 │ - │ - │ DFEDrain │ - │ - │ 1 │ 0 │ 0.00 │ 0.02 ║ ╚════╧════════╧════════╧═══════════════════════╧═══════════════════════════════════╧══════╧══════════╧═══════════╧═══════╧═══════════╝ ``` I tempi subQuery nell'ultima colonna della tabella più in basso si sommano fino a dare un risultato di 0,36 ms (`.04 + .29 + .01 + .02 = .36`). Quando si aggiunge il tempo di coordinamento per tale sottoquery (`.36 + .026 = .386`), si ottiene un risultato che è vicino al tempo subQuery registrato nell'ultima colonna della tabella più in alto, ossia `0.38` ms. ## Versioni di linguaggio di query supportate in questo rilascio Prima di aggiornare un cluster database alla versione 1.2.0.0, assicurati che il tuo progetto sia compatibile con queste versioni di linguaggio di query: + *Versione meno recente di Gremlin supportata:* `3.5.2` + *Versione più recente di Gremlin supportata:* `3.5.4` + *Versione openCypher:* `Neptune-9.0.20190305-1.0` + *Versione di SPARQL:* `1.1` ## Percorsi di aggiornamento al rilascio del motore 1.2.0.0 Poiché si tratta di un rilascio principale del motore, non è previsto un aggiornamento automatico. Puoi eseguire l'aggiornamento al rilascio `1.2.0.0` solo manualmente, a partire dall'ultimo rilascio di patch del [rilascio 1.1.1.0 del motore](engine-releases-1.1.1.0.md). Prima di poter essere aggiornati a `1.2.0.0`, i rilasci precedenti del motore devono prima essere aggiornati all'ultimo rilascio di `1.1.1.0`. Pertanto, prima di provare a eseguire l'aggiornamento a questo rilascio, verifica che sia in uso il rilascio di patch più recente del rilascio `1.1.1.0`. Se non ne hai la certezza, inizia eseguendo l'aggiornamento al rilascio di patch più recente di `1.1.1.0`. Prima dell'aggiornamento, devi anche creare nuovamente tutti i gruppi di parametri del cluster database personalizzati che usavi con la versione precedente, utilizzando la famiglia di gruppi di parametri `neptune1.2`. Per ulteriori informazioni, consulta [Gruppi di parametri di Amazon Neptune](parameter-groups.md). Se prima esegui l'aggiornamento al rilascio `1.1.1.0` e subito dopo a `1.2.0.0`, è possibile che si verifichi un errore come quello riportato di seguito: ``` 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 (consulta [Gestione del cluster di database Amazon Neptune](cluster-maintenance.md)). ## Aggiornamento a questo rilascio 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.0.0 \ 4. --allow-major-version-upgrade \ 5. --apply-immediately ``` Per Windows: ``` 1. aws neptune modify-db-cluster ^ 2. --db-cluster-identifier (your-neptune-cluster) ^ 3. --engine-version 1.2.0.0 ^ 4. --allow-major-version-upgrade ^ 5. --apply-immediately ``` Invece di `--apply-immediately`, puoi specificare `--no-apply-immediately`. Per eseguire un aggiornamento della versione principale, il parametro è obbligatorio. allow-major-version-upgrade Assicurati inoltre di includere la versione del motore onde evitare che il tuo motore venga aggiornato a una versione diversa. Se il cluster utilizza un gruppo di parametri del cluster personalizzato, assicurati di includere questo parametro per specificarlo: ``` --db-cluster-parameter-group-name (name of the custom DB cluster parameter group) ``` Analogamente, se alcune istanze del cluster utilizzano un gruppo di parametri del database personalizzato, assicurati di includere questo parametro per specificarlo: ``` --db-instance-parameter-group-name (name of the custom instance parameter group) ``` ### Eseguire sempre un test prima dell'aggiornamento Quando viene rilasciata una nuova versione principale o secondaria del motore Neptune, testa sempre le applicazioni Neptune su di essa prima di procedere all'aggiornamento. Anche un aggiornamento secondario potrebbe introdurre nuove funzionalità o comportamenti che possono influire sul codice. Inizia confrontando le pagine delle note di rilascio della versione corrente con quelle della versione di destinazione per valutare se verranno modificate le versioni del linguaggio di query o verranno introdotte altre modifiche che causano interruzioni. Il modo migliore per testare una nuova versione prima di aggiornare il cluster database di produzione è clonare il cluster di produzione affinché il clone esegua la nuova versione del motore. È quindi possibile eseguire query sul clone senza influire sul cluster database di produzione. ### Creare sempre uno snapshot manuale prima dell'aggiornamento Prima di procedere a un aggiornamento, è consigliabile creare sempre uno snapshot manuale del cluster database. Uno snapshot automatico offre solo una protezione a breve termine, mentre uno snapshot manuale rimane disponibile fino a quando non lo elimini esplicitamente. In alcuni casi Neptune crea automaticamente uno snapshot manuale come parte del processo di aggiornamento, ma non è consigliabile farvi affidamento ed è comunque opportuno creare sempre il proprio snapshot manuale. Quando hai la certezza che non sarà necessario ripristinare lo stato precedente all'aggiornamento del cluster di database, puoi eliminare in modo esplicito lo snapshot manuale che hai creato, così come lo snapshot manuale eventualmente creato da Neptune. Se Neptune crea uno snapshot manuale, questo avrà un nome che inizia con `preupgrade`, seguito dal nome del cluster database, dalla versione del motore di origine, dalla versione del motore di destinazione e dalla data. **Nota** Se stai tentando di eseguire l'aggiornamento mentre [è in corso un'azione in sospeso](manage-console-maintaining), potrebbe verificarsi un errore come il seguente: ``` We're sorry, your request to modify DB cluster (cluster identifier) has failed. Cannot modify engine version because instance (instance identifier) is running on an old configuration. Apply any pending maintenance actions on the instance before proceeding with the upgrade. ``` Se riscontri questo errore, attendi il completamento dell'azione in sospeso o attiva immediatamente una finestra di manutenzione per completare l'aggiornamento precedente. Per ulteriori informazioni sull'aggiornamento della versione del motore, consulta [Gestione del cluster di database Amazon Neptune](cluster-maintenance.md). In caso di domande o dubbi, il team di AWS supporto è disponibile nei forum della community e tramite [AWS Premium Support](https://aws.amazon.com/support). # Motore Amazon Neptune versione 1.2.0.0.R4 (29/09/2023) A partire dal 29 settembre 2023, viene implementata a livello generale la versione del motore 1.2.0.0.R4. 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. + Per i cluster DB senza server, è stata modificata l'impostazione della capacità minima a 1,0 NCU e l'impostazione massima valida più bassa a 2,5. NCUs Vedi [Dimensionamento della capacità in un cluster database Neptune Serverless](neptune-serverless-capacity-scaling.md) *(((before release, this change needs to be reflected in the serverless page too))).* ## Difetti corretti in questo rilascio del motore + È stato corretto un bug di OpenCypher a causa del quale le update-and-return query non venivano gestite correttamente. `orderBy` `limit` `skip` + È 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 nella gestione delle transazioni Bolt. + 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. Ad esempio, per query come questa: ``` g.withSideEffect('Neptune#useDFE', true) .V() .as("a") .select("a") .by(out() .limit(1)) ``` + Risolto un bug di Gremlin per cui una query non funzionava perché conteneva troppi TinkerPop passaggi e quindi non veniva risolta. + È stato corretto un bug di Gremlin a causa del quale `order()` non ordinava correttamente gli output di stringa quando alcuni di essi contenevano un carattere di spazio. + È stato corretto un bug di Gremlin a causa del quale poteva verificarsi una perdita di transazioni quando una query veniva inviata come String e conteneva `GroupCountStep`. + È 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 Gremlin a causa del quale l'aggiunta di un arco e delle relative proprietà seguiti da `inV()` o `outV()` causava `InternalFailureException`. + È stato risolto un problema di simultaneità nel livello di archiviazione. ## Versioni di linguaggio di query supportate in questo rilascio Prima di aggiornare un cluster database alla versione 1.2.0.0.R4, assicurati che il tuo progetto sia compatibile con queste versioni di linguaggio di query: + *Versione meno recente di Gremlin supportata:* `3.5.2` + *Versione più recente di Gremlin supportata:* `3.5.6` + *Versione openCypher:* `Neptune-9.0.20190305-1.0` + *Versione di SPARQL:* `1.1` ## Percorsi di aggiornamento al rilascio del motore 1.2.0.0.R4 Se si esegue la versione del motore `1.2.0.0`, il cluster verrà aggiornato automaticamente a questo rilascio di patch durante la finestra di manutenzione successiva. Puoi eseguire l'aggiornamento al rilascio `1.2.0.0` solo manualmente, a partire dall'ultimo rilascio di patch del [rilascio 1.1.1.0 del motore](engine-releases-1.1.1.0.md). Prima di poter essere aggiornati a `1.2.0.0`, i rilasci precedenti del motore devono prima essere aggiornati all'ultimo rilascio di `1.1.1.0`. Se prima esegui l'aggiornamento al rilascio `1.1.1.0` e subito dopo a `1.2.0.0`, è possibile che si verifichi un errore come quello riportato di seguito: ``` 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. ## Aggiornamento a questo rilascio 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.0.0 \ 4. --allow-major-version-upgrade \ 5. --apply-immediately ``` Per Windows: ``` 1. aws neptune modify-db-cluster ^ 2. --db-cluster-identifier (your-neptune-cluster) ^ 3. --engine-version 1.2.0.0 ^ 4. --allow-major-version-upgrade ^ 5. --apply-immediately ``` Invece di `--apply-immediately`, puoi specificare `--no-apply-immediately`. Per eseguire un aggiornamento della versione principale, il allow-major-version-upgrade parametro è obbligatorio. Assicurati inoltre di includere la versione del motore onde evitare che il tuo motore venga aggiornato a una versione diversa. Se il cluster utilizza un gruppo di parametri del cluster personalizzato, assicurati di includere questo parametro per specificarlo: ``` --db-cluster-parameter-group-name (name of the custom DB cluster parameter group) ``` Analogamente, se alcune istanze del cluster utilizzano un gruppo di parametri del database personalizzato, assicurati di includere questo parametro per specificarlo: ``` --db-instance-parameter-group-name (name of the custom instance parameter group) ``` ### Eseguire sempre un test prima dell'aggiornamento Quando viene rilasciata una nuova versione principale o secondaria del motore Neptune, testa sempre le applicazioni Neptune su di essa prima di procedere all'aggiornamento. Anche un aggiornamento secondario potrebbe introdurre nuove funzionalità o comportamenti che possono influire sul codice. Inizia confrontando le pagine delle note di rilascio della versione corrente con quelle della versione di destinazione per valutare se verranno modificate le versioni del linguaggio di query o verranno introdotte altre modifiche che causano interruzioni. Il modo migliore per testare una nuova versione prima di aggiornare il cluster database di produzione è clonare il cluster di produzione affinché il clone esegua la nuova versione del motore. È quindi possibile eseguire query sul clone senza influire sul cluster database di produzione. ### Creare sempre uno snapshot manuale prima dell'aggiornamento Prima di procedere a un aggiornamento, è consigliabile creare sempre uno snapshot manuale del cluster database. Uno snapshot automatico offre solo una protezione a breve termine, mentre uno snapshot manuale rimane disponibile fino a quando non lo elimini esplicitamente. In alcuni casi Neptune crea automaticamente uno snapshot manuale come parte del processo di aggiornamento, ma non è consigliabile farvi affidamento ed è comunque opportuno creare sempre il proprio snapshot manuale. Quando hai la certezza che non sarà necessario ripristinare lo stato precedente all'aggiornamento del cluster di database, puoi eliminare in modo esplicito lo snapshot manuale che hai creato, così come lo snapshot manuale eventualmente creato da Neptune. Se Neptune crea uno snapshot manuale, questo avrà un nome che inizia con `preupgrade`, seguito dal nome del cluster database, dalla versione del motore di origine, dalla versione del motore di destinazione e dalla data. **Nota** Se stai tentando di eseguire l'aggiornamento mentre [è in corso un'azione in sospeso](manage-console-maintaining), potrebbe verificarsi un errore come il seguente: ``` We're sorry, your request to modify DB cluster (cluster identifier) has failed. Cannot modify engine version because instance (instance identifier) is running on an old configuration. Apply any pending maintenance actions on the instance before proceeding with the upgrade. ``` Se riscontri questo errore, attendi il completamento dell'azione in sospeso o attiva immediatamente una finestra di manutenzione per completare l'aggiornamento precedente. Per ulteriori informazioni sull'aggiornamento della versione del motore, consulta [Gestione del cluster di database Amazon Neptune](cluster-maintenance.md). In caso di domande o dubbi, il team di AWS supporto è disponibile nei forum della community e tramite [AWS Premium Support](https://aws.amazon.com/support). # Motore Amazon Neptune versione 1.2.0.0.R3 (15/12/2022) A partire dal 15 dicembre 2022, viene implementata a livello generale la versione del motore 1.2.0.0.R3. 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 + Prestazioni migliorate delle query openCypher che riguardano `MERGE` e `OPTIONAL MATCH`. + Sono state migliorate le prestazioni delle query openCypher che riguardano `UNWIND` di un elenco di mappe di valori letterali. + Prestazioni migliorate delle query openCypher che dispongono di un filtro `IN` per `id`. Per esempio: ``` MATCH (n) WHERE id(n) IN ['1', '2', '3'] RETURN n ``` + Miglioramenti delle prestazioni e correzioni della correttezza per vari operatori Gremlin, tra cui `repeat`, `coalesce`, `store` e `aggregate`. ## Difetti corretti in questo rilascio del motore + È stato corretto un bug di openCypher per cui le query restituivano la stringa `"null"` anziché un valore nullo in Bolt and SPARQL-JSON. + È stato corretto un bug di openCypher in modo da poter interpretare correttamente il tipo di parametro quando il valore è un elenco o un elenco di mappe. + È stato corretto un bug del log di audit che causava la registrazione di informazioni non necessarie e l'assenza di alcuni campi nei log. + È stato corretto un bug del log di audit a causa del quale l'ARN IAM delle richieste HTTP a un cluster database abilitato per IAM non veniva registrato. + È stato corretto un bug relativo alla cache di ricerca in modo da limitare la memoria incrementale utilizzata per le istanze di scrittura nella cache. + È stato corretto un bug relativo alla cache di ricerca che comportava l'impostazione della modalità di sola lettura per la cache di ricerca in caso di errore delle istanze di scrittura. ## Versioni di linguaggio di query supportate in questo rilascio Prima di aggiornare un cluster database alla versione 1.2.0.0.R3, assicurati che il tuo progetto sia compatibile con queste versioni di linguaggio di query: + *Versione meno recente di Gremlin supportata:* `3.5.2` + *Versione più recente di Gremlin supportata:* `3.5.4` + *Versione openCypher:* `Neptune-9.0.20190305-1.0` + *Versione di SPARQL:* `1.1` ## Percorsi di aggiornamento al rilascio del motore 1.2.0.0.R3 Se si esegue la versione del motore `1.2.0.0`, il cluster verrà aggiornato automaticamente a questo rilascio di patch durante la finestra di manutenzione successiva. Puoi eseguire l'aggiornamento al rilascio `1.2.0.0` solo manualmente, a partire dall'ultimo rilascio di patch del [rilascio 1.1.1.0 del motore](engine-releases-1.1.1.0.md). Prima di poter essere aggiornati a `1.2.0.0`, i rilasci precedenti del motore devono prima essere aggiornati all'ultimo rilascio di `1.1.1.0`. Se prima esegui l'aggiornamento al rilascio `1.1.1.0` e subito dopo a `1.2.0.0`, è possibile che si verifichi un errore come quello riportato di seguito: ``` 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. ## Aggiornamento a questo rilascio 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.0.0 \ 4. --allow-major-version-upgrade \ 5. --apply-immediately ``` Per Windows: ``` 1. aws neptune modify-db-cluster ^ 2. --db-cluster-identifier (your-neptune-cluster) ^ 3. --engine-version 1.2.0.0 ^ 4. --allow-major-version-upgrade ^ 5. --apply-immediately ``` Invece di `--apply-immediately`, puoi specificare `--no-apply-immediately`. Per eseguire un aggiornamento della versione principale, il allow-major-version-upgrade parametro è obbligatorio. Assicurati inoltre di includere la versione del motore onde evitare che il tuo motore venga aggiornato a una versione diversa. Se il cluster utilizza un gruppo di parametri del cluster personalizzato, assicurati di includere questo parametro per specificarlo: ``` --db-cluster-parameter-group-name (name of the custom DB cluster parameter group) ``` Analogamente, se alcune istanze del cluster utilizzano un gruppo di parametri del database personalizzato, assicurati di includere questo parametro per specificarlo: ``` --db-instance-parameter-group-name (name of the custom instance parameter group) ``` ### Eseguire sempre un test prima dell'aggiornamento Quando viene rilasciata una nuova versione principale o secondaria del motore Neptune, testa sempre le applicazioni Neptune su di essa prima di procedere all'aggiornamento. Anche un aggiornamento secondario potrebbe introdurre nuove funzionalità o comportamenti che possono influire sul codice. Inizia confrontando le pagine delle note di rilascio della versione corrente con quelle della versione di destinazione per valutare se verranno modificate le versioni del linguaggio di query o verranno introdotte altre modifiche che causano interruzioni. Il modo migliore per testare una nuova versione prima di aggiornare il cluster database di produzione è clonare il cluster di produzione affinché il clone esegua la nuova versione del motore. È quindi possibile eseguire query sul clone senza influire sul cluster database di produzione. ### Creare sempre uno snapshot manuale prima dell'aggiornamento Prima di procedere a un aggiornamento, è consigliabile creare sempre uno snapshot manuale del cluster database. Uno snapshot automatico offre solo una protezione a breve termine, mentre uno snapshot manuale rimane disponibile fino a quando non lo elimini esplicitamente. In alcuni casi Neptune crea automaticamente uno snapshot manuale come parte del processo di aggiornamento, ma non è consigliabile farvi affidamento ed è comunque opportuno creare sempre il proprio snapshot manuale. Quando hai la certezza che non sarà necessario ripristinare lo stato precedente all'aggiornamento del cluster di database, puoi eliminare in modo esplicito lo snapshot manuale che hai creato, così come lo snapshot manuale eventualmente creato da Neptune. Se Neptune crea uno snapshot manuale, questo avrà un nome che inizia con `preupgrade`, seguito dal nome del cluster database, dalla versione del motore di origine, dalla versione del motore di destinazione e dalla data. **Nota** Se stai tentando di eseguire l'aggiornamento mentre [è in corso un'azione in sospeso](manage-console-maintaining), potrebbe verificarsi un errore come il seguente: ``` We're sorry, your request to modify DB cluster (cluster identifier) has failed. Cannot modify engine version because instance (instance identifier) is running on an old configuration. Apply any pending maintenance actions on the instance before proceeding with the upgrade. ``` Se riscontri questo errore, attendi il completamento dell'azione in sospeso o attiva immediatamente una finestra di manutenzione per completare l'aggiornamento precedente. Per ulteriori informazioni sull'aggiornamento della versione del motore, consulta [Gestione del cluster di database Amazon Neptune](cluster-maintenance.md). In caso di domande o dubbi, il team di AWS supporto è disponibile nei forum della community e tramite [AWS Premium Support](https://aws.amazon.com/support). # Motore Amazon Neptune versione 1.2.0.0.R2 (14/10/2022) A partire dal 14 ottobre 2022, viene implementata a livello generale la versione del motore 1.2.0.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 + Sono state migliorate le prestazioni delle query `order-by` Gremlin. Le query Gremlin con `order-by` al termine di un `NeptuneGraphQueryStep` ora utilizzano blocchi di dimensioni superiori per prestazioni migliori. Questo non si applica a `order-by` in un nodo interno (non root) del piano di query. + Sono state migliorate le prestazioni delle query di aggiornamento Gremlin. I vertici e gli archi devono ora essere bloccati per impedirne l'eliminazione durante l'aggiunta di archi o proprietà. Questa modifica elimina i blocchi duplicati all'interno di una transazione, migliorando così le prestazioni. + Sono state migliorate le prestazioni delle query Gremlin che utilizzano `dedup()` all'interno di una sottoquery `repeat()` tramite spostamento di `dedup` verso il basso fino al livello di esecuzione nativo. + È stato aggiunto l'hint per la query `Neptune#cardinalityEstimates` Gremlin. Se impostato su `false`, disabilita le stime di cardinalità. + Sono stati aggiunti messaggi di errore intuitivi per gli errori di autenticazione IAM. Questi messaggi ora mostrano l'utente IAM o l'ARN del ruolo, l'ARN della risorsa e un elenco di azioni non autorizzate per la richiesta. L'elenco delle azioni non autorizzate ti consente di capire cosa potrebbe mancare o essere esplicitamente vietato nella policy IAM che stai utilizzando. ## Difetti corretti in questo rilascio del motore + È stato corretto un bug di correttezza di Gremlin che riguardava la traduzione di `WherePredicateStep`, a causa del quale il motore di query di Neptune generava risultati errati per le query che usano `where(P.neq('x'))` e le relative varianti. + È stato corretto un bug di Gremlin a causa del quale l'utilizzo erroneo `PartitionStrategy` dopo l'aggiornamento alla versione TinkerPop 3.5 generava un errore con il messaggio «non PartitionStrategy funziona con i Traversals anonimi», che impediva l'esecuzione dell'attraversamento. + Sono stati corretti diversi bug di Gremlin relativi al valore `joinTime` di un comando join finale e alle statistiche all'interno dei sottogruppi di `Project.ASK`. + È stato corretto un bug di openCypher nella clausola `MERGE` che in alcuni casi causava la creazione di nodi e archi duplicati. + È stato corretto un bug di transazione a causa del quale una sessione poteva inserire dati dei grafi ed eseguire il commit anche quando i corrispondenti inserimenti simultanei del dizionario venivano ripristinati. + È stato corretto un bug dello strumento di caricamento in blocco che causava regressioni delle prestazioni in caso di ingenti carichi di inserimento. + È stato corretto un bug di SPARQL nella gestione delle query che contengono `(NOT) EXISTS` all'interno di una clausola `OPTIONAL`, a causa del quale in qualche caso mancavano alcuni risultati delle query. + È stato corretto un bug a causa del quale i driver potevano sembrare bloccati nei casi in cui le richieste venivano annullate a causa di un timeout prima dell'avvio della valutazione. Era possibile entrare in questo stato se tutti i thread di elaborazione delle query sul server venivano utilizzati mentre si verificavano dei timeout per gli elementi nella coda delle richieste. Poiché i timeout della coda delle richieste non inviavano messaggi immediatamente, al client sembrava che le risposte restassero in sospeso. ## Versioni di linguaggio di query supportate in questo rilascio Prima di aggiornare un cluster database alla versione 1.2.0.0.R2, assicurati che il tuo progetto sia compatibile con queste versioni di linguaggio di query: + *Versione meno recente di Gremlin supportata:* `3.5.2` + *Versione più recente di Gremlin supportata:* `3.5.4` + *Versione openCypher:* `Neptune-9.0.20190305-1.0` + *Versione di SPARQL:* `1.1` ## Percorsi di aggiornamento al rilascio del motore 1.2.0.0.R2 Se si esegue la versione del motore `1.2.0.0`, il cluster verrà aggiornato automaticamente a questo rilascio di patch durante la finestra di manutenzione successiva. Puoi eseguire l'aggiornamento al rilascio `1.2.0.0` solo manualmente, a partire dall'ultimo rilascio di patch del [rilascio 1.1.1.0 del motore](engine-releases-1.1.1.0.md). Prima di poter essere aggiornati a `1.2.0.0`, i rilasci precedenti del motore devono prima essere aggiornati all'ultimo rilascio di `1.1.1.0`. Se prima esegui l'aggiornamento al rilascio `1.1.1.0` e subito dopo a `1.2.0.0`, è possibile che si verifichi un errore come quello riportato di seguito: ``` 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. ## Aggiornamento a questo rilascio 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.0.0 \ 4. --allow-major-version-upgrade \ 5. --apply-immediately ``` Per Windows: ``` 1. aws neptune modify-db-cluster ^ 2. --db-cluster-identifier (your-neptune-cluster) ^ 3. --engine-version 1.2.0.0 ^ 4. --allow-major-version-upgrade ^ 5. --apply-immediately ``` Invece di `--apply-immediately`, puoi specificare `--no-apply-immediately`. Per eseguire un aggiornamento della versione principale, il parametro è obbligatorio. allow-major-version-upgrade Assicurati inoltre di includere la versione del motore onde evitare che il tuo motore venga aggiornato a una versione diversa. Se il cluster utilizza un gruppo di parametri del cluster personalizzato, assicurati di includere questo parametro per specificarlo: ``` --db-cluster-parameter-group-name (name of the custom DB cluster parameter group) ``` Analogamente, se alcune istanze del cluster utilizzano un gruppo di parametri del database personalizzato, assicurati di includere questo parametro per specificarlo: ``` --db-instance-parameter-group-name (name of the custom instance parameter group) ``` ### Eseguire sempre un test prima dell'aggiornamento Quando viene rilasciata una nuova versione principale o secondaria del motore Neptune, testa sempre le applicazioni Neptune su di essa prima di procedere all'aggiornamento. Anche un aggiornamento secondario potrebbe introdurre nuove funzionalità o comportamenti che possono influire sul codice. Inizia confrontando le pagine delle note di rilascio della versione corrente con quelle della versione di destinazione per valutare se verranno modificate le versioni del linguaggio di query o verranno introdotte altre modifiche che causano interruzioni. Il modo migliore per testare una nuova versione prima di aggiornare il cluster database di produzione è clonare il cluster di produzione affinché il clone esegua la nuova versione del motore. È quindi possibile eseguire query sul clone senza influire sul cluster database di produzione. ### Creare sempre uno snapshot manuale prima dell'aggiornamento Prima di procedere a un aggiornamento, è consigliabile creare sempre uno snapshot manuale del cluster database. Uno snapshot automatico offre solo una protezione a breve termine, mentre uno snapshot manuale rimane disponibile fino a quando non lo elimini esplicitamente. In alcuni casi Neptune crea automaticamente uno snapshot manuale come parte del processo di aggiornamento, ma non è consigliabile farvi affidamento ed è comunque opportuno creare sempre il proprio snapshot manuale. Quando hai la certezza che non sarà necessario ripristinare lo stato precedente all'aggiornamento del cluster di database, puoi eliminare in modo esplicito lo snapshot manuale che hai creato, così come lo snapshot manuale eventualmente creato da Neptune. Se Neptune crea uno snapshot manuale, questo avrà un nome che inizia con `preupgrade`, seguito dal nome del cluster database, dalla versione del motore di origine, dalla versione del motore di destinazione e dalla data. **Nota** Se stai tentando di eseguire l'aggiornamento mentre [è in corso un'azione in sospeso](manage-console-maintaining), potrebbe verificarsi un errore come il seguente: ``` We're sorry, your request to modify DB cluster (cluster identifier) has failed. Cannot modify engine version because instance (instance identifier) is running on an old configuration. Apply any pending maintenance actions on the instance before proceeding with the upgrade. ``` Se riscontri questo errore, attendi il completamento dell'azione in sospeso o attiva immediatamente una finestra di manutenzione per completare l'aggiornamento precedente. Per ulteriori informazioni sull'aggiornamento della versione del motore, consulta [Gestione del cluster di database Amazon Neptune](cluster-maintenance.md). In caso di domande o dubbi, il team di AWS supporto è disponibile nei forum della community e tramite [AWS Premium Support](https://aws.amazon.com/support).