Motore Amazon Neptune versione 1.1.1.0 (19/04/2022)

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

Importante

L'aggiornamento a questo rilascio del motore da una versione precedente alla 1.1.0.0 attiva anche un aggiornamento del sistema operativo su tutte le istanze del cluster database. Poiché le richieste di scrittura attive che si verificano durante l'aggiornamento del sistema operativo non vengono elaborate, è necessario sospendere tutti i carichi di lavoro in scrittura sul cluster da aggiornare, compresi i caricamenti di dati in blocco, prima di avviare l'aggiornamento.

Per completare correttamente l'aggiornamento, ogni sottorete in ciascuna zona di disponibilità (AZ) deve avere almeno un indirizzo IP disponibile per ogni istanza di Neptune. Ad esempio, se ci sono un'istanza di scrittura e due istanze di lettura nella sottorete 1 e due istanze di lettura nella sottorete 2, la sottorete 1 deve avere almeno 3 indirizzi IP liberi e la sottorete 2 deve avere almeno 2 indirizzi IP liberi prima di avviare l'aggiornamento.

All'inizio dell'aggiornamento, Neptune genera uno snapshot con un nome composto da preupgrade seguito da un identificatore generato automaticamente in base alle informazioni del cluster database. Per lo snapshot non ti verrà addebitato alcun costo e potrai utilizzarlo per ripristinare il cluster database in caso di problemi durante il processo di aggiornamento.

La nuova versione del motore (una volta completato il relativo aggiornamento) rimane disponibile per un breve periodo di tempo sul vecchio sistema operativo, ma in meno di 5 minuti tutte le istanze del cluster avviano contemporaneamente un aggiornamento del sistema operativo. A questo punto, il cluster database non sarà disponibile per alcuni minuti. Puoi riprendere i carichi di lavoro in scrittura al termine dell'aggiornamento.

Questo processo genera i seguenti eventi:

• Messaggi di evento per cluster:

  • Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-(autogenerated snapshot ID)]

  • Database cluster major version has been upgraded

• Messaggi di evento per istanza:

  • Applying off-line patches to DB instance

  • DB instance shutdown

  • Finished applying off-line patches to DB instance

  • DB instance restarted

Rilascio di patch successive per questa versione

• Rilascio di manutenzione: 1.1.1.0.R2 (16/05/2022)

• Rilascio: 1.1.1.0.R3 (07/06/2022)

• Rilascio: 1.1.1.0.R4 (23/06/2022)

• Rilascio: 1.1.1.0.R5 (21/07/2022)

• Rilascio: 1.1.1.0.R6 (23/09/2022)

• Rilascio: 1.1.1.0.R7 (23/01/2023)

Nuove caratteristiche in questa versione del motore

• Il linguaggio di query openCypher è ora disponibile a livello generale per l'uso in produzione.

  avvertimento

  In questo rilascio è presente una modifica radicale per il codice che usa openCypher con autenticazione IAM. Nell'anteprima di Neptune per openCypher, la stringa host nella firma IAM includeva il protocollo, come bolt://, ad esempio:

  "Host":"bolt://(host URL):(port)"

  A partire da questo rilascio del motore, il protocollo deve essere omesso:

  "Host":"(host URL):(port)"

  Per esempi, consulta Utilizzo del protocollo Bolt.

• Aggiunto il supporto per TinkerPop 3.5.2. Tra le modifiche inserite in questa versione vi sono la compatibilità con le transazioni remote e il supporto di bytecode per le sessioni (utilizzando g.tx) e l'aggiunta della funzione datetime() al linguaggio Gremlin.

  avvertimento

  Sono state introdotte diverse modifiche radicali in TinkerPop 3.5.0, 3.5.1 e 3.5.2 che potrebbero influire sul codice Gremlin. Ad esempio, non è più possibile utilizzare gli attraversamenti generati da GraphTraversalSource come figlio, come questo: g.V().union(identity(), g.V()).

  Ora invece, viene utilizzato un attraversamento anonimo come questo: g.V().union(identity(), __.V()).

