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.0.0 (21/07/2022)
Desde 21/07/2022, a versão 1.2.0.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) 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.0.0.R2 (14/10/2022)](engine-releases-1.2.0.0.R2.md)
+ [Versão: 1.2.0.0.R3 (15/12/2022)](engine-releases-1.2.0.0.R3.md)
+ [Versão: 1.2.0.0.R4 (29/09/2023)](engine-releases-1.2.0.0.R4.md)
## Novos recursos nesta versão do mecanismo
+ Adição de suporte para [bancos de dados globais](neptune-global-database.md). Um banco de dados global do Neptune abrange várias Regiões da AWS e consiste em um cluster de banco de dados principal em uma região e até cinco clusters de banco de dados secundários em outras regiões.
+ Adição de suporte para um controle de acesso nas políticas do IAM no Neptune mais granular do que estava disponível anteriormente, com base nas ações do plano de dados. Essa é uma alteração importante, pois as políticas existentes do IAM baseadas na ação `connect` obsoleta devem ser ajustadas para usar as ações mais granulares do plano de dados. Consulte [Tipos de política do IAM](security-iam-access-manage.md#iam-auth-policy).
+ Melhoria da disponibilidade da instância de leitor. Anteriormente, quando uma instância de gravador era reiniciada, todas as instâncias de leitor em um cluster do Neptune também eram reiniciadas. A partir da versão 1.2.0.0 do mecanismo, as instâncias de leitor permanecem ativas após a reinicialização do gravador, o que melhora a disponibilidade do leitor. As instâncias de leitor podem ser reiniciadas separadamente para captar as alterações do grupo de parâmetros. Consulte [Reinicializar uma instância de banco de dados no Amazon Neptune](manage-console-instances-reboot.md).
+ Adição de um novo parâmetro de cluster de banco de dados [neptune\$1streams\$1expiry\$1days](parameters.md#parameters-db-cluster-parameters-neptune_streams_expiry_days) que permite definir o número de dias em que os registros de fluxos são mantidos no servidor antes de serem excluídos. O intervalo é de um a noventa e o padrão é sete.
## Melhorias nesta versão do mecanismo
+ Melhoria no desempenho da serialização do Gremlin para consultas ByteCode.
+ O Neptune agora processa predicados de texto usando o mecanismo do DFE, para melhorar o desempenho.
+ O Neptune agora processa as etapas `limit()` do Gremlin usando o mecanismo do DFE, incluindo limites de percurso não terminal e secundário.
+ O tratamento da etapa `union()` do Gremlin pelo DFE foi alterado para funcionar com outros novos atributos, o que significa que os nós de referência aparecem nos perfis de consulta conforme o esperado.
+ Melhoria no desempenho em até um fator de cinco de algumas operações de junção caras no DFE por meio da paralelização delas.
+ Adição de suporte de modulação `by()` para `OrderGlobalStep order(global)` para o mecanismo do DFE do Gremlin.
+ Adição da exibição de valores estáticos injetados nos detalhes de explicação do DFE.
+ Melhoria do desempenho ao remover padrões duplicados.
+ Adição de suporte à preservação da ordem no mecanismo do DFE do Gremlin.
+ Melhoria no desempenho das consultas do Gremlin com filtros vazios, como estes:
```
g.V().hasId(P.within([]))
```
```
g.V().hasId([])
```
+ Melhoria das mensagens de erro quando uma consulta do SPARQL usa um valor numérico muito grande para o Neptune representar internamente.
+ Melhoria no desempenho para descartar vértices com bordas associadas, reduzindo as pesquisas de índice quando os fluxos estão desabilitados.
+ Extensão do suporte do DFE para mais variantes da etapa `has()`, especificamente, para `hasKey()`, `hasLabel()` e para intervalos de predicados para strings/URIs em `has()`. Isso afeta consultas como as seguintes:
```
// hasKey() on properties
g.V().properties().hasKey("name")
g.V().properties().has(T.key, TextP.startingWith("a"))
g.E().properties().hasKey("weight")
g.E().properties().hasKey(TextP.containing("t"))
// hasLabel() on vertex properties
g.V().properties().hasLabel("name")
// range predicates on ID and Label fields
g.V().has(T.label, gt("person"))
g.E().has(T.id, lte("(an ID value)"))
```
+ Adição de uma função [`join()`](access-graph-opencypher-extensions.md#opencypher-compliance-join-function) do openCypher específica do Neptune que concatena strings em uma lista em uma única string.
+ Atualização das [políticas gerenciadas do Neptune](security-iam-access-managed-policies.md) para incluir permissões de acesso a dados e permissões para as novas APIs de bancos de dados globais.
## Defeitos corrigidos nesta versão do mecanismo
+ Correção de um erro em que uma solicitação HTTP sem o tipo de conteúdo especificado falhava automaticamente.
+ Correção de um erro do SPARQL no otimizador de consultas que impedia o uso de uma chamada de serviço em uma consulta.
+ Correção de um erro do SPARQL no analisador Turtle RDF em que uma combinação específica de dados Unicode causava falha.
+ Correção de um erro do SPARQL em que uma combinação específica de cláusulas `GRAPH` e `SELECT` produzia resultados de consulta incorretos.
+ Correção de um erro do Gremlin que causava um problema de exatidão em consultas que usavam qualquer etapa de filtro em uma etapa de união, como a seguinte:
```
g.V("1").union(hasLabel("person"), out())
```
+ Correção de um erro do Gremlin em que `count()` de `both().simplePath()` resultava no dobro do número real de resultados gerados sem `count()`.
+ Correção de um erro do openCypher em que uma exceção de incompatibilidade de assinatura com defeito era gerada pelo servidor para solicitações do Bolt para clusters com a autenticação do IAM habilitada.
+ Correção de um erro do openCypher em que uma consulta 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 que poderia causar um erro interno quando uma consulta que gerava um valor constante era enviada.
+ Correção de um erro nos detalhes da explicação para que a subconsulta do DFE `Time(ms)` agora some corretamente os tempos de CPU dos operadores na subconsulta do DFE. Pense no seguinte trecho da saída de explicação como exemplo:
```
subQuery1
╔════╤════════╤════════╤═══════════════════════╤═══════════════════════════════════╤══════╤══════════╤═══════════╤═══════╤═══════════╗
║ ID │ Out #1 │ Out #2 │ Name │ Arguments │ Mode │ Units In │ Units Out │ Ratio │ Time (ms) ║
╠════╪════════╪════════╪═══════════════════════╪═══════════════════════════════════╪══════╪══════════╪═══════════╪═══════╪═══════════╣
...
╟────┼────────┼────────┼───────────────────────┼───────────────────────────────────┼──────┼──────────┼───────────┼───────┼───────────╢
║ 1 │ 2 │ - │ DFEChunkLocalSubQuery │ subQuery=...graph#336e.../graph_1 │ - │ 1 │ 1 │ 1.00 │ 0.38 ║
║ │ │ │ │ coordinationTime(ms)=0.026 │ │ │ │ │ ║
╟────┼────────┼────────┼───────────────────────┼───────────────────────────────────┼──────┼──────────┼───────────┼───────┼───────────╢
...
subQuery=...graph#336e.../graph_1
╔════╤════════╤════════╤═══════════════════════╤═══════════════════════════════════╤══════╤══════════╤═══════════╤═══════╤═══════════╗
║ ID │ Out #1 │ Out #2 │ Name │ Arguments │ Mode │ Units In │ Units Out │ Ratio │ Time (ms) ║
╠════╪════════╪════════╪═══════════════════════╪═══════════════════════════════════╪══════╪══════════╪═══════════╪═══════╪═══════════╣
║ 0 │ 1 │ - │ DFESolutionInjection │ solutions=[?100 -> [-10^^]] │ - │ 0 │ 1 │ 0.00 │ 0.04 ║
║ │ │ │ │ outSchema=[?100] │ │ │ │ │ ║
╟────┼────────┼────────┼───────────────────────┼───────────────────────────────────┼──────┼──────────┼───────────┼───────┼───────────╢
║ 1 │ 3 │ - │ DFERelationalJoin │ joinVars=[] │ - │ 2 │ 1 │ 0.50 │ 0.29 ║
╟────┼────────┼────────┼───────────────────────┼───────────────────────────────────┼──────┼──────────┼───────────┼───────┼───────────╢
║ 2 │ 1 │ - │ DFESolutionInjection │ outSchema=[] │ - │ 0 │ 1 │ 0.00 │ 0.01 ║
╟────┼────────┼────────┼───────────────────────┼───────────────────────────────────┼──────┼──────────┼───────────┼───────┼───────────╢
║ 3 │ - │ - │ DFEDrain │ - │ - │ 1 │ 0 │ 0.00 │ 0.02 ║
╚════╧════════╧════════╧═══════════════════════╧═══════════════════════════════════╧══════╧══════════╧═══════════╧═══════╧═══════════╝
```
Os tempos de subconsulta na última coluna da tabela inferior somam 0,36 ms (`.04 + .29 + .01 + .02 = .36`). Ao adicionar ao tempo de coordenação dessa subconsulta (`.36 + .026 = .386`), você obtém um resultado próximo ao horário da subconsulta registrada na última coluna da tabela superior, ou seja, `0.38` ms.
## 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.0.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.2.0.0 do mecanismo
Como essa é uma versão principal do mecanismo, não há atualização automática para ela.
Somente é possível atualizar para a versão `1.2.0.0` manualmente a partir da versão de patch mais recente da [versão 1.1.1.0 do mecanismo](engine-releases-1.1.1.0.md). É necessário primeiro atualizar as versões anteriores do mecanismo para a versão mais recente de `1.1.1.0` para que seja possível atualizá-las para `1.2.0.0`.
Portanto, antes de tentar atualizar para esta versão, confirme se você está executando a versão de patch mais recente da versão `1.1.1.0`. Se não estiver, comece atualizando para a versão de patch mais recente da `1.1.1.0`.
Antes da atualização, também é necessário recriar qualquer grupo de parâmetros de cluster de banco de dados personalizado que você estava usando com a versão anterior, usando a família de grupos de parâmetros `neptune1.2`. Consulte [Grupos de parâmetros do Amazon Neptune](parameter-groups.md) para obter mais informações.
Se você atualizar primeiro para a versão `1.1.1.0` e logo depois para `1.2.0.0`, 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 (consulte [Manter o cluster de banco de dados do Amazon Neptune](cluster-maintenance.md)).
## Atualizar para esta versão
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.0.0 \
4. --allow-major-version-upgrade \
5. --apply-immediately
```
Para Windows:
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.2.0.0 ^
4. --allow-major-version-upgrade ^
5. --apply-immediately
```
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.2.0.0.R4 (29/09/2023)
Desde 29/09/2023, a versão 1.2.0.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.
**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.
+ Para clusters de banco de dados sem servidor, foram alteradas a configuração de capacidade mínima para 1,0 NCU e a configuração máxima válida mais baixa para 2,5 NCUs. Consulte [Escalabilidade da capacidade em um cluster de banco de dados do Neptune Serverless](neptune-serverless-capacity-scaling.md) *(antes do lançamento, essa alteração também precisa ser refletida na página sem servidor).*
## 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 no tratamento de transações do Bolt.
+ 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. Por exemplo, para consultas como esta:
```
g.withSideEffect('Neptune#useDFE', true)
.V()
.as("a")
.select("a")
.by(out()
.limit(1))
```
+ Correção de um erro do Gremlin em que uma consulta falhava porque continha muitas etapas do TinkerPop e não era limpa.
+ Correção de um erro do Gremlin em que `order()` não classificava corretamente as saídas de string quando algumas delas continham um caractere de espaço.
+ Correção de um erro do Gremlin em que um vazamento de transação podia ocorrer quando uma consulta era enviada como uma string e continha `GroupCountStep`.
+ 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 Gremlin em que adicionar uma borda e suas propriedades seguidas por `inV()` ou `outV()` causava uma `InternalFailureException`.
+ Correção de um erro de simultaneidade na camada de armazenamento.
## 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.0.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.6`
+ *openCypher versão:* `Neptune-9.0.20190305-1.0`
+ *SPARQL versão:* `1.1`
## Caminhos de atualização para a versão 1.2.0.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.2.0.0`.
Somente é possível atualizar para a versão `1.2.0.0` manualmente a partir da versão de patch mais recente da [versão 1.1.1.0 do mecanismo](engine-releases-1.1.1.0.md). É necessário primeiro atualizar as versões anteriores do mecanismo para a versão mais recente de `1.1.1.0` para que seja possível atualizá-las para `1.2.0.0`.
Se você atualizar primeiro para a versão `1.1.1.0` e logo depois para `1.2.0.0`, 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.
## Atualizar para esta versão
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.0.0 \
4. --allow-major-version-upgrade \
5. --apply-immediately
```
Para Windows:
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.2.0.0 ^
4. --allow-major-version-upgrade ^
5. --apply-immediately
```
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.2.0.0.R3 (15/12/2022)
Desde 15/12/2022, a versão 1.2.0.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.
**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
+ Melhoria no desempenho das consultas do openCypher que envolvem `MERGE` e `OPTIONAL MATCH`.
+ Melhoria no desempenho das consultas do openCypher que envolvem `UNWIND` em 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 as consultas geravam uma string, `"null"`, em vez de um valor nulo em Bolt e SPARQL-JSON.
+ Correção de um erro do openCypher para interpretar o tipo de parâmetro corretamente quando o valor é uma lista ou uma lista de mapas.
+ 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.
+ Correção de um erro no log de auditoria em que o ARN do IAM das solicitações HTTP para um cluster de banco de dados habilitado para IAM não era registrado.
+ Correção de um erro no cache de pesquisa para limitar a memória incremental usada para gravações no cache.
+ Correção de um erro do cache de pesquisa que envolvia a configuração do modo somente leitura para o cache de pesquisa quando as gravações falhavam.
## 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.0.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.2.0.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.2.0.0`.
Somente é possível atualizar para a versão `1.2.0.0` manualmente a partir da versão de patch mais recente da [versão 1.1.1.0 do mecanismo](engine-releases-1.1.1.0.md). É necessário primeiro atualizar as versões anteriores do mecanismo para a versão mais recente de `1.1.1.0` para que seja possível atualizá-las para `1.2.0.0`.
Se você atualizar primeiro para a versão `1.1.1.0` e logo depois para `1.2.0.0`, 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.
## Atualizar para esta versão
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.0.0 \
4. --allow-major-version-upgrade \
5. --apply-immediately
```
Para Windows:
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.2.0.0 ^
4. --allow-major-version-upgrade ^
5. --apply-immediately
```
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.2.0.0.R2 (14/10/2022)
Desde 14/10/2022, a versão 1.2.0.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
+ 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.
+ Melhoria no desempenho das consultas do Gremlin que usam `dedup()` em uma subconsulta `repeat()` enviando `dedup` à camada de execução nativa.
+ Adição da dica de consulta `Neptune#cardinalityEstimates` do Gremlin. Quando definido como `false`, isso desabilita as estimativas de cardinalidade.
+ Adição de mensagens de erro fáceis de usar para erros de autenticação do IAM. Agora, essas mensagens mostram o ARN do usuário ou do perfil do IAM, o ARN do recurso e uma lista de ações não autorizadas da solicitação. A lista de ações não autorizadas ajuda você a ver o que pode estar faltando ou é explicitamente negado na política do IAM que você está usando.
## Defeitos corrigidos nesta versão do mecanismo
+ Correção de um erro de exatidão do Gremlin envolvendo a conversão de `WherePredicateStep`, em que o mecanismo de consulta do Neptune estava produzindo resultados incorretos para consultas que usavam `where(P.neq('x'))` e as variações dela.
+ Correção de um erro do Gremlin em que o uso de `PartitionStrategy` após a atualização para o TinkerPop 3.5 gerava incorretamente um erro com a mensagem “PartitionStrategy não funciona com percursos anônimos”, o que impedia a execução do percurso.
+ Correção de vários erros do Gremlin relacionados ao `joinTime` de uma junção final e às estatísticas nos subgrupos `Project.ASK`.
+ 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 de transação em que uma sessão podia inserir dados de grafos e confirmar mesmo quando as inserções simultâneas correspondentes do dicionário eram revertidas.
+ Correção de um erro do carregador em massa que causava regressões de desempenho sob cargas de inserção pesadas.
+ 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 em que os drivers pareciam travar nos casos em que as solicitações eram canceladas devido a um tempo limite antes do início da avaliação. Era possível entrar nesse estado se todos os threads de processamento de consultas no servidor fossem consumidos enquanto os tempos limite ocorressem nos itens na fila de solicitações. Como os tempos limite da fila de solicitações não estavam enviando mensagens imediatamente, as respostas pareciam pendentes para o cliente.
## 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.0.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.2.0.0.R2 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.2.0.0`.
Somente é possível atualizar para a versão `1.2.0.0` manualmente a partir da versão de patch mais recente da [versão 1.1.1.0 do mecanismo](engine-releases-1.1.1.0.md). É necessário primeiro atualizar as versões anteriores do mecanismo para a versão mais recente de `1.1.1.0` para que seja possível atualizá-las para `1.2.0.0`.
Se você atualizar primeiro para a versão `1.1.1.0` e logo depois para `1.2.0.0`, 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.
## Atualizar para esta versão
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.0.0 \
4. --allow-major-version-upgrade \
5. --apply-immediately
```
Para Windows:
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.2.0.0 ^
4. --allow-major-version-upgrade ^
5. --apply-immediately
```
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).