As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Mecanismo do Amazon Neptune versão 1.2.1.0 (08/03/2023)
Desde 08/03/2023, a versão 1.2.1.0 do mecanismo está sendo implantada de forma geral. Observe que leva vários dias para que uma nova versão fique disponível em todas as regiões.
**nota**
**Se estiver fazendo a atualização de uma versão do mecanismo anterior à 1.2.0.0:**
A [versão 1.2.0.0 do mecanismo](engine-releases-1.2.0.0.md) introduziu um novo formato para grupos de parâmetros personalizados e grupos de parâmetros de cluster personalizados. Como resultado, se você estiver atualizando de uma versão de mecanismo anterior à 1.2.0.0 para a versão 1.2.0.0 ou posterior, deverá recriar todos os grupos de parâmetros personalizados e grupos de parâmetros de cluster personalizados existentes usando a família de grupos de parâmetros `neptune1.2`. As versões anteriores usavam a família de grupos de parâmetros `neptune1`, e esses grupos de parâmetros não funcionarão com a versão 1.2.0.0 e posterior. Consulte [Grupos de parâmetros do Amazon Neptune](parameter-groups.md) para obter mais informações.
A versão 1.2.0.0 do mecanismo também introduziu um novo formato para undo logs. Como resultado, todos os undo logs criados por uma versão anterior do mecanismo devem ser eliminados e a métrica [`UndoLogsListSize`](cw-metrics.md#cw-metrics-UndoLogListSize) do CloudWatch deve cair para zero para que seja possível iniciar qualquer atualização de uma versão anterior à 1.2.0.0. Se houver muitos registros de undo logs (duzentos mil ou mais) ao tentar iniciar uma atualização, a tentativa de atualização poderá expirar enquanto aguarda a conclusão da limpeza dos undo logs.
É possível acelerar a taxa de limpeza atualizando a instância de gravador do cluster, que é onde a limpeza ocorre. Fazer isso antes de tentar realizar a atualização pode reduzir o número de undo logs antes de começar. Aumentar o tamanho do gravador para um tipo de instância 24XL pode aumentar a taxa de limpeza para mais de um milhão de registros por hora.
Se a métrica `UndoLogsListSize` do CloudWatch for extremamente grande, abrir um caso de suporte pode ajudar a examinar estratégias adicionais para reduzi-la.
Por fim, houve uma alteração significativa na versão 1.2.0.0. Ela afeta o código anterior que usava o protocolo Bolt com autenticação do IAM. A partir da versão 1.2.0.0, o Bolt precisa de um caminho de recursos para a assinatura do IAM. Em Java, a definição do caminho de recursos pode ser assim: `request.setResourcePath("/openCypher"));`. Em outras linguagens, o `/openCypher` pode ser anexado ao URI do endpoint. Consulte [Usar o protocolo Bolt](access-graph-opencypher-bolt.md) para ver exemplos.
## Versões de patch subsequentes para esta versão
+ [Versão: 1.2.1.0.R2 (02/05/2023)](engine-releases-1.2.1.0.R2.md)
+ [Versão: 1.2.1.0.R3 (13/06/2023)](engine-releases-1.2.1.0.R3.md)
+ [Versão: 1.2.1.0.R4 (10/08/2023)](engine-releases-1.2.1.0.R4.md)
+ [Versão: 1.2.1.0.R5 (02/09/2023)](engine-releases-1.2.1.0.R5.md)
+ [Versão: 1.2.1.0.R6 (12/09/2023)](engine-releases-1.2.1.0.R6.md)
+ [Versão: 1.2.1.0.R7 (06/10/2023)](engine-releases-1.2.1.0.R7.md)
## Novos recursos nesta versão do mecanismo
+ Adição de suporte para o [TinkerPop 3.6.2](https://tinkerpop.apache.org/docs/3.6.2-SNAPSHOT/dev/provider/), que adiciona vários novos atributos do Gremlin, como as novas etapas `mergeV()`, `mergeE()`, `element()` e `fail()`. As etapas `mergeV()` e `mergeE()` são particularmente importantes, pois oferecem uma opção declarativa há muito esperada para realizar operações do tipo upsert, o que deve simplificar bastante os padrões de código existentes e facilitar a leitura do Gremlin. A versão 3.6.x também adicionou predicados regex, uma nova sobrecarga à etapa `property()` que precisa de uma `Map` e uma grande revisão do comportamento da modulação `by()` que é muito mais consistente em todas as etapas que a utilizam.
Consulte a [TinkerPop change log](https://github.com/apache/tinkerpop/blob/3.6.0/CHANGELOG.asciidoc#release-3-6-0) e de [atualização](https://tinkerpop.apache.org/docs/current/upgrade/) para obter informações sobre as alterações na versão 3.6 e fatores a serem considerados ao realizar a atualização.
Se você estiver usando `fold().coalesce(unfold(), )` para inserções condicionais, recomendamos migrar para a nova sintaxe `mergeV/E()`, descrita [aqui](https://tinkerpop.apache.org/docs/3.6.0/reference/#mergevertex-step) e [aqui](https://tinkerpop.apache.org/docs/3.6.0/reference/#mergeedge-step). O Neptune usa um padrão de bloqueio mais estreito para `Merge` do que para `Coalesce`, o que pode reduzir as exceções de modificação simultânea (CMEs).
Para obter mais informações sobre os novos atributos disponíveis nesta versão do TinkerPop, consulte o blog de Stephen Mallette, [Exploring new features of Apache TinkerPop 3.6.x in Amazon Neptune](https://aws.amazon.com/blogs/database/exploring-new-features-of-apache-tinkerpop-3-6-x-in-amazon-neptune/).
+ Adição de suporte para [tipos de instância R6i](https://aws.amazon.com/ec2/instance-types/r6i/), equipados com processadores escaláveis Intel Xeon de terceira geração. Eles são ideais para workloads com uso intenso de memória e oferecem relação de computação/preço até 15% melhor e largura de banda de memória até 20% maior por vCPU do que tipos de instância R5 comparáveis.
+ Adição de endpoints de [API de resumo de grafos](neptune-graph-summary.md) para grafos de propriedades e do RDF, que permitem que você obtenha um relatório resumido rápido sobre o grafo.
Para grafos de propriedades (PG), a API de resumo de grafos gera uma lista somente leitura de rótulos de nós e bordas e chaves de propriedade, junto com contagens de nós, bordas e propriedades. Para grafos do RDF, ela fornece uma lista de classes e chaves de predicados, junto com contagens de quadrantes, assuntos e predicados.
As seguintes alterações foram realizadas com nova API de resumo de grafos:
+ Adição de uma nova ação de plano de dados [GetGraphSummary](iam-dp-actions.md#getgraphsummary).
+ Adição de um novo endpoint `rdf/statistics` para substituir o endpoint `sparql/statistics` que agora está obsoleto.
+ Alteração do nome do campo `summary` na resposta do status das estatísticas para `signatureInfo`, para não confundi-lo com as informações de resumo dos grafos. As versões anteriores do mecanismo continuam usando `summary` na resposta JSON.
+ Alteração da precisão do campo `date` na resposta do status das estatísticas de minuto para milissegundo. O formato anterior era `2020-05-07T23:13Z` (precisão de minutos), enquanto o novo formato é `2023-01-24T00:47:43.319Z` (precisão de milissegundos). Os dois são compatíveis com a ISO 8601, mas essa alteração pode romper o código existente, dependendo de como a data está sendo analisada.
+ Adição de uma nova magia de linha [`%statistics`](notebooks-magics.md#notebooks-line-magics-statistics) à bancada de trabalho que permite recuperar estatísticas do mecanismo do DFE.
+ Adição de uma nova magia de linha [`%summary`](notebooks-magics.md#notebooks-line-magics-summary) à bancada de trabalho que permite recuperar informações de resumo dos grafos.
+ Adição do [registro em log de consultas lentas](slow-query-logs.md) para registrar consultas que demoram mais do que um limite especificado para serem executadas. Você ativa e controla o registro em log de consultas lentas usando os dois novos parâmetros dinâmicos, a saber, [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).
+ Adição de suporte para dois [parâmetros dinâmicos](parameter-groups.md), a saber, os novos parâmetros de 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). Ao fazer uma alteração em um parâmetro dinâmico, ela tem efeito imediatamente, sem a necessidade de reinicializar a instância.
+ Adição de uma função [removeKeyFromMap()](access-graph-opencypher-extensions.md#opencypher-compliance-removeKeyFromMap-function) do openCypher específica do Neptune que remove uma chave especificada de um mapa e exibe o novo mapa resultante.
## Melhorias nesta versão do mecanismo
+ Extensão do suporte ao DFE do Gremlin para etapas `limit` com escopo local.
+ Adição de suporte de modulação `by()` para `DedupGlobalStep` do Gremlin no mecanismo do DFE.
+ Adição de suporte do DFE para `SelectStep` e `SelectOneStep` do Gremlin.
+ Melhorias no desempenho e correções para vários operadores do Gremlin, incluindo `repeat`, `coalesce`, `store` e `aggregate`.
+ Melhoria no desempenho das consultas do openCypher que envolvem `MERGE` e `OPTIONAL MATCH`.
+ Melhoria no desempenho das consultas do openCypher que envolvem `UNWIND` de uma lista de mapas de valores literais.
+ Melhoria no desempenho das consultas do openCypher que têm um filtro `IN` para `id`. Por exemplo:
```
MATCH (n) WHERE id(n) IN ['1', '2', '3'] RETURN n
```
+ Adição da capacidade de especificar o IRI básico para consultas do SPARQL usando a declaração BASE (consulte [IRI de base padrão para consultas e atualizações](feature-sparql-compliance.md#opencypher-compliance-default-iri)).
+ Redução do tempo de espera do processamento de carga para carregamentos em massa somente de bordas do Gremlin e do openCypher.
+ Os carregamentos em massa agora são retomados de forma assíncrona quando o Neptune é reiniciado para evitar um longo tempo de espera causado por problemas de conectividade do Amazon S3 antes de falhar nas tentativas de retomada.
+ Melhoria no tratamento das consultas SPARQL DESCRIBE que têm a dica de consulta [describeMode](sparql-query-hints-for-describe.md#sparql-query-hints-describeMode) definida como `"CBD"` (descrição concisa limitada) e que envolvem um grande número de nós em branco.
## Defeitos corrigidos nesta versão do mecanismo
+ Correção de um erro do openCypher em que as consultas geravam uma string, `"null"`, em vez de um valor nulo em Bolt e SPARQL-JSON.
+ Correção de um erro do openCypher na compreensão de lista que produzia um valor nulo em vez dos valores fornecidos para os elementos da lista.
+ Correção de um erro do openCypher em que os valores de bytes não eram serializados corretamente.
+ Correção de um erro do Gremlin em `UnionStep` que ocorria quando uma entrada era uma borda atravessando um vértice em um percurso secundário.
+ Correção de um erro do Gremlin que fazia com que um rótulo de etapa associado a `UnionStep` não se propagasse corretamente até a última etapa de cada percurso secundário.
+ Correção de um erro do Gremlin na etapa `dedup` com rótulos após uma etapa `repeat`, em que os rótulos anexados à etapa `dedup` não estavam disponíveis para uso posterior na consulta.
+ Correção de um erro do Gremlin em que a conversão da etapa `repeat` dentro de uma etapa `union` falhava com um erro interno.
+ Correção dos problemas de exatidão do Gremlin para consultas do DFE com `limit` como percurso filho de etapas que não são de junção retornando ao Tinkerpop. Consultas em um formato como este são afetadas:
```
g.withSideEffect('Neptune#useDFE', true).V().as("a").select("a").by(out().limit(1))
```
+ Correção de um erro do SPARQL em que os padrões `SPARQL GRAPH` não consideravam o conjunto de dados fornecido por uma cláusula `FROM NAMED`.
+ Correção de um erro do SPARQL em que `DESCRIBE` do SPARQL com algumas cláusulas `FROM` e/ou `FROM NAMED` nem sempre usava corretamente os dados de grafos padrão e às vezes gerava uma exceção. Consulte [Comportamento do SPARQL DESCRIBE em relação ao grafo padrão](sparql-default-describe.md).
+ Correção de um erro do SPARQL para que a mensagem de exceção correta fosse exibida quando caracteres nulos fossem rejeitados.
+ Correção de um erro de [explain](sparql-explain.md) do SPARQL que afetava os planos que continham um operador [PipelinedHashIndexJoin](sparql-explain-operators.md#sparql-explain-operator-pipeline-hash-index-join).
+ Correção de um erro que causava um erro interno quando uma consulta que gerava um valor constante era enviada.
+ Correção de um problema com a lógica do detector de deadlock que ocasionalmente fazia com que o mecanismo parasse de responder.
## Versões de linguagem de consulta compatíveis com esta versão
Antes de atualizar um cluster de banco de dados para a versão 1.2.1.0, assegure-se de que o projeto seja compatível com estas versões da linguagem de consulta:
+ *Versão compatível mais antiga do Gremlin:* `3.6.2`
+ *Versão compatível mais recente do Gremlin:* `3.6.2`
+ *openCypher versão:* `Neptune-9.0.20190305-1.1`
+ *SPARQL versão:* `1.1`
## Caminhos de atualização para a versão 1.2.1.0 do mecanismo
É possível atualizar manualmente qualquer versão anterior do mecanismo do Neptune maior ou igual a [1.1.0.0](engine-releases-1.1.0.0.md) para esta versão.
**nota**
A partir da [versão 1.2.0.0 do mecanismo](engine-releases-1.2.0.0.md), todos os grupos de parâmetros personalizados e os grupos de parâmetros de cluster personalizados utilizados com versões do mecanismo anteriores à `1.2.0.0` agora devem ser recriados usando a família de grupos de parâmetros `neptune1.2`. As versões anteriores usavam a família de grupos de parâmetros `neptune1`, e esses grupos de parâmetros não funcionarão com versões a partir de `1.2.0.0` em diante. Consulte [Grupos de parâmetros do Amazon Neptune](parameter-groups.md) para obter mais informações.
A atualização para esta versão principal não será automática.
## Atualizar para esta versão
O Amazon Neptune 1.2.1.0 já está disponível ao público em geral.
Se um cluster de banco de dados estiver executando uma versão do mecanismo a partir da qual haja um caminho de atualização para esta versão, ele estará elegível para ser atualizado agora. Você pode atualizar qualquer cluster elegível usando as operações do cluster de banco de dados no console ou usando o SDK. O seguinte comando da CLI atualizará imediatamente um cluster elegível:
Para Linux, OS X ou Unix:
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.2.1.0 \
4. --apply-immediately
```
Para Windows:
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.2.1.0 ^
4. --apply-immediately
```
As atualizações são simultaneamente aplicadas a todas as instâncias em um cluster de banco de dados. Como as atualizações exigem a reinicialização do banco de dados nessas instâncias, ocorrerá um tempo de inatividade de vinte a trinta segundos a alguns minutos. Depois disso, você poderá retomar o uso do cluster de banco de dados.
### Sempre teste antes de fazer a atualização
Quando uma nova versão principal ou secundária do mecanismo do Neptune for lançada, sempre teste as aplicações do Neptune antes de atualizá-la. Mesmo uma atualização secundária pode introduzir novos atributos ou comportamentos que afetem o código.
Comece comparando as páginas de notas da versão atual com as da versão de destino para ver se haverá alterações nas versões da linguagem de consulta ou outras alterações importantes.
A melhor maneira de testar uma nova versão antes de atualizar o cluster de banco de dados de produção é clonar o cluster de produção para que o clone execute a nova versão do mecanismo. Depois, você pode executar consultas no clone sem afetar o cluster de banco de dados de produção.
### Sempre crie um snapshot manual antes de fazer a atualização
Antes de fazer uma atualização, é altamente recomendável sempre criar um snapshot manual do cluster de banco de dados. Ter um snapshot automático só oferece proteção de curto prazo, enquanto um snapshot manual permanece disponível até que você o exclua explicitamente.
Em determinados casos, o Neptune cria um snapshot manual para você como parte do processo de atualização, mas não confie nisso e, em qualquer caso, crie o próprio snapshot manual.
Quando você tiver certeza de que não precisará reverter o cluster de banco de dados para o estado de pré-atualização, poderá excluir explicitamente o snapshot manual criado, bem como o snapshot manual que o Neptune tenha criado. Se o Neptune criar um snapshot manual, ele terá um nome que começa com `preupgrade`, seguido pelo nome do cluster de banco de dados, a versão do mecanismo de origem, a versão do mecanismo de destino e a data.
**nota**
Se você estiver tentando atualizar com [uma ação pendente em andamento](manage-console-maintaining), poderá encontrar um erro como o seguinte:
```
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 você encontrar esse erro, aguarde a conclusão da ação pendente ou acione imediatamente uma janela de manutenção para permitir que a atualização anterior seja concluída.
Para obter mais informações sobre como atualizar a versão do mecanismo, consulte [Manter o cluster de banco de dados do Amazon Neptune](cluster-maintenance.md). Em caso de dúvidas ou preocupações, o AWS Support está disponível nos fóruns da comunidade e por meio do [AWS Premium Support](https://aws.amazon.com/support).
# Mecanismo do Amazon Neptune versão 1.2.1.0.R7 (06/10/2023)
Desde 06/10/2023, a versão 1.2.1.0.R7 do mecanismo está sendo implantada de forma geral. Observe que leva vários dias para que uma nova versão fique disponível em todas as regiões.
**nota**
**Se estiver fazendo a atualização de uma versão do mecanismo anterior à 1.2.0.0:**
A [versão 1.2.0.0 do mecanismo](engine-releases-1.2.0.0.md) introduziu um novo formato para grupos de parâmetros personalizados e grupos de parâmetros de cluster personalizados. Como resultado, se você estiver atualizando de uma versão de mecanismo anterior à 1.2.0.0 para a versão 1.2.0.0 ou posterior, deverá recriar todos os grupos de parâmetros personalizados e grupos de parâmetros de cluster personalizados existentes usando a família de grupos de parâmetros `neptune1.2`. As versões anteriores usavam a família de grupos de parâmetros `neptune1`, e esses grupos de parâmetros não funcionarão com a versão 1.2.0.0 e posterior. Consulte [Grupos de parâmetros do Amazon Neptune](parameter-groups.md) para obter mais informações.
A versão 1.2.0.0 do mecanismo também introduziu um novo formato para undo logs. Como resultado, todos os undo logs criados por uma versão anterior do mecanismo devem ser eliminados e a métrica [`UndoLogsListSize`](cw-metrics.md#cw-metrics-UndoLogListSize) do CloudWatch deve cair para zero para que seja possível iniciar qualquer atualização de uma versão anterior à 1.2.0.0. Se houver muitos registros de undo logs (duzentos mil ou mais) ao tentar iniciar uma atualização, a tentativa de atualização poderá expirar enquanto aguarda a conclusão da limpeza dos undo logs.
É possível acelerar a taxa de limpeza atualizando a instância de gravador do cluster, que é onde a limpeza ocorre. Fazer isso antes de tentar realizar a atualização pode reduzir o número de undo logs antes de começar. Aumentar o tamanho do gravador para um tipo de instância 24XL pode aumentar a taxa de limpeza para mais de um milhão de registros por hora.
Se a métrica `UndoLogsListSize` do CloudWatch for extremamente grande, abrir um caso de suporte pode ajudar a examinar estratégias adicionais para reduzi-la.
Por fim, houve uma alteração significativa na versão 1.2.0.0. Ela afeta o código anterior que usava o protocolo Bolt com autenticação do IAM. A partir da versão 1.2.0.0, o Bolt precisa de um caminho de recursos para a assinatura do IAM. Em Java, a definição do caminho de recursos pode ser assim: `request.setResourcePath("/openCypher"));`. Em outras linguagens, o `/openCypher` pode ser anexado ao URI do endpoint. Consulte [Usar o protocolo Bolt](access-graph-opencypher-bolt.md) para ver exemplos.
## Defeitos corrigidos nesta versão do mecanismo
+ Correção de um erro em que, em alguns casos, uma transação com falha não era fechada corretamente.
## Versões de linguagem de consulta compatíveis com esta versão
Antes de atualizar um cluster de banco de dados para a versão 1.2.1.0.R7, assegure-se de que o projeto seja compatível com estas versões da linguagem de consulta:
+ *Versão compatível mais antiga do Gremlin:* `3.6.2`
+ *Versão compatível mais recente do Gremlin:* `3.6.2`
+ *openCypher versão:* `Neptune-9.0.20190305-1.0`
+ *SPARQL versão:* `1.1`
## Atualizar para esta versão
O Amazon Neptune 1.2.1.0.R7 já está disponível ao público em geral.
Se um cluster de banco de dados estiver executando uma versão do mecanismo a partir da qual haja um caminho de atualização para esta versão, ele estará elegível para ser atualizado agora. Você pode atualizar qualquer cluster elegível usando as operações do cluster de banco de dados no console ou usando o SDK. O seguinte comando da CLI atualizará imediatamente um cluster elegível:
Para Linux, OS X ou Unix:
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.2.1.0 \
4. --apply-immediately
```
Para Windows:
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.2.1.0 ^
4. --apply-immediately
```
As atualizações são simultaneamente aplicadas a todas as instâncias em um cluster de banco de dados. Como as atualizações exigem a reinicialização do banco de dados nessas instâncias, ocorrerá um tempo de inatividade de vinte a trinta segundos a alguns minutos. Depois disso, você poderá retomar o uso do cluster de banco de dados.
### Sempre teste antes de fazer a atualização
Quando uma nova versão principal ou secundária do mecanismo do Neptune for lançada, sempre teste as aplicações do Neptune antes de atualizá-la. Mesmo uma atualização secundária pode introduzir novos atributos ou comportamentos que afetem o código.
Comece comparando as páginas de notas da versão atual com as da versão de destino para ver se haverá alterações nas versões da linguagem de consulta ou outras alterações importantes.
A melhor maneira de testar uma nova versão antes de atualizar o cluster de banco de dados de produção é clonar o cluster de produção para que o clone execute a nova versão do mecanismo. Depois, você pode executar consultas no clone sem afetar o cluster de banco de dados de produção.
### Sempre crie um snapshot manual antes de fazer a atualização
Antes de fazer uma atualização, é altamente recomendável sempre criar um snapshot manual do cluster de banco de dados. Ter um snapshot automático só oferece proteção de curto prazo, enquanto um snapshot manual permanece disponível até que você o exclua explicitamente.
Em determinados casos, o Neptune cria um snapshot manual para você como parte do processo de atualização, mas não confie nisso e, em qualquer caso, crie o próprio snapshot manual.
Quando você tiver certeza de que não precisará reverter o cluster de banco de dados para o estado de pré-atualização, poderá excluir explicitamente o snapshot manual criado, bem como o snapshot manual que o Neptune tenha criado. Se o Neptune criar um snapshot manual, ele terá um nome que começa com `preupgrade`, seguido pelo nome do cluster de banco de dados, a versão do mecanismo de origem, a versão do mecanismo de destino e a data.
**nota**
Se você estiver tentando atualizar com [uma ação pendente em andamento](manage-console-maintaining), poderá encontrar um erro como o seguinte:
```
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 você encontrar esse erro, aguarde a conclusão da ação pendente ou acione imediatamente uma janela de manutenção para permitir que a atualização anterior seja concluída.
Para obter mais informações sobre como atualizar a versão do mecanismo, consulte [Manter o cluster de banco de dados do Amazon Neptune](cluster-maintenance.md). Em caso de dúvidas ou preocupações, o AWS Support está disponível nos fóruns da comunidade e por meio do [AWS Premium Support](https://aws.amazon.com/support).
# Mecanismo do Amazon Neptune versão 1.2.1.0.R6 (12/09/2023)
Desde 12/09/2023, a versão 1.2.1.0.R6 do mecanismo está sendo implantada de forma geral. Observe que leva vários dias para que uma nova versão fique disponível em todas as regiões.
**nota**
**Se estiver fazendo a atualização de uma versão do mecanismo anterior à 1.2.0.0:**
A [versão 1.2.0.0 do mecanismo](engine-releases-1.2.0.0.md) introduziu um novo formato para grupos de parâmetros personalizados e grupos de parâmetros de cluster personalizados. Como resultado, se você estiver atualizando de uma versão de mecanismo anterior à 1.2.0.0 para a versão 1.2.0.0 ou posterior, deverá recriar todos os grupos de parâmetros personalizados e grupos de parâmetros de cluster personalizados existentes usando a família de grupos de parâmetros `neptune1.2`. As versões anteriores usavam a família de grupos de parâmetros `neptune1`, e esses grupos de parâmetros não funcionarão com a versão 1.2.0.0 e posterior. Consulte [Grupos de parâmetros do Amazon Neptune](parameter-groups.md) para obter mais informações.
A versão 1.2.0.0 do mecanismo também introduziu um novo formato para undo logs. Como resultado, todos os undo logs criados por uma versão anterior do mecanismo devem ser eliminados e a métrica [`UndoLogsListSize`](cw-metrics.md#cw-metrics-UndoLogListSize) do CloudWatch deve cair para zero para que seja possível iniciar qualquer atualização de uma versão anterior à 1.2.0.0. Se houver muitos registros de undo logs (duzentos mil ou mais) ao tentar iniciar uma atualização, a tentativa de atualização poderá expirar enquanto aguarda a conclusão da limpeza dos undo logs.
É possível acelerar a taxa de limpeza atualizando a instância de gravador do cluster, que é onde a limpeza ocorre. Fazer isso antes de tentar realizar a atualização pode reduzir o número de undo logs antes de começar. Aumentar o tamanho do gravador para um tipo de instância 24XL pode aumentar a taxa de limpeza para mais de um milhão de registros por hora.
Se a métrica `UndoLogsListSize` do CloudWatch for extremamente grande, abrir um caso de suporte pode ajudar a examinar estratégias adicionais para reduzi-la.
Por fim, houve uma alteração significativa na versão 1.2.0.0. Ela afeta o código anterior que usava o protocolo Bolt com autenticação do IAM. A partir da versão 1.2.0.0, o Bolt precisa de um caminho de recursos para a assinatura do IAM. Em Java, a definição do caminho de recursos pode ser assim: `request.setResourcePath("/openCypher"));`. Em outras linguagens, o `/openCypher` pode ser anexado ao URI do endpoint. Consulte [Usar o protocolo Bolt](access-graph-opencypher-bolt.md) para ver exemplos.
## Novos recursos nesta versão do mecanismo
+ Lançamento da [API de dados do Neptune](data-api.md).
A API de dados do Amazon Neptune é compatível com o SDK para carregar dados, executar consultas, obter informações sobre os dados e executar operações de machine learning. Ela é compatível com as linguagens de consulta Gremlin e openCypher no Neptune e está disponível em todas as linguagens do SDK. Ela assina automaticamente as solicitações da API e simplifica consideravelmente a integração do Neptune às aplicações.
## Defeitos corrigidos nesta versão do mecanismo
+ Correção de um erro que poderia causar picos de CPU sob altas cargas quando os logs de consultas lentas eram habilitados.
+ Correção de um erro do Gremlin em que adicionar uma borda e suas propriedades seguidas por `inV()` ou `outV()` gerava uma `InternalFailureException`.
+ Correção de alguns problemas com o encadeamento de perfis do IAM que causavam degradação no desempenho do carregador em massa em alguns casos.
## Versões de linguagem de consulta compatíveis com esta versão
Antes de atualizar um cluster de banco de dados para a versão 1.2.1.0.R6, assegure-se de que o projeto seja compatível com estas versões da linguagem de consulta:
+ *Versão compatível mais antiga do Gremlin:* `3.6.2`
+ *Versão compatível mais recente do Gremlin:* `3.6.2`
+ *openCypher versão:* `Neptune-9.0.20190305-1.0`
+ *SPARQL versão:* `1.1`
## Atualizar para esta versão
O Amazon Neptune 1.2.1.0.R6 já está disponível ao público em geral.
Se um cluster de banco de dados estiver executando uma versão do mecanismo a partir da qual haja um caminho de atualização para esta versão, ele estará elegível para ser atualizado agora. Você pode atualizar qualquer cluster elegível usando as operações do cluster de banco de dados no console ou usando o SDK. O seguinte comando da CLI atualizará imediatamente um cluster elegível:
Para Linux, OS X ou Unix:
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.2.1.0 \
4. --apply-immediately
```
Para Windows:
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.2.1.0 ^
4. --apply-immediately
```
As atualizações são simultaneamente aplicadas a todas as instâncias em um cluster de banco de dados. Como as atualizações exigem a reinicialização do banco de dados nessas instâncias, ocorrerá um tempo de inatividade de vinte a trinta segundos a alguns minutos. Depois disso, você poderá retomar o uso do cluster de banco de dados.
### Sempre teste antes de fazer a atualização
Quando uma nova versão principal ou secundária do mecanismo do Neptune for lançada, sempre teste as aplicações do Neptune antes de atualizá-la. Mesmo uma atualização secundária pode introduzir novos atributos ou comportamentos que afetem o código.
Comece comparando as páginas de notas da versão atual com as da versão de destino para ver se haverá alterações nas versões da linguagem de consulta ou outras alterações importantes.
A melhor maneira de testar uma nova versão antes de atualizar o cluster de banco de dados de produção é clonar o cluster de produção para que o clone execute a nova versão do mecanismo. Depois, você pode executar consultas no clone sem afetar o cluster de banco de dados de produção.
### Sempre crie um snapshot manual antes de fazer a atualização
Antes de fazer uma atualização, é altamente recomendável sempre criar um snapshot manual do cluster de banco de dados. Ter um snapshot automático só oferece proteção de curto prazo, enquanto um snapshot manual permanece disponível até que você o exclua explicitamente.
Em determinados casos, o Neptune cria um snapshot manual para você como parte do processo de atualização, mas não confie nisso e, em qualquer caso, crie o próprio snapshot manual.
Quando você tiver certeza de que não precisará reverter o cluster de banco de dados para o estado de pré-atualização, poderá excluir explicitamente o snapshot manual criado, bem como o snapshot manual que o Neptune tenha criado. Se o Neptune criar um snapshot manual, ele terá um nome que começa com `preupgrade`, seguido pelo nome do cluster de banco de dados, a versão do mecanismo de origem, a versão do mecanismo de destino e a data.
**nota**
Se você estiver tentando atualizar com [uma ação pendente em andamento](manage-console-maintaining), poderá encontrar um erro como o seguinte:
```
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 você encontrar esse erro, aguarde a conclusão da ação pendente ou acione imediatamente uma janela de manutenção para permitir que a atualização anterior seja concluída.
Para obter mais informações sobre como atualizar a versão do mecanismo, consulte [Manter o cluster de banco de dados do Amazon Neptune](cluster-maintenance.md). Em caso de dúvidas ou preocupações, o AWS Support está disponível nos fóruns da comunidade e por meio do [AWS Premium Support](https://aws.amazon.com/support).
# Mecanismo do Amazon Neptune versão 1.2.1.0.R5 (02/09/2023)
Desde 02/09/2023, a versão 1.2.1.0.R5 do mecanismo está sendo implantada de forma geral. Observe que leva vários dias para que uma nova versão fique disponível em todas as regiões.
**nota**
**Se estiver fazendo a atualização de uma versão do mecanismo anterior à 1.2.0.0:**
A [versão 1.2.0.0 do mecanismo](engine-releases-1.2.0.0.md) introduziu um novo formato para grupos de parâmetros personalizados e grupos de parâmetros de cluster personalizados. Como resultado, se você estiver atualizando de uma versão de mecanismo anterior à 1.2.0.0 para a versão 1.2.0.0 ou posterior, deverá recriar todos os grupos de parâmetros personalizados e grupos de parâmetros de cluster personalizados existentes usando a família de grupos de parâmetros `neptune1.2`. As versões anteriores usavam a família de grupos de parâmetros `neptune1`, e esses grupos de parâmetros não funcionarão com a versão 1.2.0.0 e posterior. Consulte [Grupos de parâmetros do Amazon Neptune](parameter-groups.md) para obter mais informações.
A versão 1.2.0.0 do mecanismo também introduziu um novo formato para undo logs. Como resultado, todos os undo logs criados por uma versão anterior do mecanismo devem ser eliminados e a métrica [`UndoLogsListSize`](cw-metrics.md#cw-metrics-UndoLogListSize) do CloudWatch deve cair para zero para que seja possível iniciar qualquer atualização de uma versão anterior à 1.2.0.0. Se houver muitos registros de undo logs (duzentos mil ou mais) ao tentar iniciar uma atualização, a tentativa de atualização poderá expirar enquanto aguarda a conclusão da limpeza dos undo logs.
É possível acelerar a taxa de limpeza atualizando a instância de gravador do cluster, que é onde a limpeza ocorre. Fazer isso antes de tentar realizar a atualização pode reduzir o número de undo logs antes de começar. Aumentar o tamanho do gravador para um tipo de instância 24XL pode aumentar a taxa de limpeza para mais de um milhão de registros por hora.
Se a métrica `UndoLogsListSize` do CloudWatch for extremamente grande, abrir um caso de suporte pode ajudar a examinar estratégias adicionais para reduzi-la.
Por fim, houve uma alteração significativa na versão 1.2.0.0. Ela afeta o código anterior que usava o protocolo Bolt com autenticação do IAM. A partir da versão 1.2.0.0, o Bolt precisa de um caminho de recursos para a assinatura do IAM. Em Java, a definição do caminho de recursos pode ser assim: `request.setResourcePath("/openCypher"));`. Em outras linguagens, o `/openCypher` pode ser anexado ao URI do endpoint. Consulte [Usar o protocolo Bolt](access-graph-opencypher-bolt.md) para ver exemplos.
## Novos recursos nesta versão do mecanismo
+ Lançamento da [API de dados do Neptune](data-api.md).
A API de dados do Amazon Neptune é compatível com o SDK para carregar dados, executar consultas, obter informações sobre os dados e executar operações de machine learning. Ela é compatível com as linguagens de consulta Gremlin e openCypher no Neptune e está disponível em todas as linguagens do SDK. Ela assina automaticamente as solicitações da API e simplifica consideravelmente a integração do Neptune às aplicações.
## Defeitos corrigidos nesta versão do mecanismo
+ Correção de um erro do Gremlin em que adicionar uma borda e suas propriedades seguidas por `inV()` ou `outV()` gerava uma `InternalFailureException`.
+ Correção de alguns problemas com o encadeamento de perfis do IAM que causavam degradação no desempenho do carregador em massa em alguns casos.
## Versões de linguagem de consulta compatíveis com esta versão
Antes de atualizar um cluster de banco de dados para a versão 1.2.1.0.R5, assegure-se de que o projeto seja compatível com estas versões da linguagem de consulta:
+ *Versão compatível mais antiga do Gremlin:* `3.6.2`
+ *Versão compatível mais recente do Gremlin:* `3.6.2`
+ *openCypher versão:* `Neptune-9.0.20190305-1.0`
+ *SPARQL versão:* `1.1`
## Atualizar para esta versão
O Amazon Neptune 1.2.1.0.R5 já está disponível ao público em geral.
Se um cluster de banco de dados estiver executando uma versão do mecanismo a partir da qual haja um caminho de atualização para esta versão, ele estará elegível para ser atualizado agora. Você pode atualizar qualquer cluster elegível usando as operações do cluster de banco de dados no console ou usando o SDK. O seguinte comando da CLI atualizará imediatamente um cluster elegível:
Para Linux, OS X ou Unix:
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.2.1.0 \
4. --apply-immediately
```
Para Windows:
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.2.1.0 ^
4. --apply-immediately
```
As atualizações são simultaneamente aplicadas a todas as instâncias em um cluster de banco de dados. Como as atualizações exigem a reinicialização do banco de dados nessas instâncias, ocorrerá um tempo de inatividade de vinte a trinta segundos a alguns minutos. Depois disso, você poderá retomar o uso do cluster de banco de dados.
### Sempre teste antes de fazer a atualização
Quando uma nova versão principal ou secundária do mecanismo do Neptune for lançada, sempre teste as aplicações do Neptune antes de atualizá-la. Mesmo uma atualização secundária pode introduzir novos atributos ou comportamentos que afetem o código.
Comece comparando as páginas de notas da versão atual com as da versão de destino para ver se haverá alterações nas versões da linguagem de consulta ou outras alterações importantes.
A melhor maneira de testar uma nova versão antes de atualizar o cluster de banco de dados de produção é clonar o cluster de produção para que o clone execute a nova versão do mecanismo. Depois, você pode executar consultas no clone sem afetar o cluster de banco de dados de produção.
### Sempre crie um snapshot manual antes de fazer a atualização
Antes de fazer uma atualização, é altamente recomendável sempre criar um snapshot manual do cluster de banco de dados. Ter um snapshot automático só oferece proteção de curto prazo, enquanto um snapshot manual permanece disponível até que você o exclua explicitamente.
Em determinados casos, o Neptune cria um snapshot manual para você como parte do processo de atualização, mas não confie nisso e, em qualquer caso, crie o próprio snapshot manual.
Quando você tiver certeza de que não precisará reverter o cluster de banco de dados para o estado de pré-atualização, poderá excluir explicitamente o snapshot manual criado, bem como o snapshot manual que o Neptune tenha criado. Se o Neptune criar um snapshot manual, ele terá um nome que começa com `preupgrade`, seguido pelo nome do cluster de banco de dados, a versão do mecanismo de origem, a versão do mecanismo de destino e a data.
**nota**
Se você estiver tentando atualizar com [uma ação pendente em andamento](manage-console-maintaining), poderá encontrar um erro como o seguinte:
```
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 você encontrar esse erro, aguarde a conclusão da ação pendente ou acione imediatamente uma janela de manutenção para permitir que a atualização anterior seja concluída.
Para obter mais informações sobre como atualizar a versão do mecanismo, consulte [Manter o cluster de banco de dados do Amazon Neptune](cluster-maintenance.md). Em caso de dúvidas ou preocupações, o AWS Support está disponível nos fóruns da comunidade e por meio do [AWS Premium Support](https://aws.amazon.com/support).
# Mecanismo do Amazon Neptune versão 1.2.1.0.R4 (10/08/2023)
Desde 10/08/2023, a versão 1.2.1.0.R4 do mecanismo está sendo implantada de forma geral. Observe que leva vários dias para que uma nova versão fique disponível em todas as regiões.
**Importante**
As alterações introduzidas nesta versão do mecanismo, em alguns casos, podem ocasionar degradação do desempenho do carregamento em massa. Como resultado, as atualizações para esta versão foram temporariamente suspensas até que o problema seja resolvido.
**nota**
**Se estiver fazendo a atualização de uma versão do mecanismo anterior à 1.2.0.0:**
A [versão 1.2.0.0 do mecanismo](engine-releases-1.2.0.0.md) introduziu um novo formato para grupos de parâmetros personalizados e grupos de parâmetros de cluster personalizados. Como resultado, se você estiver atualizando de uma versão de mecanismo anterior à 1.2.0.0 para a versão 1.2.0.0 ou posterior, deverá recriar todos os grupos de parâmetros personalizados e grupos de parâmetros de cluster personalizados existentes usando a família de grupos de parâmetros `neptune1.2`. As versões anteriores usavam a família de grupos de parâmetros `neptune1`, e esses grupos de parâmetros não funcionarão com a versão 1.2.0.0 e posterior. Consulte [Grupos de parâmetros do Amazon Neptune](parameter-groups.md) para obter mais informações.
A versão 1.2.0.0 do mecanismo também introduziu um novo formato para undo logs. Como resultado, todos os undo logs criados por uma versão anterior do mecanismo devem ser eliminados e a métrica [`UndoLogsListSize`](cw-metrics.md#cw-metrics-UndoLogListSize) do CloudWatch deve cair para zero para que seja possível iniciar qualquer atualização de uma versão anterior à 1.2.0.0. Se houver muitos registros de undo logs (duzentos mil ou mais) ao tentar iniciar uma atualização, a tentativa de atualização poderá expirar enquanto aguarda a conclusão da limpeza dos undo logs.
É possível acelerar a taxa de limpeza atualizando a instância de gravador do cluster, que é onde a limpeza ocorre. Fazer isso antes de tentar realizar a atualização pode reduzir o número de undo logs antes de começar. Aumentar o tamanho do gravador para um tipo de instância 24XL pode aumentar a taxa de limpeza para mais de um milhão de registros por hora.
Se a métrica `UndoLogsListSize` do CloudWatch for extremamente grande, abrir um caso de suporte pode ajudar a examinar estratégias adicionais para reduzi-la.
Por fim, houve uma alteração significativa na versão 1.2.0.0. Ela afeta o código anterior que usava o protocolo Bolt com autenticação do IAM. A partir da versão 1.2.0.0, o Bolt precisa de um caminho de recursos para a assinatura do IAM. Em Java, a definição do caminho de recursos pode ser assim: `request.setResourcePath("/openCypher"));`. Em outras linguagens, o `/openCypher` pode ser anexado ao URI do endpoint. Consulte [Usar o protocolo Bolt](access-graph-opencypher-bolt.md) para ver exemplos.
## Melhorias nesta versão do mecanismo
+ Adição de suporte ao [GraphSON-1.0](https://tinkerpop.apache.org/docs/3.4.1/dev/io/#graphson) para Gremlin. Para usar o GraphSON-1.0, transmita `Accept header` com um valor de:
```
application/vnd.gremlin-v1.0+json;types=false
```
## Defeitos corrigidos nesta versão do mecanismo
+ Correção de um erro do Gremlin em que ocorria um vazamento de transação ao conferir o endpoint de status da consulta do Gremlin para consultas com predicados em percursos secundários para etapas não processadas de modo nativo.
+ Correção de um erro do openCypher no tratamento de transações do Bolt.
+ Correção de um problema de simultaneidade na camada de armazenamento que poderia causar uma falha.
+ Correção de um erro nos logs de consultas lentas para garantir que eles não estejam ativos quando desabilitados.
## Versões de linguagem de consulta compatíveis com esta versão
Antes de atualizar um cluster de banco de dados para a versão 1.2.1.0.R4, assegure-se de que o projeto seja compatível com estas versões da linguagem de consulta:
+ *Versão compatível mais antiga do Gremlin:* `3.6.2`
+ *Versão compatível mais recente do Gremlin:* `3.6.5`
+ *openCypher versão:* `Neptune-9.0.20190305-1.0`
+ *SPARQL versão:* `1.1`
## Caminhos de atualização para a versão 1.2.1.0.R4 do mecanismo
## Atualizar para esta versão
O Amazon Neptune 1.2.1.0.R4 já está disponível ao público em geral.
Se um cluster de banco de dados estiver executando uma versão do mecanismo a partir da qual haja um caminho de atualização para esta versão, ele estará elegível para ser atualizado agora. Você pode atualizar qualquer cluster elegível usando as operações do cluster de banco de dados no console ou usando o SDK. O seguinte comando da CLI atualizará imediatamente um cluster elegível:
Para Linux, OS X ou Unix:
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.2.1.0 \
4. --apply-immediately
```
Para Windows:
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.2.1.0 ^
4. --apply-immediately
```
As atualizações são simultaneamente aplicadas a todas as instâncias em um cluster de banco de dados. Como as atualizações exigem a reinicialização do banco de dados nessas instâncias, ocorrerá um tempo de inatividade de vinte a trinta segundos a alguns minutos. Depois disso, você poderá retomar o uso do cluster de banco de dados.
### Sempre teste antes de fazer a atualização
Quando uma nova versão principal ou secundária do mecanismo do Neptune for lançada, sempre teste as aplicações do Neptune antes de atualizá-la. Mesmo uma atualização secundária pode introduzir novos atributos ou comportamentos que afetem o código.
Comece comparando as páginas de notas da versão atual com as da versão de destino para ver se haverá alterações nas versões da linguagem de consulta ou outras alterações importantes.
A melhor maneira de testar uma nova versão antes de atualizar o cluster de banco de dados de produção é clonar o cluster de produção para que o clone execute a nova versão do mecanismo. Depois, você pode executar consultas no clone sem afetar o cluster de banco de dados de produção.
### Sempre crie um snapshot manual antes de fazer a atualização
Antes de fazer uma atualização, é altamente recomendável sempre criar um snapshot manual do cluster de banco de dados. Ter um snapshot automático só oferece proteção de curto prazo, enquanto um snapshot manual permanece disponível até que você o exclua explicitamente.
Em determinados casos, o Neptune cria um snapshot manual para você como parte do processo de atualização, mas não confie nisso e, em qualquer caso, crie o próprio snapshot manual.
Quando você tiver certeza de que não precisará reverter o cluster de banco de dados para o estado de pré-atualização, poderá excluir explicitamente o snapshot manual criado, bem como o snapshot manual que o Neptune tenha criado. Se o Neptune criar um snapshot manual, ele terá um nome que começa com `preupgrade`, seguido pelo nome do cluster de banco de dados, a versão do mecanismo de origem, a versão do mecanismo de destino e a data.
**nota**
Se você estiver tentando atualizar com [uma ação pendente em andamento](manage-console-maintaining), poderá encontrar um erro como o seguinte:
```
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 você encontrar esse erro, aguarde a conclusão da ação pendente ou acione imediatamente uma janela de manutenção para permitir que a atualização anterior seja concluída.
Para obter mais informações sobre como atualizar a versão do mecanismo, consulte [Manter o cluster de banco de dados do Amazon Neptune](cluster-maintenance.md). Em caso de dúvidas ou preocupações, o AWS Support está disponível nos fóruns da comunidade e por meio do [AWS Premium Support](https://aws.amazon.com/support).
# Mecanismo do Amazon Neptune versão 1.2.1.0.R3 (13/06/2023)
Desde 13/06/2023, a versão 1.2.1.0.R3 do mecanismo está sendo implantada de forma geral. Observe que leva vários dias para que uma nova versão fique disponível em todas as regiões.
**Importante**
As alterações introduzidas nesta versão do mecanismo, em alguns casos, podem ocasionar degradação do desempenho do carregamento em massa. Como resultado, as atualizações para esta versão foram temporariamente suspensas até que o problema seja resolvido.
**nota**
**Se estiver fazendo a atualização de uma versão do mecanismo anterior à 1.2.0.0:**
A [versão 1.2.0.0 do mecanismo](engine-releases-1.2.0.0.md) introduziu um novo formato para grupos de parâmetros personalizados e grupos de parâmetros de cluster personalizados. Como resultado, se você estiver atualizando de uma versão de mecanismo anterior à 1.2.0.0 para a versão 1.2.0.0 ou posterior, deverá recriar todos os grupos de parâmetros personalizados e grupos de parâmetros de cluster personalizados existentes usando a família de grupos de parâmetros `neptune1.2`. As versões anteriores usavam a família de grupos de parâmetros `neptune1`, e esses grupos de parâmetros não funcionarão com a versão 1.2.0.0 e posterior. Consulte [Grupos de parâmetros do Amazon Neptune](parameter-groups.md) para obter mais informações.
A versão 1.2.0.0 do mecanismo também introduziu um novo formato para undo logs. Como resultado, todos os undo logs criados por uma versão anterior do mecanismo devem ser eliminados e a métrica [`UndoLogsListSize`](cw-metrics.md#cw-metrics-UndoLogListSize) do CloudWatch deve cair para zero para que seja possível iniciar qualquer atualização de uma versão anterior à 1.2.0.0. Se houver muitos registros de undo logs (duzentos mil ou mais) ao tentar iniciar uma atualização, a tentativa de atualização poderá expirar enquanto aguarda a conclusão da limpeza dos undo logs.
É possível acelerar a taxa de limpeza atualizando a instância de gravador do cluster, que é onde a limpeza ocorre. Fazer isso antes de tentar realizar a atualização pode reduzir o número de undo logs antes de começar. Aumentar o tamanho do gravador para um tipo de instância 24XL pode aumentar a taxa de limpeza para mais de um milhão de registros por hora.
Se a métrica `UndoLogsListSize` do CloudWatch for extremamente grande, abrir um caso de suporte pode ajudar a examinar estratégias adicionais para reduzi-la.
Por fim, houve uma alteração significativa na versão 1.2.0.0. Ela afeta o código anterior que usava o protocolo Bolt com autenticação do IAM. A partir da versão 1.2.0.0, o Bolt precisa de um caminho de recursos para a assinatura do IAM. Em Java, a definição do caminho de recursos pode ser assim: `request.setResourcePath("/openCypher"));`. Em outras linguagens, o `/openCypher` pode ser anexado ao URI do endpoint. Consulte [Usar o protocolo Bolt](access-graph-opencypher-bolt.md) para ver exemplos.
## Novos recursos nesta versão do mecanismo
+ Adição de suporte para carregamento em massa entre contas usando o [encadeamento de perfis do IAM](bulk-load-tutorial-chain-roles.md).
## Melhorias nesta versão do mecanismo
+ Melhoria da etapa `fail()` do Gremlin para diferenciar a exceção produzida de uma `InternalFailureException` genérica e garantir que qualquer mensagem fornecida pelo usuário fosse propagada de volta ao chamador.
+ Melhoria das otimizações do mecanismo de consulta do Gremlin para `store`, `aggregate`, `cap`, `limit` e `hasLabel`.
+ Adição de suporte para funções trignométricas do openCypher:
+ `acos()`
+ `asin()`
+ `atan()`
+ `atan2()`
+ `cos()`
+ `cot()`
+ `degrees()`
+ `pi()`
+ `radians()`
+ `sin()`
+ `tan()`
+ Adição de suporte para várias funções de agregação do openCypher:
+ `percentileDisc()`
+ `stDev()`
+ Adição de suporte para a função `epochmillis()` do openCypher que converte um `datetime` em `epochmillis`. Por exemplo:
```
MATCH (n) RETURN epochMillis(n.someDateTime)
1698972364782
```
+ Adição de suporte para o operador (`%`) do módulo do openCypher.
+ Adição de suporte para a ferramenta openCypher Static Debug Explain.
+ Adição de suporte para a função `randomUUID()` no openCypher.
+ Melhoria do desempenho do openCypher:
+ Melhoria do analisador e do planejador de consultas.
+ Melhoria da utilização da CPU no mecanismo do DFE.
+ Melhoria no desempenho de consultas que contêm várias cláusulas de atualização que reutilizam as mesmas variáveis. Veja estes exemplos:
```
MERGE (n {name: 'John'})
or
MERGE (m {name: 'Jim'})
or
MERGE (n)-[:knows {since: 2023}]→(m)
```
+ Otimização dos planos de consulta para padrões de consulta de vários saltos, como:
```
MATCH (n)-->()-->()-->(m)
RETURN n m
```
+ Melhoria no desempenho da injeção de listas e mapas por meio de consultas parametrizadas. Por exemplo:
```
UNWIND $idList as id MATCH (n {`~id`: id})
RETURN n.name
```
+ Melhoria na execução de consultas que contêm `WITH` tornando-as uma barreira apropriada.
+ Otimização para evitar a materialização redundante de valores em `Unfold` e funções de agregação.
+ Melhoria no desempenho das consultas do SPARQL que contêm um grande número de entradas estáticas na cláusula `VALUES`, como:
```
SELECT ?n WHERE { VALUES (?name) { ("John") ("Jim") ... many values ... } ?n a ?n_type . ?n ?name . }
```
+ Melhoria no desempenho de consultas SPARQL CBD.
## Defeitos corrigidos nesta versão do mecanismo
+ Correção de um erro do Gremlin em que consultas longas com aninhamento profundo causavam alto uso da CPU e tempos limite de consulta durante a fase de planejamento da consulta.
+ Correção de um erro do Gremlin em que uma `NullPointerException` inválida podia ser lançada ao usar `mergeV` ou `mergeE`.
## Versões de linguagem de consulta compatíveis com esta versão
Antes de atualizar um cluster de banco de dados para a versão 1.2.1.0.R3, assegure-se de que o projeto seja compatível com estas versões da linguagem de consulta:
+ *Versão compatível mais antiga do Gremlin:* `3.6.2`
+ *Versão compatível mais recente do Gremlin:* `3.6.2`
+ *openCypher versão:* `Neptune-9.0.20190305-1.0`
+ *SPARQL versão:* `1.1`
## Caminhos de atualização para a versão 1.2.1.0.R3 do mecanismo
## Atualizar para esta versão
O Amazon Neptune 1.2.1.0.R3 já está disponível ao público em geral.
Se um cluster de banco de dados estiver executando uma versão do mecanismo a partir da qual haja um caminho de atualização para esta versão, ele estará elegível para ser atualizado agora. Você pode atualizar qualquer cluster elegível usando as operações do cluster de banco de dados no console ou usando o SDK. O seguinte comando da CLI atualizará imediatamente um cluster elegível:
Para Linux, OS X ou Unix:
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.2.1.0 \
4. --apply-immediately
```
Para Windows:
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.2.1.0 ^
4. --apply-immediately
```
As atualizações são simultaneamente aplicadas a todas as instâncias em um cluster de banco de dados. Como as atualizações exigem a reinicialização do banco de dados nessas instâncias, ocorrerá um tempo de inatividade de vinte a trinta segundos a alguns minutos. Depois disso, você poderá retomar o uso do cluster de banco de dados.
### Sempre teste antes de fazer a atualização
Quando uma nova versão principal ou secundária do mecanismo do Neptune for lançada, sempre teste as aplicações do Neptune antes de atualizá-la. Mesmo uma atualização secundária pode introduzir novos atributos ou comportamentos que afetem o código.
Comece comparando as páginas de notas da versão atual com as da versão de destino para ver se haverá alterações nas versões da linguagem de consulta ou outras alterações importantes.
A melhor maneira de testar uma nova versão antes de atualizar o cluster de banco de dados de produção é clonar o cluster de produção para que o clone execute a nova versão do mecanismo. Depois, você pode executar consultas no clone sem afetar o cluster de banco de dados de produção.
### Sempre crie um snapshot manual antes de fazer a atualização
Antes de fazer uma atualização, é altamente recomendável sempre criar um snapshot manual do cluster de banco de dados. Ter um snapshot automático só oferece proteção de curto prazo, enquanto um snapshot manual permanece disponível até que você o exclua explicitamente.
Em determinados casos, o Neptune cria um snapshot manual para você como parte do processo de atualização, mas não confie nisso e, em qualquer caso, crie o próprio snapshot manual.
Quando você tiver certeza de que não precisará reverter o cluster de banco de dados para o estado de pré-atualização, poderá excluir explicitamente o snapshot manual criado, bem como o snapshot manual que o Neptune tenha criado. Se o Neptune criar um snapshot manual, ele terá um nome que começa com `preupgrade`, seguido pelo nome do cluster de banco de dados, a versão do mecanismo de origem, a versão do mecanismo de destino e a data.
**nota**
Se você estiver tentando atualizar com [uma ação pendente em andamento](manage-console-maintaining), poderá encontrar um erro como o seguinte:
```
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 você encontrar esse erro, aguarde a conclusão da ação pendente ou acione imediatamente uma janela de manutenção para permitir que a atualização anterior seja concluída.
Para obter mais informações sobre como atualizar a versão do mecanismo, consulte [Manter o cluster de banco de dados do Amazon Neptune](cluster-maintenance.md). Em caso de dúvidas ou preocupações, o AWS Support está disponível nos fóruns da comunidade e por meio do [AWS Premium Support](https://aws.amazon.com/support).
# Mecanismo do Amazon Neptune versão 1.2.1.0.R2 (02/05/2023)
Desde 02/05/2023, a versão 1.2.1.0.R2 do mecanismo está sendo implantada de forma geral. Observe que leva vários dias para que uma nova versão fique disponível em todas as regiões.
**nota**
**Se estiver fazendo a atualização de uma versão do mecanismo anterior à 1.2.0.0:**
A [versão 1.2.0.0 do mecanismo](engine-releases-1.2.0.0.md) introduziu um novo formato para grupos de parâmetros personalizados e grupos de parâmetros de cluster personalizados. Como resultado, se você estiver atualizando de uma versão de mecanismo anterior à 1.2.0.0 para a versão 1.2.0.0 ou posterior, deverá recriar todos os grupos de parâmetros personalizados e grupos de parâmetros de cluster personalizados existentes usando a família de grupos de parâmetros `neptune1.2`. As versões anteriores usavam a família de grupos de parâmetros `neptune1`, e esses grupos de parâmetros não funcionarão com a versão 1.2.0.0 e posterior. Consulte [Grupos de parâmetros do Amazon Neptune](parameter-groups.md) para obter mais informações.
A versão 1.2.0.0 do mecanismo também introduziu um novo formato para undo logs. Como resultado, todos os undo logs criados por uma versão anterior do mecanismo devem ser eliminados e a métrica [`UndoLogsListSize`](cw-metrics.md#cw-metrics-UndoLogListSize) do CloudWatch deve cair para zero para que seja possível iniciar qualquer atualização de uma versão anterior à 1.2.0.0. Se houver muitos registros de undo logs (duzentos mil ou mais) ao tentar iniciar uma atualização, a tentativa de atualização poderá expirar enquanto aguarda a conclusão da limpeza dos undo logs.
É possível acelerar a taxa de limpeza atualizando a instância de gravador do cluster, que é onde a limpeza ocorre. Fazer isso antes de tentar realizar a atualização pode reduzir o número de undo logs antes de começar. Aumentar o tamanho do gravador para um tipo de instância 24XL pode aumentar a taxa de limpeza para mais de um milhão de registros por hora.
Se a métrica `UndoLogsListSize` do CloudWatch for extremamente grande, abrir um caso de suporte pode ajudar a examinar estratégias adicionais para reduzi-la.
Por fim, houve uma alteração significativa na versão 1.2.0.0. Ela afeta o código anterior que usava o protocolo Bolt com autenticação do IAM. A partir da versão 1.2.0.0, o Bolt precisa de um caminho de recursos para a assinatura do IAM. Em Java, a definição do caminho de recursos pode ser assim: `request.setResourcePath("/openCypher"));`. Em outras linguagens, o `/openCypher` pode ser anexado ao URI do endpoint. Consulte [Usar o protocolo Bolt](access-graph-opencypher-bolt.md) para ver exemplos.
## Melhorias nesta versão do mecanismo
+ Adição de um parâmetro `enableInterContainerTrafficEncryption` a todas as [APIs do Neptune ML](machine-learning-api-reference.md), que você pode usar para habilitar e desabilitar a criptografia de tráfego entre contêineres em trabalhos de treinamento ou ajuste de hiperparâmetros.
+ Adição de suporte a vários rótulos para `mergeV()` e `mergeE()` do Gremlin.
## Defeitos corrigidos nesta versão do mecanismo
+ Correção de um erro do openCypher em que as consultas de atualização e retorno não tratavam `orderBy`, `limit` e `skip` corretamente.
+ Correção de um erro do openCypher que permitia que parâmetros contidos em uma solicitação fossem substituídos por parâmetros contidos em outra solicitação simultânea.
+ Correção de um erro do openCypher em que os logs de consulta lenta não continham os tempos de consulta corretos.
+ Correção de um erro do Gremlin em que um vazamento de transação podia ocorrer quando uma consulta contendo `GroupCountStep` era enviada como uma string.
+ Correção de um erro do Gremlin em que as consultas do WebSocket falhavam quando os logs de consultas lentas estavam habilitados.
+ Correção de um erro do Gremlin em que os logs de depuração do contador de armazenamento ficavam ausentes dos logs de consultas lentas para solicitações do WebSocket.
+ Correção de alguns erros do Gremlin que envolviam `mergeV()` e `mergeE()`.
+ Correção de um erro do SPARQL em que os custos de consultas de grafos nomeados eram estimados incorretamente, resultando em planos de consulta abaixo do ideal e erros de falta de memória.
+ Correção de um erro que afetava a autorização para consultas do Gremlin e do openCypher em um cluster habilitado para IAM.
## Versões de linguagem de consulta compatíveis com esta versão
Antes de atualizar um cluster de banco de dados para a versão 1.2.1.0.R2, assegure-se de que o projeto seja compatível com estas versões da linguagem de consulta:
+ *Versão compatível mais antiga do Gremlin:* `3.6.2`
+ *Versão compatível mais recente do Gremlin:* `3.6.2`
+ *openCypher versão:* `Neptune-9.0.20190305-1.0`
+ *SPARQL versão:* `1.1`
## Caminhos de atualização para a versão 1.2.1.0.R2 do mecanismo
## Atualizar para esta versão
O Amazon Neptune 1.2.1.0.R2 já está disponível ao público em geral.
Se um cluster de banco de dados estiver executando uma versão do mecanismo a partir da qual haja um caminho de atualização para esta versão, ele estará elegível para ser atualizado agora. Você pode atualizar qualquer cluster elegível usando as operações do cluster de banco de dados no console ou usando o SDK. O seguinte comando da CLI atualizará imediatamente um cluster elegível:
Para Linux, OS X ou Unix:
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.2.1.0 \
4. --apply-immediately
```
Para Windows:
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.2.1.0 ^
4. --apply-immediately
```
As atualizações são simultaneamente aplicadas a todas as instâncias em um cluster de banco de dados. Como as atualizações exigem a reinicialização do banco de dados nessas instâncias, ocorrerá um tempo de inatividade de vinte a trinta segundos a alguns minutos. Depois disso, você poderá retomar o uso do cluster de banco de dados.
### Sempre teste antes de fazer a atualização
Quando uma nova versão principal ou secundária do mecanismo do Neptune for lançada, sempre teste as aplicações do Neptune antes de atualizá-la. Mesmo uma atualização secundária pode introduzir novos atributos ou comportamentos que afetem o código.
Comece comparando as páginas de notas da versão atual com as da versão de destino para ver se haverá alterações nas versões da linguagem de consulta ou outras alterações importantes.
A melhor maneira de testar uma nova versão antes de atualizar o cluster de banco de dados de produção é clonar o cluster de produção para que o clone execute a nova versão do mecanismo. Depois, você pode executar consultas no clone sem afetar o cluster de banco de dados de produção.
### Sempre crie um snapshot manual antes de fazer a atualização
Antes de fazer uma atualização, é altamente recomendável sempre criar um snapshot manual do cluster de banco de dados. Ter um snapshot automático só oferece proteção de curto prazo, enquanto um snapshot manual permanece disponível até que você o exclua explicitamente.
Em determinados casos, o Neptune cria um snapshot manual para você como parte do processo de atualização, mas não confie nisso e, em qualquer caso, crie o próprio snapshot manual.
Quando você tiver certeza de que não precisará reverter o cluster de banco de dados para o estado de pré-atualização, poderá excluir explicitamente o snapshot manual criado, bem como o snapshot manual que o Neptune tenha criado. Se o Neptune criar um snapshot manual, ele terá um nome que começa com `preupgrade`, seguido pelo nome do cluster de banco de dados, a versão do mecanismo de origem, a versão do mecanismo de destino e a data.
**nota**
Se você estiver tentando atualizar com [uma ação pendente em andamento](manage-console-maintaining), poderá encontrar um erro como o seguinte:
```
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 você encontrar esse erro, aguarde a conclusão da ação pendente ou acione imediatamente uma janela de manutenção para permitir que a atualização anterior seja concluída.
Para obter mais informações sobre como atualizar a versão do mecanismo, consulte [Manter o cluster de banco de dados do Amazon Neptune](cluster-maintenance.md). Em caso de dúvidas ou preocupações, o AWS Support está disponível nos fóruns da comunidade e por meio do [AWS Premium Support](https://aws.amazon.com/support).