• Aggiunto il supporto per le chiavi di condizione globali AWS da utilizzare nelle policy di accesso ai dati IAM che controllano l'accesso ai dati archiviati in Neptune, un cluster database Neptune.

• Il motore di query Neptune DFE è ora disponibile a livello generale per l'uso in produzione con il linguaggio di query openCypher, ma non ancora per le query Gremlin e SPARQL. Adesso può essere abilitato utilizzando il relativo parametro di istanza neptune_dfe_query_engine anziché il parametro della modalità di laboratorio.

Miglioramenti in questo rilascio del motore

• Sono state aggiunte nuove funzionalità a openCypher, come il supporto per le query parametrizzate, la memorizzazione nella cache dell'albero sintattico astratto (AST) per le query parametrizzate, miglioramenti del percorso a lunghezza variabile (VLP), oltre a nuovi operatori e clausole. Per scoprire il livello attuale di supporto linguistico, consulta openCypher conformità alle specifiche in Amazon Neptune.

• Sono stati apportati miglioramenti significativi alle prestazioni di openCypher per semplici carichi di lavoro in lettura e scrittura, con conseguente aumento della velocità di trasmissione effettiva rispetto al rilascio 1.1.0.0.

• Sono state rimosse le limitazioni bidirezionali e di profondità di openCypher per la gestione dei percorsi a lunghezza variabile.

• È stato completato il supporto nel motore DFE per i predicati within e without di Gremlin, inclusi i casi in cui vengono combinati con altri operatori di predicati. Per esempio:

  g.V().has('age', within(12, 15, 18).or(gt(30)))

• È stato esteso il supporto nel motore DFE per la fase order di Gremlin quando l'ambito è globale (ovvero non order(local)) e quando i modulatori by() non vengono utilizzati. Ad esempio, questa query ora avrebbe il supporto DFE:

   g.V().values("age").order()

• È stato aggiunto un campo isLastOp al formato di risposta del log delle modifiche apportate ai flussi Neptune, per indicare che un record è l'ultima operazione della relativa transazione.

• Sono state significativamente migliorate le prestazioni della registrazione di log di audit ed è stata ridotta la latenza quando la registrazione di log di audit è abilitata.

• Le query HTTP e bytecode WebSocket di Gremlin sono state convertite in un formato leggibile dall'utente nei log di audit. Le query possono ora essere copiate direttamente dai log di audit per essere eseguite nei notebook Neptune e altrove. Nota: questa modifica all'attuale formato dei log di audit rappresenta un cambiamento radicale.

Difetti corretti in questa versione del motore

• È stato corretto un raro bug di Gremlin per cui non veniva restituito alcun risultato quando si utilizzavano in combinazione fasi filter() e count() annidate, come nella seguente query:

  g.V("1").filter(out("knows")
          .filter(in("knows")
          .hasId("notExists"))
          .count())

• È stato corretto un bug di Gremlin in cui veniva restituito un errore quando si utilizzava un vertice archiviato tramite una fase di aggregazione negli attraversamenti to() o from() congiuntamente a una fase addE. Un esempio di query di questo tipo è:

  g.V("id").aggregate("v").out().addE().to(select("v").unfold()))

• È stato corretto un bug di Gremlin a causa del quale la fase not dava esito negativo nei casi limite in cui si utilizzava il motore DFE. Per esempio:

  g.V().not(V())

• È stato corretto un bug di Gremlin a causa del quale i valori sideEffect non erano disponibili all'interno degli attraversamenti to() e from().

• È stato corretto un bug che occasionalmente causava un ripristino rapido per innescare un failover dell'istanza.

• È stato corretto un bug dello strumento di caricamento in blocco a causa del quale una transazione non riuscita non veniva chiusa prima dell'inizio del successivo processo di caricamento.

• È stato corretto un bug dello strumento di caricamento in blocco a causa del quale una condizione di memoria insufficiente poteva causare un arresto anomalo del sistema.

• È stato aggiunto un nuovo tentativo per correggere un bug dello strumento di caricamento in blocco a causa del quale tale strumento non aspettava abbastanza a lungo prima che le credenziali IAM diventassero disponibili dopo un failover.

