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.1.1.0 (19/04/2022)
Desde 19/04/2022, a versão 1.1.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.
**Importante**
**A atualização para esta versão do mecanismo a partir de uma versão anterior à `1.1.0.0` também aciona uma atualização do sistema operacional em todas as instâncias do cluster de banco de dados. Como as solicitações de gravação ativas que ocorrem durante a atualização do sistema operacional não serão processadas, você deve pausar todas as workloads de gravação no cluster que está sendo atualizado, incluindo carregamentos de dados em massa, antes de iniciar a atualização.**
Para concluir a atualização com êxito, todas as sub-redes em cada zona de disponibilidade (AZ) devem ter pelo menos um endereço IP disponível por instância do Neptune. Por exemplo, se houver uma instância de gravador e duas instâncias de leitor na sub-rede 1 e duas instâncias de leitor na sub-rede 2, a sub-rede 1 deverá ter pelo menos três endereços IP livres e a sub-rede 2 deverá ter pelo menos dois endereços IP livres antes de iniciar a atualização.
No início da atualização, o Neptune gera um snapshot com um nome composto de `preupgrade` seguido por um identificador gerado automaticamente com base nas informações do cluster de banco de dados. Você não será cobrado por esse snapshot e poderá usá-lo para restaurar o cluster de banco de dados se algo der errado durante o processo de atualização.
Quando a atualização do mecanismo em si for concluída, a nova versão do mecanismo estará disponível brevemente no sistema operacional antigo, mas em menos de cinco minutos todas as instâncias do cluster iniciarão simultaneamente uma atualização do sistema operacional. O cluster de banco de dados ficará indisponível nesse momento por alguns minutos. Você poderá retomar as workloads de gravação após a conclusão da atualização.
Esse processo gera os seguintes eventos:
Mensagens de eventos por cluster:
`Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-(autogenerated snapshot ID)]`
`Database cluster major version has been upgraded`
Mensagens de eventos por instância:
`Applying off-line patches to DB instance`
`DB instance shutdown`
`Finished applying off-line patches to DB instance`
`DB instance restarted`
## Versões de patch subsequentes para esta versão
+ [Versão de manutenção: 1.1.1.0.R2 (16/05/2022)](engine-releases-1.1.1.0.R2.md)
+ [Versão: 1.1.1.0.R3 (07/06/2022)](engine-releases-1.1.1.0.R3.md)
+ [Versão: 1.1.1.0.R4 (23/06/2022)](engine-releases-1.1.1.0.R4.md)
+ [Versão: 1.1.1.0.R5 (21/07/2022)](engine-releases-1.1.1.0.R5.md)
+ [Versão: 1.1.1.0.R6 (23/09/2022)](engine-releases-1.1.1.0.R6.md)
+ [Versão: 1.1.1.0.R7 (23/01/2023)](engine-releases-1.1.1.0.R7.md)
## Novos recursos nesta versão do mecanismo
+ A [linguagem de consulta openCypher](access-graph-opencypher.md) agora está disponível para o público para uso em produção.
**Atenção**
Há uma alteração significativa nesta versão para o código que usa o openCypher com autenticação do IAM. Na pré-visualização do Neptune para openCypher, a string do host na assinatura do IAM incluía o protocolo, como `bolt://`, desta forma:
```
"Host":"bolt://(host URL):(port)"
```
A partir desta versão do mecanismo, o protocolo deve ser omitido:
```
"Host":"(host URL):(port)"
```
Consulte [Usar o protocolo Bolt](access-graph-opencypher-bolt.md) para ver exemplos.
+ Adição de suporte para o TinkerPop `3.5.2`. Entre as [alterações nesta versão](https://github.com/apache/tinkerpop/blob/3.5.2/CHANGELOG.asciidoc#release-3-5-2) estão o suporte para transações remotas e o suporte a bytecode para sessões (usando [https://tinkerpop.apache.org/docs/current/reference/#transactions](https://tinkerpop.apache.org/docs/current/reference/#transactions)) e a adição da função `datetime()` à linguagem Gremlin.
**Atenção**
Existem algumas alterações importantes introduzidas no TinkerPop 3.5.0, 3.5.1 e 3.5.2 que podem afetar o código do Gremlin. Por exemplo, [usar percursos gerados por um GraphTraversalSource como filhos ](https://issues.apache.org/jira/browse/TINKERPOP-2361) dessa forma não funcionará mais: `g.V().union(identity(), g.V())`.
Agora, em vez disso, use um percurso anônimo como este: `g.V().union(identity(), __.V())`.
+ Adição de suporte para [chaves de condição globais da AWS](iam-data-condition-keys.md#iam-data-global-condition-keys) que você pode usar nas [políticas de acesso a dados do IAM](iam-admin-policies.md) que controlam o acesso aos dados armazenados no Neptune, um cluster de banco de dados do Neptune.
+ O [mecanismo de consulta DFE do Neptune](neptune-dfe-engine.md) agora está disponível ao público para uso em produção com a linguagem de consulta openCypher, mas ainda não para consultas do Gremlin e do SPARQL. Agora você o habilita usando o próprio parâmetro de instância [neptune\$1dfe\$1query\$1engine](parameters.md#parameters-instance-parameters-neptune_dfe_query_engine) em vez do parâmetro de modo de laboratório.
## Melhorias nesta versão do mecanismo
+ Adição de novos atributos ao [openCypher](access-graph-opencypher.md), como suporte a consultas parametrizadas, armazenamento em cache de árvore de sintaxe abstrata (AST) para consultas parametrizadas, melhorias no caminho de comprimento variável (VLP) e novos operadores e cláusulas. Consulte [Conformidade com especificações do openCypher no Amazon Neptune](feature-opencypher-compliance.md) para conhecer o nível atual de suporte a linguagens.
+ Melhorias significativas no desempenho do openCypher para workloads simples de leitura e gravação, ocasionando maior throughput em comparação com a versão 1.1.0.0.
+ Remoção das limitações bidirecionais e de profundidade do openCypher que lidam com caminhos de comprimento variável.
+ Suporte completo no mecanismo DFE para os predicados `within` e `without` do Gremlin, incluindo casos em que eles são combinados com outros operadores de predicados. Por exemplo:
```
g.V().has('age', within(12, 15, 18).or(gt(30)))
```
+ Suporte estendido no mecanismo DFE para a etapa `order` do Gremlin quando o escopo é global (ou seja, não `order(local)`) e quando os moduladores `by()` não são usados. Por exemplo, esta consulta agora teria suporte para DFE:
```
g.V().values("age").order()
```
+ Adição de um campo `isLastOp` ao formato de resposta do [log de alterações de fluxos do Neptune](streams-using-api-reponse.md) para indicar que um registro é a última operação na transação.
+ Melhoria significativa do desempenho do registro em log de auditoria e redução da latência quando o registro em log de auditoria está habilitado.
+ Conversão de consultas de bytecode e HTTP WebSocket do Gremlin em um formato legível pelo usuário nos logs de auditoria. Agora, as consultas podem ser copiadas diretamente dos logs de auditoria para serem executadas nos blocos de anotações Neptune e em outros lugares. Observe que essa alteração no formato atual do log de auditoria constitui uma alteração significativa.
## Defeitos corrigidos nesta versão do mecanismo
+ Correção de um erro raro do Gremlin em que nenhum resultado era exibido ao usar as etapas `filter()` e `count()` aninhadas em combinação, como nesta consulta:
```
g.V("1").filter(out("knows")
.filter(in("knows")
.hasId("notExists"))
.count())
```
+ Correção de um erro do Gremlin em que um erro era gerado ao usar um vértice armazenado por uma etapa agregada em um percurso `to()` ou `from()` com uma etapa `addE`. Veja um exemplo de consulta desse:
```
g.V("id").aggregate("v").out().addE().to(select("v").unfold()))
```
+ Correção de um erro do Gremlin em que a etapa `not` falhava em casos de borda ao usar o mecanismo DFE. Por exemplo:
```
g.V().not(V())
```
+ Correção de erro do Gremlin em que valores `sideEffect` não estavam disponíveis em percursos `to()` e `from()`.
+ Correção de um erro que ocasionalmente fazia com que uma redefinição rápida acionasse um failover de instância.
+ Correção de um erro do carregador em massa em que uma transação com falha não era fechada antes do início do próximo trabalho de carregamento.
+ Correção de um erro do carregador em massa em que uma condição de pouca memória poderia causar travamento do sistema.
+ Adição de uma nova tentativa para corrigir um erro do carregador em massa em que o carregador não esperava o suficiente para que as credenciais do IAM ficassem disponíveis após um failover.
+ Correção de um erro em que o cache interno de credenciais não estava sendo limpo adequadamente para endpoints que não eram de consulta, como o endpoint de `status`.
+ Correção de um erro de fluxos para garantir que os números de sequência de confirmação de fluxos sejam ordenados corretamente.
+ Correção de um erro em que conexões de longa execução eram encerradas antes de dez dias em clusters habilitados 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.1.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.5.2`
+ *Versão compatível mais recente do Gremlin:* `3.5.4`
+ *openCypher versão:* `Neptune-9.0.20190305-1.0`
+ *SPARQL versão:* `1.1`
## Caminhos de atualização para a versão 1.1.1.0 do mecanismo
É possível atualizar manualmente qualquer versão anterior do mecanismo do Neptune para esta versão. Observe que as versões anteriores ao mecanismo de versão principal (1.1.0.0) levarão mais tempo para serem atualizadas para esta versão.
A atualização para esta versão não será automática.
## Atualizar para esta versão
**Importante**
**A atualização para esta versão do mecanismo a partir de qualquer versão anterior à `1.1.0.0` também aciona uma atualização do sistema operacional em todas as instâncias no cluster de banco de dados. Como as solicitações de gravação ativas que ocorrem durante a atualização do sistema operacional não serão processadas, você deve pausar todas as workloads de gravação no cluster que está sendo atualizado, incluindo carregamentos de dados em massa, antes de iniciar a atualização.**
No início da atualização, o Neptune gera um snapshot com um nome composto de `preupgrade` seguido por um identificador gerado automaticamente com base nas informações do cluster de banco de dados. Você não será cobrado por esse snapshot e poderá usá-lo para restaurar o cluster de banco de dados se algo der errado durante o processo de atualização.
Quando a atualização do mecanismo em si for concluída, a nova versão do mecanismo estará disponível brevemente no sistema operacional antigo, mas em menos de cinco minutos todas as instâncias do cluster iniciarão simultaneamente uma atualização do sistema operacional. O cluster de banco de dados ficará indisponível nesse momento por cerca de seis minutos. Você poderá retomar as workloads de gravação após a conclusão da atualização.
Esse processo gera os seguintes eventos:
Mensagens de eventos por cluster:
`Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-(autogenerated snapshot ID)]`
`Database cluster major version has been upgraded`
Mensagens de eventos por instância:
`Applying off-line patches to DB instance`
`DB instance shutdown`
`Finished applying off-line patches to DB instance`
`DB instance restarted`
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 essa 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 neptune \
4. --engine-version 1.1.1.0 \
5. --allow-major-version-upgrade \
6. --apply-immediately
```
Para Windows:
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine neptune ^
4. --engine-version 1.1.1.0 ^
5. --allow-major-version-upgrade ^
6. --apply-immediately
```
Em vez de `--apply-immediately`, é possível especificar `--no-apply-immediately`. Para realizar uma atualização de versão principal, é necessário usar o parâmetro allow-major-version-upgrade. Além disso, não se esqueça de incluir a versão do mecanismo ou ele poderá ser atualizado para outra versão.
Se o cluster usar um grupo de parâmetros de cluster personalizado, não se esqueça de incluir este parâmetro para especificá-lo:
```
--db-cluster-parameter-group-name (name of the custom DB cluster parameter group)
```
Da mesma forma, se alguma instância no cluster usar um grupo de parâmetros de banco de dados personalizado, não se esqueça de incluir este parâmetro para especificá-lo:
```
--db-instance-parameter-group-name (name of the custom instance parameter group)
```
### 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.1.1.0.R7 (23/01/2023)
Desde 23/01/2023, a versão 1.1.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.
**Importante**
**A atualização para esta versão do mecanismo a partir de uma versão anterior à `1.1.0.0` também aciona uma atualização do sistema operacional em todas as instâncias do cluster de banco de dados. Como as solicitações de gravação ativas que ocorrem durante a atualização do sistema operacional não serão processadas, você deve pausar todas as workloads de gravação no cluster que está sendo atualizado, incluindo carregamentos de dados em massa, antes de iniciar a atualização.**
Para concluir a atualização com êxito, todas as sub-redes em cada zona de disponibilidade (AZ) devem ter pelo menos um endereço IP disponível por instância do Neptune. Por exemplo, se houver uma instância de gravador e duas instâncias de leitor na sub-rede 1 e duas instâncias de leitor na sub-rede 2, a sub-rede 1 deverá ter pelo menos três endereços IP livres e a sub-rede 2 deverá ter pelo menos dois endereços IP livres antes de iniciar a atualização.
No início da atualização, o Neptune gera um snapshot com um nome composto de `preupgrade` seguido por um identificador gerado automaticamente com base nas informações do cluster de banco de dados. Você não será cobrado por esse snapshot e poderá usá-lo para restaurar o cluster de banco de dados se algo der errado durante o processo de atualização.
Quando a atualização do mecanismo em si for concluída, a nova versão do mecanismo estará disponível brevemente no sistema operacional antigo, mas em menos de cinco minutos todas as instâncias do cluster iniciarão simultaneamente uma atualização do sistema operacional. O cluster de banco de dados ficará indisponível nesse momento por alguns minutos. Você poderá retomar as workloads de gravação após a conclusão da atualização.
Esse processo gera os seguintes eventos:
Mensagens de eventos por cluster:
`Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-(autogenerated snapshot ID)]`
`Database cluster major version has been upgraded`
Mensagens de eventos por instância:
`Applying off-line patches to DB instance`
`DB instance shutdown`
`Finished applying off-line patches to DB instance`
`DB instance restarted`
## Melhorias nesta versão do mecanismo
+ 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
```
+ Melhorias no desempenho e correções para vários operadores do Gremlin, incluindo `repeat`, `coalesce`, `store` e `aggregate`.
## Defeitos corrigidos nesta versão do mecanismo
+ Correção de um erro do openCypher em que uma solicitação usando HTTP keep-alive poderia ser fechada incorretamente se fosse enviada após uma solicitação com falha.
+ Correção de um erro do openCypher em que o tipo de parâmetro nem sempre era interpretado corretamente para uma lista ou uma lista de mapas.
+ 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 códigos e mensagens de erro do openCypher para falhas de tempo limite de consulta e erros de memória insuficiente.
+ Correção de um erro do Gremlin que fazia com que `valueMap()` não fosse otimizado em um percurso `by()` no mecanismo do DFE.
+ Correção de um problema com a lógica do detector de deadlock que ocasionalmente fazia com que o mecanismo parasse de responder.
+ Correção de um erro no log de auditoria que fazia com que informações desnecessárias fossem registradas e determinados campos ficassem ausentes nos logs.
## 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.1.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.5.2`
+ *Versão compatível mais recente do Gremlin:* `3.5.3`
+ *openCypher versão:* `Neptune-9.0.20190305-1.0`
+ *SPARQL versão:* `1.1`
## Caminhos de atualização para a versão 1.1.1.0.R7 do mecanismo
O cluster será atualizado com essa versão de patch automaticamente durante a próxima janela de manutenção se você estiver executando a versão do mecanismo `1.1.1.0`.
## Atualizar para esta versão
**Importante**
**A atualização para esta versão do mecanismo a partir de qualquer versão anterior à `1.1.0.0` também aciona uma atualização do sistema operacional em todas as instâncias no cluster de banco de dados. Como as solicitações de gravação ativas que ocorrem durante a atualização do sistema operacional não serão processadas, você deve pausar todas as workloads de gravação no cluster que está sendo atualizado, incluindo carregamentos de dados em massa, antes de iniciar a atualização.**
No início da atualização, o Neptune gera um snapshot com um nome composto de `preupgrade` seguido por um identificador gerado automaticamente com base nas informações do cluster de banco de dados. Você não será cobrado por esse snapshot e poderá usá-lo para restaurar o cluster de banco de dados se algo der errado durante o processo de atualização.
Quando a atualização do mecanismo em si for concluída, a nova versão do mecanismo estará disponível brevemente no sistema operacional antigo, mas em menos de cinco minutos todas as instâncias do cluster iniciarão simultaneamente uma atualização do sistema operacional. O cluster de banco de dados ficará indisponível nesse momento por cerca de seis minutos. Você poderá retomar as workloads de gravação após a conclusão da atualização.
Esse processo gera os seguintes eventos:
Mensagens de eventos por cluster:
`Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-(autogenerated snapshot ID)]`
`Database cluster major version has been upgraded`
Mensagens de eventos por instância:
`Applying off-line patches to DB instance`
`DB instance shutdown`
`Finished applying off-line patches to DB instance`
`DB instance restarted`
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 essa 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.1.1.0 \
4. --apply-immediately
```
Para Windows:
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.1.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.1.1.0.R6 (23/09/2022)
Desde 23/09/2022, a versão 1.1.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.
**Importante**
**A atualização para esta versão do mecanismo a partir de uma versão anterior à `1.1.0.0` também aciona uma atualização do sistema operacional em todas as instâncias do cluster de banco de dados. Como as solicitações de gravação ativas que ocorrem durante a atualização do sistema operacional não serão processadas, você deve pausar todas as workloads de gravação no cluster que está sendo atualizado, incluindo carregamentos de dados em massa, antes de iniciar a atualização.**
Para concluir a atualização com êxito, todas as sub-redes em cada zona de disponibilidade (AZ) devem ter pelo menos um endereço IP disponível por instância do Neptune. Por exemplo, se houver uma instância de gravador e duas instâncias de leitor na sub-rede 1 e duas instâncias de leitor na sub-rede 2, a sub-rede 1 deverá ter pelo menos três endereços IP livres e a sub-rede 2 deverá ter pelo menos dois endereços IP livres antes de iniciar a atualização.
No início da atualização, o Neptune gera um snapshot com um nome composto de `preupgrade` seguido por um identificador gerado automaticamente com base nas informações do cluster de banco de dados. Você não será cobrado por esse snapshot e poderá usá-lo para restaurar o cluster de banco de dados se algo der errado durante o processo de atualização.
Quando a atualização do mecanismo em si for concluída, a nova versão do mecanismo estará disponível brevemente no sistema operacional antigo, mas em menos de cinco minutos todas as instâncias do cluster iniciarão simultaneamente uma atualização do sistema operacional. O cluster de banco de dados ficará indisponível nesse momento por alguns minutos. Você poderá retomar as workloads de gravação após a conclusão da atualização.
Esse processo gera os seguintes eventos:
Mensagens de eventos por cluster:
`Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-(autogenerated snapshot ID)]`
`Database cluster major version has been upgraded`
Mensagens de eventos por instância:
`Applying off-line patches to DB instance`
`DB instance shutdown`
`Finished applying off-line patches to DB instance`
`DB instance restarted`
**nota**
Há uma alteração significativa nesta versão para o código que usa o openCypher com autenticação do IAM. Até o momento, a string do host na assinatura do IAM incluía o protocolo, como `bolt://`, por exemplo:
```
"Host":"bolt://(host URL):(port)"
```
A partir da versão do mecanismo `1.1.1.0`, o protocolo deve ser omitido:
```
"Host":"(host URL):(port)"
```
Consulte [Usar o protocolo Bolt](access-graph-opencypher-bolt.md) para ver exemplos.
## Melhorias nesta versão do mecanismo
+ Melhoria no desempenho de consultas `order-by` do Gremlin. As consultas do Gremlin com um `order-by` no final de uma `NeptuneGraphQueryStep` agora usam um tamanho de bloco maior para melhor desempenho. Isso não se aplica a `order-by` em um nó interno (não raiz) do plano de consulta.
+ Melhoria no desempenho de consultas de atualização do Gremlin. Agora, vértices e bordas devem ser bloqueados contra exclusão ao adicionar bordas ou propriedades. Essa alteração elimina bloqueios duplicados em uma transação, o que melhora o desempenho.
## Defeitos corrigidos nesta versão do mecanismo
+ Correção de um erro do openCypher na cláusula `MERGE` que, em alguns casos, causava a criação duplicada de nós e bordas.
+ Correção de um erro no tratamento de consultas do SPARQL que contêm `(NOT) EXISTS` em uma cláusula `OPTIONAL` em que, em alguns casos, os resultados da consulta ficavam ausentes.
+ Correção de um erro que atrasava a reinicialização do servidor quando um carregamento em massa estava em andamento.
+ Correção de um erro em que um percurso bidirecional do padrão de comprimento variável do openCypher com um filtro na propriedade de relacionamento causava um erro. Um exemplo desse padrão de comprimento variável é `(n)-[r*1..2]->(m)`.
+ Correção de um erro relacionado à forma como os dados em cache são enviados de volta ao cliente, que em alguns casos resultava em uma latência inesperadamente longa.
## 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.1.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.5.2`
+ *Versão compatível mais recente do Gremlin:* `3.5.4`
+ *openCypher versão:* `Neptune-9.0.20190305-1.0`
+ *SPARQL versão:* `1.1`
## Caminhos de atualização para a versão 1.1.1.0.R6 do mecanismo
O cluster será atualizado com essa versão de patch automaticamente durante a próxima janela de manutenção se você estiver executando a versão do mecanismo `1.1.1.0`.
## Atualizar para esta versão
**Importante**
**A atualização para esta versão do mecanismo a partir de qualquer versão anterior à `1.1.0.0` também aciona uma atualização do sistema operacional em todas as instâncias no cluster de banco de dados. Como as solicitações de gravação ativas que ocorrem durante a atualização do sistema operacional não serão processadas, você deve pausar todas as workloads de gravação no cluster que está sendo atualizado, incluindo carregamentos de dados em massa, antes de iniciar a atualização.**
No início da atualização, o Neptune gera um snapshot com um nome composto de `preupgrade` seguido por um identificador gerado automaticamente com base nas informações do cluster de banco de dados. Você não será cobrado por esse snapshot e poderá usá-lo para restaurar o cluster de banco de dados se algo der errado durante o processo de atualização.
Quando a atualização do mecanismo em si for concluída, a nova versão do mecanismo estará disponível brevemente no sistema operacional antigo, mas em menos de cinco minutos todas as instâncias do cluster iniciarão simultaneamente uma atualização do sistema operacional. O cluster de banco de dados ficará indisponível nesse momento por cerca de seis minutos. Você poderá retomar as workloads de gravação após a conclusão da atualização.
Esse processo gera os seguintes eventos:
Mensagens de eventos por cluster:
`Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-(autogenerated snapshot ID)]`
`Database cluster major version has been upgraded`
Mensagens de eventos por instância:
`Applying off-line patches to DB instance`
`DB instance shutdown`
`Finished applying off-line patches to DB instance`
`DB instance restarted`
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 essa 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.1.1.0 \
4. --apply-immediately
```
Para Windows:
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.1.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.1.1.0.R5 (21/07/2022)
Desde 21/07/2022, a versão 1.1.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.
**Importante**
**A atualização para esta versão do mecanismo a partir de uma versão anterior à `1.1.0.0` também aciona uma atualização do sistema operacional em todas as instâncias do cluster de banco de dados. Como as solicitações de gravação ativas que ocorrem durante a atualização do sistema operacional não serão processadas, você deve pausar todas as workloads de gravação no cluster que está sendo atualizado, incluindo carregamentos de dados em massa, antes de iniciar a atualização.**
Para concluir a atualização com êxito, todas as sub-redes em cada zona de disponibilidade (AZ) devem ter pelo menos um endereço IP disponível por instância do Neptune. Por exemplo, se houver uma instância de gravador e duas instâncias de leitor na sub-rede 1 e duas instâncias de leitor na sub-rede 2, a sub-rede 1 deverá ter pelo menos três endereços IP livres e a sub-rede 2 deverá ter pelo menos dois endereços IP livres antes de iniciar a atualização.
No início da atualização, o Neptune gera um snapshot com um nome composto de `preupgrade` seguido por um identificador gerado automaticamente com base nas informações do cluster de banco de dados. Você não será cobrado por esse snapshot e poderá usá-lo para restaurar o cluster de banco de dados se algo der errado durante o processo de atualização.
Quando a atualização do mecanismo em si for concluída, a nova versão do mecanismo estará disponível brevemente no sistema operacional antigo, mas em menos de cinco minutos todas as instâncias do cluster iniciarão simultaneamente uma atualização do sistema operacional. O cluster de banco de dados ficará indisponível nesse momento por alguns minutos. Você poderá retomar as workloads de gravação após a conclusão da atualização.
Esse processo gera os seguintes eventos:
Mensagens de eventos por cluster:
`Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-(autogenerated snapshot ID)]`
`Database cluster major version has been upgraded`
Mensagens de eventos por instância:
`Applying off-line patches to DB instance`
`DB instance shutdown`
`Finished applying off-line patches to DB instance`
`DB instance restarted`
**nota**
Há uma alteração significativa nesta versão para o código que usa o openCypher com autenticação do IAM. Até o momento, a string do host na assinatura do IAM incluía o protocolo, como `bolt://`, por exemplo:
```
"Host":"bolt://(host URL):(port)"
```
A partir da versão do mecanismo `1.1.1.0`, o protocolo deve ser omitido:
```
"Host":"(host URL):(port)"
```
Consulte [Usar o protocolo Bolt](access-graph-opencypher-bolt.md) para ver exemplos.
## Melhorias nesta versão do mecanismo
+ Foram realizadas melhorias para oferecer compatibilidade com a detecção de deadlocks.
## Defeitos corrigidos nesta versão do mecanismo
+ Correção de um erro que impedia um desligamento limpo dos clusters de banco de dados em determinadas condições.
## 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.1.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.5.2`
+ *Versão compatível mais recente do Gremlin:* `3.5.4`
+ *openCypher versão:* `Neptune-9.0.20190305-1.0`
+ *SPARQL versão:* `1.1`
## Caminhos de atualização para a versão 1.1.1.0.R5 do mecanismo
O cluster será atualizado com essa versão de patch automaticamente durante a próxima janela de manutenção se você estiver executando a versão do mecanismo `1.1.1.0`.
## Atualizar para esta versão
**Importante**
**A atualização para esta versão do mecanismo a partir de qualquer versão anterior à `1.1.0.0` também aciona uma atualização do sistema operacional em todas as instâncias no cluster de banco de dados. Como as solicitações de gravação ativas que ocorrem durante a atualização do sistema operacional não serão processadas, você deve pausar todas as workloads de gravação no cluster que está sendo atualizado, incluindo carregamentos de dados em massa, antes de iniciar a atualização.**
No início da atualização, o Neptune gera um snapshot com um nome composto de `preupgrade` seguido por um identificador gerado automaticamente com base nas informações do cluster de banco de dados. Você não será cobrado por esse snapshot e poderá usá-lo para restaurar o cluster de banco de dados se algo der errado durante o processo de atualização.
Quando a atualização do mecanismo em si for concluída, a nova versão do mecanismo estará disponível brevemente no sistema operacional antigo, mas em menos de cinco minutos todas as instâncias do cluster iniciarão simultaneamente uma atualização do sistema operacional. O cluster de banco de dados ficará indisponível nesse momento por cerca de seis minutos. Você poderá retomar as workloads de gravação após a conclusão da atualização.
Esse processo gera os seguintes eventos:
Mensagens de eventos por cluster:
`Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-(autogenerated snapshot ID)]`
`Database cluster major version has been upgraded`
Mensagens de eventos por instância:
`Applying off-line patches to DB instance`
`DB instance shutdown`
`Finished applying off-line patches to DB instance`
`DB instance restarted`
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 essa 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.1.1.0 \
4. --apply-immediately
```
Para Windows:
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.1.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.1.1.0.R4 (23/06/2022)
Desde 23/06/2022, a versão 1.1.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**
**A atualização para esta versão do mecanismo a partir de uma versão anterior à `1.1.0.0` também aciona uma atualização do sistema operacional em todas as instâncias do cluster de banco de dados. Como as solicitações de gravação ativas que ocorrem durante a atualização do sistema operacional não serão processadas, você deve pausar todas as workloads de gravação no cluster que está sendo atualizado, incluindo carregamentos de dados em massa, antes de iniciar a atualização.**
Para concluir a atualização com êxito, todas as sub-redes em cada zona de disponibilidade (AZ) devem ter pelo menos um endereço IP disponível por instância do Neptune. Por exemplo, se houver uma instância de gravador e duas instâncias de leitor na sub-rede 1 e duas instâncias de leitor na sub-rede 2, a sub-rede 1 deverá ter pelo menos três endereços IP livres e a sub-rede 2 deverá ter pelo menos dois endereços IP livres antes de iniciar a atualização.
No início da atualização, o Neptune gera um snapshot com um nome composto de `preupgrade` seguido por um identificador gerado automaticamente com base nas informações do cluster de banco de dados. Você não será cobrado por esse snapshot e poderá usá-lo para restaurar o cluster de banco de dados se algo der errado durante o processo de atualização.
Quando a atualização do mecanismo em si for concluída, a nova versão do mecanismo estará disponível brevemente no sistema operacional antigo, mas em menos de cinco minutos todas as instâncias do cluster iniciarão simultaneamente uma atualização do sistema operacional. O cluster de banco de dados ficará indisponível nesse momento por alguns minutos. Você poderá retomar as workloads de gravação após a conclusão da atualização.
Esse processo gera os seguintes eventos:
Mensagens de eventos por cluster:
`Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-(autogenerated snapshot ID)]`
`Database cluster major version has been upgraded`
Mensagens de eventos por instância:
`Applying off-line patches to DB instance`
`DB instance shutdown`
`Finished applying off-line patches to DB instance`
`DB instance restarted`
**nota**
Há uma alteração significativa nesta versão para o código que usa o openCypher com autenticação do IAM. Até o momento, a string do host na assinatura do IAM incluía o protocolo, como `bolt://`, por exemplo:
```
"Host":"bolt://(host URL):(port)"
```
A partir da versão do mecanismo `1.1.1.0`, o protocolo deve ser omitido:
```
"Host":"(host URL):(port)"
```
Consulte [Usar o protocolo Bolt](access-graph-opencypher-bolt.md) para ver exemplos.
## Melhorias nesta versão do mecanismo
+ Atualização da configuração dos tipos de instância `x2g`.
+ Melhoria no desempenho das quedas de vértices.
## Defeitos corrigidos nesta versão do mecanismo
+ Correção do erro do Gremlin em que as soluções não mantinham uma ordem estável para uma consulta chamada várias vezes ou em vários leitores para determinados tipos de junções ASK.
+ Além disso, reduzimos o escopo de uma alteração na versão anterior que estava causando regressões de desempenho para certos tipos de junções ASK no Gremlin.
+ Correção de um erro do Gremlin na etapa `union()` que ocorria quando havia uma entrada de borda e um percurso para um vértice nos percursos secundários.
+ Correção de um erro no perfil do Gremlin em que algumas etapas eram relatadas como não otimizadas quando na realidade estavam.
+ Correção de um erro do SPARQL em que variáveis usadas em expressões `FILTER` aninhadas em cláusulas `UNION` recebiam informações de escopo inválidas.
## 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.1.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.5.2`
+ *Versão compatível mais recente do Gremlin:* `3.5.4`
+ *openCypher versão:* `Neptune-9.0.20190305-1.0`
+ *SPARQL versão:* `1.1`
## Caminhos de atualização para a versão 1.1.1.0.R4 do mecanismo
O cluster será atualizado com essa versão de patch automaticamente durante a próxima janela de manutenção se você estiver executando a versão do mecanismo `1.1.1.0`.
## Atualizar para esta versão
**Importante**
**A atualização para esta versão do mecanismo a partir de qualquer versão anterior à `1.1.0.0` também aciona uma atualização do sistema operacional em todas as instâncias no cluster de banco de dados. Como as solicitações de gravação ativas que ocorrem durante a atualização do sistema operacional não serão processadas, você deve pausar todas as workloads de gravação no cluster que está sendo atualizado, incluindo carregamentos de dados em massa, antes de iniciar a atualização.**
No início da atualização, o Neptune gera um snapshot com um nome composto de `preupgrade` seguido por um identificador gerado automaticamente com base nas informações do cluster de banco de dados. Você não será cobrado por esse snapshot e poderá usá-lo para restaurar o cluster de banco de dados se algo der errado durante o processo de atualização.
Quando a atualização do mecanismo em si for concluída, a nova versão do mecanismo estará disponível brevemente no sistema operacional antigo, mas em menos de cinco minutos todas as instâncias do cluster iniciarão simultaneamente uma atualização do sistema operacional. O cluster de banco de dados ficará indisponível nesse momento por cerca de seis minutos. Você poderá retomar as workloads de gravação após a conclusão da atualização.
Esse processo gera os seguintes eventos:
Mensagens de eventos por cluster:
`Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-(autogenerated snapshot ID)]`
`Database cluster major version has been upgraded`
Mensagens de eventos por instância:
`Applying off-line patches to DB instance`
`DB instance shutdown`
`Finished applying off-line patches to DB instance`
`DB instance restarted`
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 essa 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.1.1.0 \
4. --apply-immediately
```
Para Windows:
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.1.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.1.1.0.R3 (07/06/2022)
Desde 07/06/2022, a versão 1.1.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**
**A atualização para esta versão do mecanismo a partir de uma versão anterior à `1.1.0.0` também aciona uma atualização do sistema operacional em todas as instâncias do cluster de banco de dados. Como as solicitações de gravação ativas que ocorrem durante a atualização do sistema operacional não serão processadas, você deve pausar todas as workloads de gravação no cluster que está sendo atualizado, incluindo carregamentos de dados em massa, antes de iniciar a atualização.**
No início da atualização, o Neptune gera um snapshot com um nome composto de `preupgrade` seguido por um identificador gerado automaticamente com base nas informações do cluster de banco de dados. Você não será cobrado por esse snapshot e poderá usá-lo para restaurar o cluster de banco de dados se algo der errado durante o processo de atualização.
Quando a atualização do mecanismo em si for concluída, a nova versão do mecanismo estará disponível brevemente no sistema operacional antigo, mas em menos de cinco minutos todas as instâncias do cluster iniciarão simultaneamente uma atualização do sistema operacional. O cluster de banco de dados ficará indisponível nesse momento por alguns minutos. Você poderá retomar as workloads de gravação após a conclusão da atualização.
Esse processo gera os seguintes eventos:
Mensagens de eventos por cluster:
`Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-(autogenerated snapshot ID)]`
`Database cluster major version has been upgraded`
Mensagens de eventos por instância:
`Applying off-line patches to DB instance`
`DB instance shutdown`
`Finished applying off-line patches to DB instance`
`DB instance restarted`
**nota**
Há uma alteração significativa nesta versão para o código que usa o openCypher com autenticação do IAM. Até o momento, a string do host na assinatura do IAM incluía o protocolo, como `bolt://`, por exemplo:
```
"Host":"bolt://(host URL):(port)"
```
A partir da versão do mecanismo `1.1.1.0`, o protocolo deve ser omitido:
```
"Host":"(host URL):(port)"
```
Consulte [Usar o protocolo Bolt](access-graph-opencypher-bolt.md) para ver exemplos.
## Melhorias nesta versão do mecanismo
+ Adição de suporte para os tipos de instância `x2g` equipados com Graviton2, otimizados para workloads com uso intenso de memória. Inicialmente, eles estão disponíveis apenas em quatro Regiões da AWS:
+ Leste dos EUA (Norte da Virgínia) (`us-east-1`)
+ Leste dos EUA (Ohio) (`us-east-2`)
+ Oeste dos EUA (Oregon): \$1 \$1 \$1 ) (`us-west-2`)
+ Europa (Irlanda) (`eu-west-1`)
Para obter mais informações, consulte a [página Preços do Neptune](https://aws.amazon.com/neptune/pricing/).
+ Melhoria no desempenho das etapas do Gremlin em que vários percursos de bordas ou vértices, pesquisas de propriedades ou pesquisas de rótulos estão envolvidos.
## Defeitos corrigidos nesta versão do mecanismo
+ Correção de um erro do Gremlin no processamento da etapa `otherV()` em um percurso secundário.
+ Correção de um erro do Gremlin em consultas com `union` que têm apenas etapas de filtro como filhos. Por exemplo:
```
g.V().union(has("name"), out("knows")).out()
```
+ Correção de um erro do SPARQL em que variáveis usadas em expressões `FILTER` aninhadas em cláusulas `UNION` recebiam informações de escopo inválidas.
## 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.1.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.5.2`
+ *Versão compatível mais recente do Gremlin:* `3.5.4`
+ *openCypher versão:* `Neptune-9.0.20190305-1.0`
+ *SPARQL versão:* `1.1`
## Caminhos de atualização para a versão 1.1.1.0.R3 do mecanismo
O cluster será atualizado com essa versão de patch automaticamente durante a próxima janela de manutenção se você estiver executando a versão do mecanismo `1.1.1.0`.
## Atualizar para esta versão
**Importante**
**A atualização para esta versão do mecanismo a partir de qualquer versão anterior à `1.1.0.0` também aciona uma atualização do sistema operacional em todas as instâncias no cluster de banco de dados. Como as solicitações de gravação ativas que ocorrem durante a atualização do sistema operacional não serão processadas, você deve pausar todas as workloads de gravação no cluster que está sendo atualizado, incluindo carregamentos de dados em massa, antes de iniciar a atualização.**
No início da atualização, o Neptune gera um snapshot com um nome composto de `preupgrade` seguido por um identificador gerado automaticamente com base nas informações do cluster de banco de dados. Você não será cobrado por esse snapshot e poderá usá-lo para restaurar o cluster de banco de dados se algo der errado durante o processo de atualização.
Quando a atualização do mecanismo em si for concluída, a nova versão do mecanismo estará disponível brevemente no sistema operacional antigo, mas em menos de cinco minutos todas as instâncias do cluster iniciarão simultaneamente uma atualização do sistema operacional. O cluster de banco de dados ficará indisponível nesse momento por cerca de seis minutos. Você poderá retomar as workloads de gravação após a conclusão da atualização.
Esse processo gera os seguintes eventos:
Mensagens de eventos por cluster:
`Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-(autogenerated snapshot ID)]`
`Database cluster major version has been upgraded`
Mensagens de eventos por instância:
`Applying off-line patches to DB instance`
`DB instance shutdown`
`Finished applying off-line patches to DB instance`
`DB instance restarted`
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 essa 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.1.1.0 \
4. --apply-immediately
```
Para Windows:
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.1.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).
# Versão de manutenção do Amazon Neptune, versão 1.1.1.0.R2 (16/05/2022)
Desde 16/05/2022, a versão 1.1.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.
**Importante**
**A atualização para esta versão do mecanismo a partir de uma versão anterior à `1.1.0.0` também aciona uma atualização do sistema operacional em todas as instâncias do cluster de banco de dados. Como as solicitações de gravação ativas que ocorrem durante a atualização do sistema operacional não serão processadas, você deve pausar todas as workloads de gravação no cluster que está sendo atualizado, incluindo carregamentos de dados em massa, antes de iniciar a atualização.**
Para concluir a atualização com êxito, todas as sub-redes em cada zona de disponibilidade (AZ) devem ter pelo menos um endereço IP disponível por instância do Neptune. Por exemplo, se houver uma instância de gravador e duas instâncias de leitor na sub-rede 1 e duas instâncias de leitor na sub-rede 2, a sub-rede 1 deverá ter pelo menos três endereços IP livres e a sub-rede 2 deverá ter pelo menos dois endereços IP livres antes de iniciar a atualização.
No início da atualização, o Neptune gera um snapshot com um nome composto de `preupgrade` seguido por um identificador gerado automaticamente com base nas informações do cluster de banco de dados. Você não será cobrado por esse snapshot e poderá usá-lo para restaurar o cluster de banco de dados se algo der errado durante o processo de atualização.
Quando a atualização do mecanismo em si for concluída, a nova versão do mecanismo estará disponível brevemente no sistema operacional antigo, mas em menos de cinco minutos todas as instâncias do cluster iniciarão simultaneamente uma atualização do sistema operacional. O cluster de banco de dados ficará indisponível nesse momento por alguns minutos. Você poderá retomar as workloads de gravação após a conclusão da atualização.
Esse processo gera os seguintes eventos:
Mensagens de eventos por cluster:
`Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-(autogenerated snapshot ID)]`
`Database cluster major version has been upgraded`
Mensagens de eventos por instância:
`Applying off-line patches to DB instance`
`DB instance shutdown`
`Finished applying off-line patches to DB instance`
`DB instance restarted`
**nota**
Há uma alteração significativa nesta versão para o código que usa o openCypher com autenticação do IAM. Até o momento, a string do host na assinatura do IAM incluía o protocolo, como `bolt://`, por exemplo:
```
"Host":"bolt://(host URL):(port)"
```
A partir da versão do mecanismo `1.1.1.0`, o protocolo deve ser omitido:
```
"Host":"(host URL):(port)"
```
Consulte [Usar o protocolo Bolt](access-graph-opencypher-bolt.md) para ver exemplos.
## 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.1.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.5.2`
+ *Versão compatível mais recente do Gremlin:* `3.5.4`
+ *openCypher versão:* `Neptune-9.0.20190305-1.0`
+ *SPARQL versão:* `1.1`
## Caminhos de atualização para a versão 1.1.1.0.R2 do mecanismo
O cluster será atualizado com esta versão de patch de manutenção automaticamente durante a janela de manutenção seguinte se você estiver executando a versão `1.1.1.0` do mecanismo.
É possível atualizar manualmente qualquer versão anterior do mecanismo do Neptune para esta versão.
## Atualizar para esta versão
**Importante**
**A atualização para esta versão do mecanismo a partir de qualquer versão anterior à `1.1.0.0` também aciona uma atualização do sistema operacional em todas as instâncias no cluster de banco de dados. Como as solicitações de gravação ativas que ocorrem durante a atualização do sistema operacional não serão processadas, você deve pausar todas as workloads de gravação no cluster que está sendo atualizado, incluindo carregamentos de dados em massa, antes de iniciar a atualização.**
No início da atualização, o Neptune gera um snapshot com um nome composto de `preupgrade` seguido por um identificador gerado automaticamente com base nas informações do cluster de banco de dados. Você não será cobrado por esse snapshot e poderá usá-lo para restaurar o cluster de banco de dados se algo der errado durante o processo de atualização.
Quando a atualização do mecanismo em si for concluída, a nova versão do mecanismo estará disponível brevemente no sistema operacional antigo, mas em menos de cinco minutos todas as instâncias do cluster iniciarão simultaneamente uma atualização do sistema operacional. O cluster de banco de dados ficará indisponível nesse momento por cerca de seis minutos. Você poderá retomar as workloads de gravação após a conclusão da atualização.
Esse processo gera os seguintes eventos:
Mensagens de eventos por cluster:
`Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-(autogenerated snapshot ID)]`
`Database cluster major version has been upgraded`
Mensagens de eventos por instância:
`Applying off-line patches to DB instance`
`DB instance shutdown`
`Finished applying off-line patches to DB instance`
`DB instance restarted`
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 essa 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.1.1.0 \
4. --apply-immediately
```
Para Windows:
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.1.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).