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á.
# Manter o cluster de banco de dados do Amazon Neptune
O Neptune realiza manutenção periódica em todos os recursos que usa, incluindo:
+ **Substituir o hardware subjacente conforme necessário.** Isso acontece em segundo plano, sem que você precise realizar nenhuma ação e geralmente não afeta as operações.
+ **Atualizar o sistema operacional subjacente.** As atualizações do sistema operacional das instâncias no cluster de banco de dados são realizadas para melhorar o desempenho e a segurança. Portanto, você deve concluí-las o mais rápido possível. Em geral, essas atualizações demoram cerca de dez minutos. As atualizações do sistema operacional não alteram a versão do mecanismo de banco de dados nem a classe de uma instância de banco de dados.
Em geral, é melhor atualizar primeiro as instâncias do leitor em um cluster de banco de dados e depois a instância do gravador. Atualizar os leitores e o gravador ao mesmo tempo pode causar um período de inatividade no caso de um failover. O backup das instâncias de banco de dados não é feito automaticamente antes de uma atualização do sistema operacional. Dessa forma, faça backups manuais antes de aplicar uma atualização do sistema operacional.
+ **Atualizar o mecanismo do banco de dados Neptune.** O Neptune lança regularmente uma variedade de atualizações do mecanismo para introduzir novos recursos e melhorias e corrigir bugs.
## Números das versões do mecanismo
### Numeração de versão antes da versão 1.3.0.0 do mecanismo
Antes de novembro de 2019, o Neptune era compatível apenas com uma versão do mecanismo por vez, e os números de versão do mecanismo tinham todos o mesmo formato, `1.0.1.0.200`, em que `xxx` era o número do patch. As novas versões do mecanismo foram todas lançadas como patches para versões anteriores.
Em novembro de 2019, o Neptune passou a ser compatível com várias versões, oferecendo aos clientes um melhor controle dos caminhos de atualização. Consequentemente, a numeração de versões do mecanismo foi alterada.
De novembro de 2019 até a [versão 1.3.0.0 do mecanismo](engine-releases-1.3.0.0.md), os números de versão tinham cinco partes. Por exemplo, no número de versão `1.0.2.0.R2`:
+ A primeira parte sempre foi 1.
+ A segunda parte, (`0` em `1.0.2.0.R2`), era o número da versão principal do banco de dados.
+ A terceira e a quarta parte, (`2.0` em `1.0.2.0.R2`), eram números de versão secundária.
+ A quinta parte, (`R2` em `1.0.2.0.R2`), era o número do patch.
A maioria das atualizações era atualizações de patches, e a distinção entre patches e atualizações de versões secundárias nem sempre era clara.
### Numeração de versão a partir da versão 1.3.0.0 do mecanismo
A partir da [versão 1.3.0.0 do mecanismo](engine-releases-1.3.0.0.md), o Neptune mudou a forma como as atualizações do mecanismo são numeradas e gerenciadas.
Os números de versão do mecanismo agora têm quatro partes, cada uma correspondendo a um tipo de versão, da seguinte forma:
*product-version***.***major-version***.***minor-version***.***patch-version*
Alterações ininterruptas do tipo que foram lançadas anteriormente como patches agora são lançadas como versões secundárias que você pode gerenciar usando a configuração da instância [`AutoMinorVersionUpgrade`](engine-maintenance-management.md#using-amvu).
Isso significa que, se você quiser, poderá receber uma notificação sempre que uma nova versão secundária for lançada, basta assinar o evento [`RDS-EVENT-0156`](event-lists.md#RDS-EVENT-0156) (consulte [Assinar a notificação de eventos do Neptune](events-subscribing.md)).
As versões de patches agora estão reservadas para correções direcionadas urgentes e são numeradas usando a última parte do número da versão (`*.*.*.1`, `*.*.*.2` e assim por diante).
# Diferentes tipos de versões do mecanismo no Amazon Neptune
Os quatro tipos de versão do mecanismo que correspondem às quatro partes de um número de versão do mecanismo são os seguintes:
+ **Versão do produto**: é alterada somente se o produto passar por mudanças amplas e fundamentais na funcionalidade ou interface. A versão atual do produto Neptune é 1.
+ [**Versão principal**](#major-versions): a versões principais introduzem novos recursos importantes e mudanças significativas e geralmente têm uma vida útil de pelo menos dois anos.
+ [**Versão secundária**](#minor-versions): as versões secundárias podem conter novos recursos, melhorias e correções de erros, mas não contêm alterações significativas. Você pode escolher se deseja ou não que sejam aplicadas automaticamente durante a próxima janela de manutenção, além de optar por receber uma notificação sempre que for lançada.
+ [**Versão de patch**](#patch-version-updates): as versões de patch são lançadas somente para tratar de correções de erros urgentes ou atualizações críticas de segurança. Raramente contêm alterações significativas e são aplicadas automaticamente durante a próxima janela de manutenção após o lançamento.
## Atualizações da versão principal do Amazon Neptune
Uma atualização de versão principal geralmente introduz um ou mais recursos novos e importantes e geralmente contém alterações significativas. Normalmente, tem uma vida útil de suporte de cerca de dois anos. As versões principais do Neptune estão listadas nas [versões do mecanismo](engine-releases.md), junto com a data em que foram lançadas e o fim da vida útil estimado.
As atualizações da versão principal são totalmente opcionais até que a versão principal utilizada chegue ao fim da vida útil. Se você optar por atualizar para uma nova versão principal, você mesmo deverá instalar a nova versão usando o console do Neptune AWS CLI ou do Neptune, conforme descrito em. [Atualizações da versão principal](engine-updates-manually.md)
No entanto, se a versão principal utilizada chegar ao fim da vida útil, você receberá uma notificação de que é necessário atualizar para uma versão principal mais recente. Dessa forma, se você não fizer a atualização dentro de um período de carência após a notificação, uma atualização para a versão principal mais recente será programada automaticamente para ocorrer durante a próxima janela de manutenção. Consulte [Vida útil da versão do mecanismo](engine-updates-eol-planning.md) para obter mais informações.
## Atualizações da versão secundária do Amazon Neptune
A maioria das atualizações do mecanismo do Neptune são atualizações de versões secundárias. Elas acontecem com bastante frequência e não contêm alterações significativas.
Se o campo [`AutoMinorVersionUpgrade`](engine-maintenance-management.md#using-amvu) estiver definido como `true` na instância (primária) do gravador do cluster de banco de dados, as atualizações da versão secundária serão aplicadas automaticamente a todas as instâncias no cluster de banco de dados durante a próxima janela de manutenção após o lançamento.
Se o campo [`AutoMinorVersionUpgrade`](engine-maintenance-management.md#using-amvu) estiver definido como `false` na instância do gravador do cluster de banco de dados, elas serão aplicadas somente se você [instalá-las explicitamente](engine-updates-manually.md).
**nota**
As atualizações de versões secundárias são independentes (não dependem das atualizações anteriores da versão secundária para a mesma versão principal) e cumulativas (elas contêm todos os recursos e correções introduzidos nas atualizações de versões secundárias anteriores). Isso significa que você pode instalar qualquer atualização de versão secundária, independentemente de ter instalado ou não as anteriores.
É fácil acompanhar os lançamentos de versões secundárias assinando o evento [`RDS-EVENT-0156`](event-lists.md#RDS-EVENT-0156) (consulte [Assinar a notificação de eventos do Neptune](events-subscribing.md)). Em seguida, você receberá notificações sempre que uma nova versão secundária for lançada.
Além disso, independentemente de você assinar ou não as notificações, sempre poderá [verificar quais atualizações estão pendentes](engine-maintenance-management.md#check-pending-updates).
## Atualizações de versão de patch do Amazon Neptune
No caso de problemas de segurança ou outros defeitos graves que afetam a confiabilidade da instância, o Neptune implanta patches obrigatórios. Eles são aplicados a todas as instâncias no cluster de banco de dados durante próxima janela de manutenção, sem qualquer intervenção de sua parte.
Uma versão de patch é implantada somente quando os riscos de não implantá-la superam os riscos e o tempo de inatividade associados à implantação. As versões de patch não ocorrem com frequência (geralmente uma vez a cada poucos meses) e raramente exigem mais do que uma fração de sua janela de manutenção para serem aplicadas.
# Planejar a vida útil da versão principal do mecanismo do Amazon Neptune
As versões do mecanismo do Neptune quase sempre chegam ao fim da vida útil no final de um trimestre civil. As exceções ocorrem somente quando surgem problemas importantes de segurança ou disponibilidade.
Quando uma versão do mecanismo chegar ao fim da vida útil, você precisará atualizar o banco de dados Neptune para uma versão mais recente.
Em geral, as versões do mecanismo do Neptune continuam disponíveis da seguinte forma:
+ **Versões secundárias do mecanismo:** as versões secundárias do mecanismo permanecem disponíveis por pelo menos seis meses após o lançamento.
+ **Versões principais do mecanismo:** as versões principais do mecanismo permanecem disponíveis por pelo menos 12 meses após o lançamento.
Pelo menos 3 meses antes de uma versão do motor chegar ao fim de sua vida útil, AWS enviará uma notificação automática por e-mail para o endereço de e-mail associado à sua AWS conta e publicará a mesma mensagem no seu [AWS Health Dashboard](https://docs.aws.amazon.com/health/latest/ug/aws-health-dashboard-status.html). Isso dará tempo para planejar e se preparar para a atualização.
Quando uma versão do mecanismo chegar ao fim da vida útil, você não poderá mais criar clusters ou instâncias usando essa versão, nem o ajuste de escala automático poderá criar instâncias usando essa versão.
Uma versão do mecanismo que realmente chegue ao fim da vida útil será atualizada automaticamente durante uma janela de manutenção. A mensagem enviada a você três meses antes do fim da vida útil da versão do mecanismo conterá detalhes sobre o que essa atualização automática envolverá, incluindo a versão para a qual o mecanismo será atualizado automaticamente, o impacto nos clusters de banco de dados e as ações que recomendamos.
**Importante**
Você é responsável por manter as versões do mecanismo de banco de dados atualizadas. A AWS incentiva todos os clientes a atualizar os bancos de dados para a versão mais recente do mecanismo, a fim de se beneficiarem das proteções de segurança, privacidade e disponibilidade mais atualizadas. Se você operar o banco de dados em um mecanismo ou um software não compatível após a data de defasagem (“Mecanismo herdado”), enfrentará uma maior probabilidade de riscos operacionais, segurança e privacidade, incluindo eventos de inatividade.
A operação do seu banco de dados em qualquer mecanismo está sujeita ao Contrato que rege o uso dos AWS Serviços. Os motores antigos não estão disponíveis ao público em geral. AWS não fornece mais suporte para o Legacy Engine e AWS pode limitar o acesso ou o uso de qualquer Legacy Engine a qualquer momento, se AWS determinar que o Legacy Engine representa um risco de segurança ou responsabilidade, ou um risco de danos, aos Serviços AWS, a suas Afiliadas ou a terceiros. Sua decisão de continuar executando Seu conteúdo em um Mecanismo herdado pode fazer com que Seu conteúdo fique indisponível, corrompido ou irrecuperável. Os bancos de dados executados em um Mecanismo herdado estão sujeitos às exceções do Acordo de Serviço (SLA).
BANCOS DE DADOS E SOFTWARES RELACIONADOS EXECUTADOS EM UM MECANISMO LEGADO CONTÊM BUGS, ERROS, DEFEITOS E COMPONENTES AND/OR NOCIVOS. CONSEQUENTEMENTE, E NÃO OBSTANTE QUALQUER DISPOSIÇÃO EM CONTRÁRIO NO CONTRATO OU NOS TERMOS DO SERVIÇO, AWS ESTÁ FORNECENDO O MECANISMO ANTIGO “NO ESTADO EM QUE SE ENCONTRA”.
# Gerenciar atualizações do mecanismo no cluster de banco de dados do Neptune
**nota**
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 em todas essas instâncias, ocorrerá um tempo de inatividade de vinte ou trinta segundos a alguns minutos. Depois disso, você poderá retomar o uso do cluster de banco de dados. Em raras ocasiões, um failover Multi-AZ pode ser necessário para concluir uma atualização de manutenção em uma instância.
Para atualizações de versões principais que podem levar mais tempo para serem aplicadas, você pode usar uma [estratégia de implantação azul/verde](neptune-BG-deployments.md) para minimizar o tempo de inatividade.
## Determinar qual versão do mecanismo você está usando no momento
Você pode usar o AWS CLI [`get-engine-status`](access-graph-status.md)comando para verificar qual versão de lançamento do mecanismo seu cluster de banco de dados está usando atualmente:
```
aws neptunedata get-engine-status
```
A [saída JSON](access-graph-status.md#access-graph-status-sample-output) inclui um campo `"dbEngineVersion"` como este:
```
"dbEngineVersion": "1.3.0.0",
```
## Verifique quais atualizações estão pendentes e disponíveis
Você pode verificar as atualizações pendentes do cluster de banco de dados do usando o console do Neptune. Selecione **Bancos de dados** na coluna esquerda e, em seguida, o cluster de banco de dados no painel de bancos de dados. As atualizações pendentes estão listadas na coluna **Manutenção**. Se você selecionar **Ações** e, em seguida, **Manutenção**, você tem três opções:
+ Atualizar agora.
+ Atualizar na próxima janela.
+ Adiar atualização.
Você pode listar as atualizações pendentes do mecanismo usando o AWS CLI seguinte:
```
aws neptune describe-pending-maintenance-actions \
--resource-identifier (ARN of your DB cluster)
--region (your region) \
--engine neptune
```
Você também pode listar as atualizações de mecanismo disponíveis usando o AWS CLI seguinte:
```
aws neptune describe-db-engine-versions \
--region (your region) \
--engine neptune
```
A lista de versões disponíveis do mecanismo inclui somente as versões com um número maior do que a atual e para as quais há um caminho de atualização definido.
## 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. Uma atualização secundária pode introduzir novos recursos ou comportamentos que afetam o código mesmo sem nenhuma alteração significativa.
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 é usar a [solução de implantação azul/verde do Neptune](neptune-BG-deployments.md). Dessa forma, você pode executar aplicações e consultas na nova versão 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.
## Janela de manutenção do Neptune
A janela de manutenção semanal é um período de 30 minutos durante o qual as atualizações programadas do mecanismo e outras alterações do sistema são aplicadas. A maioria dos eventos de manutenção é concluída durante a janela de 30 minutos, embora os eventos de manutenção mais longos possam levar mais tempo para serem concluídos.
Cada cluster de banco de dados tem uma janela de manutenção semanal de 30 minutos. Se você não especificar um horário de preferência ao criar o cluster de banco de dados, o Neptune selecionará aleatoriamente um dia da semana e também atribuirá aleatoriamente um período de 30 minutos a partir de um bloco de 8 horas que varia de acordo com a região.
Aqui, por exemplo, estão os blocos de tempo de 8 horas para janelas de manutenção usadas em várias regiões da AWS :
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/neptune/latest/userguide/engine-maintenance-management.html)
A janela de manutenção determina quando as operações pendentes começam, e a maioria das operações de manutenção é concluída dentro da janela, mas tarefas de manutenção maiores podem continuar além do horário de término da janela.
### Mover a janela de manutenção do cluster de banco de dados
O ideal é que sua janela de manutenção caia no momento em que o cluster estiver em menor uso. Se isso não se aplica à sua janela atual, você pode movê-la para um horário melhor, da seguinte forma:
**Para alterar a janela de manutenção do cluster de banco de dados**
1. [Faça login no AWS Management Console e abra o console do Amazon Neptune em casa. https://console.aws.amazon.com/neptune/](https://console.aws.amazon.com/neptune/home)
1. No painel de navegação, escolha **Bancos de dados**.
1. Escolha o cluster de banco de dados para o qual deseja alterar a janela de manutenção.
1. Selecione **Modify**.
1. Escolha **Mostrar mais** na parte inferior da página **Modificar cluster**.
1. Na seção **Janela de manutenção preferencial**, defina o dia, a hora e a duração da janela de manutenção conforme sua preferência.
1. Escolha **Próximo**.
Na página de confirmação, revise suas alterações.
1. Para aplicar as alterações à janela de manutenção imediatamente, selecione **Apply immediately (Aplicar imediatamente)**.
1. Escolha **Enviar** para aplicar as alterações.
Para editar as alterações, selecione **Anterior** ou, para cancelar as alterações, escolha **Cancelar**.
## Usando AutoMinorVersionUpgrade para controlar atualizações automáticas de versões secundárias
**Importante**
`AutoMinorVersionUpgrade` só é eficaz para atualizações de versões secundárias posterior à [versão 1.3.0.0 do mecanismo](engine-releases-1.3.0.0.md).
Se o campo `AutoMinorVersionUpgrade` estiver definido como `true` na instância (primária) do gravador do cluster de banco de dados, as atualizações da versão secundária serão aplicadas automaticamente a todas as instâncias no cluster de banco de dados durante a próxima janela de manutenção após o lançamento.
Se o campo `AutoMinorVersionUpgrade` estiver definido como `false` na instância do gravador do cluster de banco de dados, elas serão aplicadas somente se você [instalá-las explicitamente](engine-updates-manually.md#engine-minor-updates-using-console).
**nota**
As versões de patch (`*.*.*.1`, `*.*.*.2` etc.) são sempre instaladas automaticamente durante a próxima janela de manutenção, independentemente de como o parâmetro `AutoMinorVersionUpgrade` está definido.
Você pode definir `AutoMinorVersionUpgrade` usando o Console de gerenciamento da AWS seguinte:
**Para definir `AutoMinorVersionUpgrade` usando o console do Neptune**
1. [Faça login no AWS Management Console e abra o console do Amazon Neptune em casa. https://console.aws.amazon.com/neptune/](https://console.aws.amazon.com/neptune/home)
1. No painel de navegação, escolha **Bancos de dados**.
1. Escolha a instância primária (gravador) do cluster de banco de dados para o qual você deseja definir `AutoMinorVersionUpgrade`.
1. Escolha **Modificar**.
1. Escolha **Mostrar mais** na parte inferior da página **Modificar cluster**.
1. Na parte inferior da página expandida, escolha **Ativar atualização automática de versão secundária** ou **Desabilitar o upgrade automático da versão secundária**.
1. Escolha **Próximo**.
Na página de confirmação, revise suas alterações.
1. Para aplicar as alterações na atualização automática de versões secundárias, selecione **Aplicar imediatamente**.
1. Escolha **Enviar** para aplicar as alterações.
Para editar as alterações, selecione **Anterior** ou, para cancelar as alterações, escolha **Cancelar**.
Você também pode usar o AWS CLI para definir o `AutoMinorVersionUpgrade` campo. Por exemplo, para defini-lo como `true`, você pode usar um comando como este:
```
1. aws neptune modify-db-instance \
2. --db-instance-identifier (the ID of your cluster's writer instance) \
3. --auto-minor-version-upgrade \
4. --apply-immediately
```
Da mesma forma, para defini-lo como `false`, use um comando como este:
```
1. aws neptune modify-db-instance \
2. --db-instance-identifier (the ID of your cluster's writer instance) \
3. --no-auto-minor-version-upgrade \
4. --apply-immediately
```
# Instalar atualizações no mecanismo do Neptune manualmente
## Como instalar uma atualização da versão principal do mecanismo
As versões principais do mecanismo sempre devem ser instaladas manualmente. Para minimizar o tempo de inatividade e fornecer bastante tempo para testes e validação, a melhor maneira de instalar uma nova versão principal geralmente é usar a [solução de implantação azul/verde do Neptune](neptune-BG-deployments.md).
Em alguns casos, você também pode usar o CloudFormation modelo com o qual criou seu cluster de banco de dados para instalar uma atualização de versão principal (consulte[Usando um CloudFormation modelo para atualizar a versão do mecanismo do seu Neptune DB Cluster](cfn-engine-update.md)).
Se você quiser instalar uma atualização da versão principal imediatamente, você pode usar um comando da CLI como o seguinte:
```
aws neptune modify-db-cluster \
--db-cluster-identifier (identifier for your neptune cluster) \
--engine neptune \
--engine-version (the new engine version) \
--apply-immediately
```
Especifique a versão do mecanismo para a qual você deseja atualizar. Caso contrário, o mecanismo poderá ser atualizado para uma versão que não seja a mais recente nem a esperada.
Em vez de `--apply-immediately`, é possível especificar `--no-apply-immediately`.
Se o cluster usar um grupo de parâmetros de cluster personalizado, use 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, use este parâmetro para especificá-lo:
```
---db-instance-parameter-group-name (name of the custom instance parameter group)
```
## Instalando uma atualização secundária do mecanismo de versão usando o Console de gerenciamento da AWS
**Para fazer uma atualização da versão secundária usando o console Neptune**
1. [Faça login no AWS Management Console e abra o console do Amazon Neptune em casa. https://console.aws.amazon.com/neptune/](https://console.aws.amazon.com/neptune/home)
1. No painel de navegação, escolha **Bancos de dados** e selecione o cluster de banco de dados que você deseja modificar.
1. Escolha **Modificar**.
1. Em **Especificações da instância**, escolha a nova versão para a qual você deseja atualizar.
1. Escolha **Próximo**.
1. Para aplicar alterações imediatamente, escolha **Aplicar imediatamente**.
1. Escolha **Enviar** para atualizar o cluster de banco de dados.
## Instalando uma atualização secundária do mecanismo de versão usando o AWS CLI
Você pode usar um comando como o seguinte para realizar uma atualização da versão secundária sem esperar pela próxima janela de manutenção:
```
aws neptune modify-db-cluster \
--db-cluster-identifier (your-neptune-cluster) \
--engine-version (new-engine-version) \
--apply-immediately
```
Se você estiver atualizando manualmente usando o AWS CLI, não se esqueça de incluir a versão do mecanismo para a qual você deseja atualizar. Caso contrário, o mecanismo poderá ser atualizado para uma versão que não seja a mais recente nem a esperada.
# Realizar a atualização para a versão 1.2.0.0 ou posterior do mecanismo a partir de uma versão anterior à 1.2.0.0
A [versão 1.2.0.0 do mecanismo](engine-releases-1.2.0.0.md) introduziu algumas alterações significativas que podem tornar a atualização de uma versão anterior mais complicada do que o normal:
+ 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 Engine introduziu um novo formato para desfazer registros. Consequentemente, se você estiver atualizando para a versão 1.2.0.0 ou superior de uma versão anterior à 1.2.0.0, a [`UndoLogListSize`](cw-metrics.md#cw-metrics-UndoLogListSize)métrica deverá estar abaixo de um determinado limite. Caso contrário, o patch será revertido e falhará. Os limites são baseados no tipo de instância: o limite padrão é 40k para instâncias 4xlarge ou maiores e 10k para instâncias menores que 4xlarge. Se `UndoLogListSize` exceder o limite ao tentar fazer o upgrade, o processo de patch será revertido, a atualização será cancelada e um evento com o motivo ficará visível na página de eventos do cluster. Esses limites podem mudar por motivos operacionais sem aviso prévio.
É 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 fazer o upgrade pode ajudar a reduzir o limite `UndoLogListSize` abaixo do limite aplicável. 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 `UndoLogListSize` CloudWatch métrica for extremamente grande, abrir um caso de suporte pode ajudá-lo a explorar estratégias adicionais para reduzi-la abaixo do limite exigido.
+ 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.