• È stato corretto un bug a causa del quale la cache interna delle credenziali non veniva cancellata correttamente per gli endpoint non sottoposti a query, come l'endpoint status.

• È stato corretto un bug relativo ai flussi per garantire il corretto ordinamento dei numeri di sequenza del commit dei flussi.

• È stato risolto un bug a causa del quale le connessioni a lunga durata venivano interrotte prima di dieci giorni nei cluster abilitati per IAM.

Versioni di linguaggio di query supportate in questo rilascio

Prima di aggiornare un cluster database alla versione 1.1.1.0, assicurati che il tuo progetto sia compatibile con queste versioni di linguaggio di query:

• Versione meno recente di Gremlin supportata: 3.5.2

• Versione più recente di Gremlin supportata: 3.5.4

• Versione openCypher: Neptune-9.0.20190305-1.0

• Versione di SPARQL: 1.1

Percorsi di aggiornamento al rilascio del motore 1.1.1.0

È possibile aggiornare manualmente qualsiasi rilascio del motore Neptune precedente a questo rilascio. Nota: le versioni precedenti a quella principale del motore (1.1.0.0) impiegheranno più tempo per effettuare l'aggiornamento a questo rilascio.

L'aggiornamento a questo rilascio non viene eseguito automaticamente.

Aggiornamento a questo rilascio

Importante

L'aggiornamento a questo rilascio del motore da qualsiasi versione precedente alla 1.1.0.0 attiva anche un aggiornamento del sistema operativo su tutte le istanze del cluster database. Poiché le richieste di scrittura attive che si verificano durante l'aggiornamento del sistema operativo non vengono elaborate, è necessario sospendere tutti i carichi di lavoro in scrittura sul cluster da aggiornare, compresi i caricamenti di dati in blocco, prima di avviare l'aggiornamento.

All'inizio dell'aggiornamento, Neptune genera uno snapshot con un nome composto da preupgrade seguito da un identificatore generato automaticamente in base alle informazioni del cluster database. Per lo snapshot non ti verrà addebitato alcun costo e potrai utilizzarlo per ripristinare il cluster database in caso di problemi durante il processo di aggiornamento.

La nuova versione del motore (una volta completato il relativo aggiornamento) rimane disponibile per un breve periodo di tempo sul vecchio sistema operativo, ma in meno di 5 minuti tutte le istanze del cluster avviano contemporaneamente un aggiornamento del sistema operativo. A questo punto, il cluster database non sarà disponibile per circa 6 minuti. Puoi riprendere i carichi di lavoro in scrittura al termine dell'aggiornamento.

Questo processo genera i seguenti eventi:

• Messaggi di evento per cluster:

  • Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-(autogenerated snapshot ID)]

  • Database cluster major version has been upgraded

• Messaggi di evento per istanza:

  • Applying off-line patches to DB instance

  • DB instance shutdown

  • Finished applying off-line patches to DB instance

  • DB instance restarted

Se un cluster database utilizza una versione del motore dalla quale esiste un percorso di aggiornamento a questo rilascio, ora è idoneo all'aggiornamento. È possibile aggiornare qualsiasi cluster idoneo utilizzando le operazioni del cluster database sulla console o utilizzando SDK. Il seguente comando CLI aggiornerà immediatamente un cluster idoneo:

Per Linux, OS X o Unix:

aws neptune modify-db-cluster \
    --db-cluster-identifier (your-neptune-cluster) \
    --engine neptune \
    --engine-version 1.1.1.0 \
    --allow-major-version-upgrade \
    --apply-immediately

Per Windows:

aws neptune modify-db-cluster ^
    --db-cluster-identifier (your-neptune-cluster) ^
    --engine neptune ^
    --engine-version 1.1.1.0 ^
    --allow-major-version-upgrade ^
    --apply-immediately

Invece di --apply-immediately, puoi specificare --no-apply-immediately. Per eseguire un aggiornamento di versione principale, è richiesto il parametro 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, 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. In caso di domande o dubbi, il team del supporto AWS è disponibile nei forum della community e tramite il Supporto AWS Premium.