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á.
# Manutenção do Amazon DocumentDB
O Amazon DocumentDB realiza periodicamente dois tipos de manutenção:
+ A **manutenção do cluster** atualiza o mecanismo do banco de dados. As atualizações do mecanismo incluem correções de segurança, correções de erros, novos recursos e outros aprimoramentos do mecanismo.
+ A **manutenção da instância** atualiza o sistema operacional (SO) na instância.
Os patches do mecanismo e as atualizações do sistema operacional usam as mesmas três categorias de ciclo de vida — *opcionais*, *obrigatórias* e *forçadas* — com a mesma notificação e comportamento de aplicação para cada categoria. Os lançamentos de motores também têm uma quarta categoria: *versões secundárias*, para as quais você atualiza manualmente. As categorias são:
+ **Opcional** — contém melhorias não críticas. Sem data de aplicação automática e sem notificação de AHD; aplique quando quiser. (Para atualizações do sistema operacional, você pode se inscrever `RDS-EVENT-0230` para ser notificado quando uma estiver disponível.)
+ **Obrigatório** — contém correções de segurança e outras correções críticas. Você recebe uma notificação por meio do Health Dashboard (AHD) e e-mail. Uma ação necessária se aplica automaticamente durante a janela de manutenção do cluster ou da instância após a sua`AutoAppliedAfterDate`. Você pode adiar alterando a janela de manutenção antes dessa data.
+ **Forçado** — uma solução rara e altamente crítica. Auto-applies fora de sua janela de manutenção após sua`ForcedApplyDate`. O Amazon DocumentDB só designa uma ação forçada quando nenhuma outra opção está disponível.
+ **Versão secundária** (somente versões de motor) — uma versão de motor numerada em cima de uma versão principal (por exemplo,`5.0.1`). User-driven: você atualiza modificando a versão do mecanismo do cluster. Nunca se aplica automaticamente; sem notificação de AHD. Versões secundárias não são publicadas para versões principais anteriores à 5.0.
Os patches do motor são lançados em uma única categoria (opcional, obrigatório ou forçado) e permanecem lá. O progresso das atualizações do sistema operacional: a maioria começa como opcional e, se não for aplicada, passa para o obrigatório e, eventualmente, forçada. O tempo exato depende do patch e é publicado na notificação do AHD e nos campos de data retornados por `describe-pending-maintenance-actions` (consulte[Aplicar datas](#db-instance-updates-apply-date)). As [notas de versão](https://docs.aws.amazon.com/documentdb/latest/devguide/release-notes.html) do Amazon DocumentDB usam esses nomes de categoria ao anunciar mudanças no mecanismo.
A aplicação de qualquer patch de mecanismo coloca o cluster offline brevemente. O restante deste tópico explica como as janelas de manutenção funcionam, como encontrar trabalhos pendentes, como aplicar patches de mecanismo e versões secundárias, como as atualizações do sistema operacional funcionam e como lidar com clusters globais.
**Topics**
+ [Numeração da versão do motor](#engine-version-numbering)
+ [Gerenciar suas janelas de manutenção do Amazon DocumentDB](#maintenance-window)
+ [Notificações para patches do mecanismo do Amazon DocumentDB](#patch-notifications)
+ [Consultar ações de manutenção pendentes do Amazon DocumentDB](#view-pending-maintenance)
+ [Atualizações do mecanismo do Amazon DocumentDB](#db-instance-updates-apply)
+ [Atualizações de versões secundárias](#minor-version-upgrades)
+ [Atualizações do sistema operacional do Amazon DocumentDB](#os-system-updates)
+ [User-initiated atualizações](#user-initiated-updates)
+ [Correção de clusters globais](#global-clusters-patching)
## Numeração da versão do motor
O Amazon DocumentDB usa dois identificadores de versão separados:
+ **Versão do motor** — um número de três partes no formulário `{{major}}.{{major}}.{{minor}}` (por exemplo, `5.0.0` ou`5.0.1`). As duas primeiras partes (`5.0`) são a versão de compatibilidade do MongoDB; a terceira parte é a versão secundária, incrementada quando o Amazon DocumentDB publica uma versão secundária contendo correções de bugs e melhorias ininterruptas. Essa é a versão que você especifica ao criar ou atualizar um cluster.
+ **Versão do patch do mecanismo** — um número separado de três partes no formulário `{{major}}.0.{{patch}}` (por exemplo,`3.0.17983`) que identifica o nível do patch aplicado ao seu cluster. O dígito médio é sempre`0`. As versões de patch contêm correções críticas de segurança e estabilidade.
Você pode determinar a versão do mecanismo a partir do prefixo da versão do patch do mecanismo, conforme mostrado na tabela a seguir.
| Prefixo da versão do patch do motor | Versão do mecanismo Amazon DocumentDB |
| --- | --- |
| 1.0.{{x}} | 3.6 |
| 2.0.{{x}} | 4,0 |
| 3.0.{{x}} | 5,0 |
| 4.0.{{x}} | 8.0 |
Para verificar a versão do patch que seu cluster está executando, conecte-se e execute`db.runCommand({getEngineVersion: 1})`.
Para ver a lista das versões de patch de mecanismo lançadas e o que cada uma contém, consulte[Notas da versão](release-notes.md).
## Gerenciar suas janelas de manutenção do Amazon DocumentDB
Cada cluster e cada instância têm sua própria janela de manutenção semanal de 30 minutos — o período em que as modificações programadas e os patches de software são executados. A maioria dos eventos é concluída em 30 minutos; os maiores podem durar mais.
Se você não escolher uma janela ao criar o recurso, o Amazon DocumentDB atribuirá uma aleatoriamente dentro de um bloco diário de 8 horas definido para a região, em um dia selecionado aleatoriamente. Escolha janelas que minimizem o impacto em seu aplicativo — à noite ou nos fins de semana, por exemplo.
Para atualizações do mecanismo de banco de dados, o Amazon DocumentDB usa a janela do cluster, não as janelas de instâncias individuais.
A tabela a seguir mostra os blocos de tempo padrão por região.
| Nome da região | Região | Bloco de tempo UTC |
| --- | --- | --- |
| Leste dos EUA (Ohio) | us-east-2 | 03:00-11:00 |
| Leste dos EUA (Norte da Virgínia) | us-east-1 | 03:00-11:00 |
| Oeste dos EUA (Oregon) | us-west-2 | 06:00-14:00 |
| África (Cidade do Cabo) | af-south-1 | 03:00-11:00 |
| Ásia-Pacífico (Hong Kong) | ap-east-1 | 06:00-14:00 |
| Ásia-Pacífico (Hyderabad) | ap-south-2 | 06:30–14:30 |
| Ásia-Pacífico (Malásia) | ap-southeast-5 | 13:00-21:00 |
| Ásia-Pacífico (Mumbai) | ap-south-1 | 06:00-14:00 |
| Ásia-Pacífico (Osaka) | ap-northeast-3 | 12:00-20:00 |
| Ásia-Pacífico (Seul) | ap-northeast-2 | 13:00-21:00 |
| Ásia-Pacífico (Singapura) | ap-southeast-1 | 14:00-22:00 |
| Ásia-Pacífico (Sydney) | ap-southeast-2 | 12:00-20:00 |
| Ásia-Pacífico (Jacarta) | ap-southeast-3 | 08:00-16:00 |
| Ásia-Pacífico (Melbourne) | ap-southeast-4 | 11:00-19:00 |
| Ásia-Pacífico (Tailândia) | ap-southeast-7 | 15:00-23:00 |
| Ásia-Pacífico (Tóquio) | ap-northeast-1 | 13:00-21:00 |
| Canadá (Central) | ca-central-1 | 03:00-11:00 |
| Oeste do Canadá (Calgary) | ca-west-1 | 18:00-02:00 |
| China (Pequim) | cn-north-1 | 06:00-14:00 |
| China (Ningxia) | cn-northwest-1 | 06:00-14:00 |
| Europa (Frankfurt) | eu-central-1 | 21:00-05:00 |
| Europa (Zurique) | eu-central-2 | 02:00-10:00 |
| Europa (Irlanda) | eu-west-1 | 22:00-06:00 |
| Europa (Londres) | eu-west-2 | 22:00-06:00 |
| Europa (Milão) | eu-south-1 | 02:00-10:00 |
| Europa (Paris) | eu-west-3 | 23:59-07:29 |
| Europa (Espanha) | eu-south-2 | 02:00-10:00 |
| Europa (Estocolmo) | eu-north-1 | 04:00 — 12:00 |
| México (Centro) | mx-central-1 | 03:00-11:00 |
| Oriente Médio (Emirados Árabes Unidos) | me-central-1 | 05:00-13:00 |
| América do Sul (São Paulo) | sa-east-1 | 00:00-08:00 |
| Israel (Tel Aviv) | il-central-1 | 04:00-12:00 |
| AWS GovCloud (US-East) | us-gov-east-1 | 17:00-01:00 |
| AWS GovCloud (US-West) | us-gov-west-1 | 06:00-14:00 |
### Gerenciar suas janelas de manutenção do Amazon DocumentDB
Escolha a janela de menor tráfego possível e ajuste-a com o tempo à medida que seus padrões de tráfego mudam. O cluster ou a instância não estará disponível durante a janela somente se uma alteração no sistema — uma operação de armazenamento em escala ou uma alteração na classe da instância, por exemplo — exigir uma interrupção, e somente pelo tempo que essa alteração realmente precisar.
**Para alterar a janela de manutenção**
+ Para um cluster: consulte [Modificar um cluster do Amazon DocumentDB](db-cluster-modify.md).
+ Para uma instância: consulte [Modificar uma instância do Amazon DocumentDB](db-instance-modify.md).
## Notificações para patches do mecanismo do Amazon DocumentDB
Quando um patch de mecanismo *necessário* se torna disponível em uma AWS região, cada AWS conta com um cluster Amazon DocumentDB afetado nessa região recebe uma notificação por meio do Health Dashboard (AHD) e por e-mail (enviada para o endereço de usuário raiz da AWS conta). Uma notificação é entregue por versão afetada do mecanismo Amazon DocumentDB. Você pode encontrá-los em **Alterações programadas** no AHD. Cada notificação lista o tempo de disponibilidade do patch, o cronograma de aplicação automática, os clusters afetados e as notas de lançamento.
As notificações são enviadas aproximadamente dois dias antes da abertura da janela de aplicação automática. Por exemplo, um patch obrigatório lançado na segunda-feira às 00:00 UTC se torna elegível para aplicação automática na quarta-feira às 00:00 UTC. Se a janela de manutenção do seu cluster for quarta-feira às 12:00 UTC, o patch será aplicado automaticamente nessa quarta-feira, cerca de 12 horas após a abertura da janela de aplicação automática. Se sua janela de manutenção for terça-feira às 12:00 UTC, o patch aguardará uma semana inteira antes de ser aplicado automaticamente.
Você tem duas opções após receber a notificação: aplicar automaticamente o patch antes da data de aplicação automática ou esperar que ele se aplique automaticamente durante uma próxima janela de manutenção (o padrão). Para se autoaplicar, abra a guia **Manutenção e backups** do cluster e procure a entrada do tipo`system-update`.
**nota**
O **status** da notificação no AHD permanece **contínuo** até que o Amazon DocumentDB lance outro patch de mecanismo com uma nova versão de patch.
Depois que o patch é aplicado, a versão do patch do mecanismo do cluster é atualizada para corresponder à versão na notificação. Verifique a nova versão executando`db.runCommand({getEngineVersion: 1})`.
Patches opcionais e novas versões secundárias não geram notificações em AHD ou por e-mail. Para rastreá-los, assista às notas de [lançamento](https://docs.aws.amazon.com/documentdb/latest/devguide/release-notes.html) do Amazon DocumentDB.
Os patches forçados (a categoria mais rara, reservada para as correções de segurança mais críticas) também são anunciados por meio de AHD e e-mail. Diferentemente dos patches necessários, eles se aplicam fora da janela de manutenção, portanto, o exemplo de tempo de aplicação automática acima não se aplica.
### Reagindo às notificações de patch de forma programática
AWS Health se integra à Amazon EventBridge, que permite criar aplicativos orientados por eventos em mais de 20 destinos, incluindo AWS Lambda o Amazon Simple Queue Service (SQS). Para reagir programaticamente à disponibilidade do patch do motor, configure em relação ao evento. EventBridge `AWS_DOCDB_DB_PATCH_UPGRADE_MAINTENANCE_SCHEDULED` A partir daí, você pode capturar dados de eventos, gerar eventos adicionais, enviar notificações push por meio do AWS Console Mobile Application ou realizar qualquer outra ação necessária.
Se o Amazon DocumentDB cancelar um patch (raro), você receberá uma notificação de AHD e um e-mail sobre o cancelamento. Use o código do `AWS_DOCDB_DB_PATCH_UPGRADE_MAINTENANCE_CANCELLED` evento com EventBridge a Amazon para lidar com esse caso. Para saber mais sobre como escrever regras, consulte o [Guia EventBridge do usuário da Amazon](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-rules.html).
## Consultar ações de manutenção pendentes do Amazon DocumentDB
Use o Console de gerenciamento da AWS ou o AWS CLI para verificar qual manutenção está pendente para um cluster ou instância.
As atualizações pendentes aparecem com o tipo de ação`system-update`, que abrange tanto os patches do mecanismo quanto as atualizações do sistema operacional.
Quando uma atualização está pendente, você pode:
+ Aplique-o imediatamente.
+ Agende-o para a próxima janela de manutenção.
+ Adie-o (somente patches do mecanismo e atualizações do sistema operacional) alterando sua janela de manutenção antes`AutoAppliedAfterDate`. Depois que essa data passar, a ação será aplicada automaticamente durante a próxima janela de manutenção. Uma vez `ForcedApplyDate` aprovado, nenhum adiamento adicional é possível.
**nota**
Se você não tomar nenhuma ação, as ações de manutenção necessárias, como os patches de motor necessários, serão aplicadas automaticamente durante uma próxima janela de manutenção. Patches opcionais e versões secundárias nunca se aplicam automaticamente.
A janela de manutenção controla quando as operações pendentes *começam*, não quanto tempo elas demoram para serem concluídas.
------
#### [ Using the Console de gerenciamento da AWS ]
1. Faça login no e abra Console de gerenciamento da AWS o console do Amazon DocumentDB em. [https://console.aws.amazon.com/docdb](https://console.aws.amazon.com/docdb)
1. No painel de navegação, escolha **Clusters**.
1. A coluna **Manutenção** do cluster mostra **Disponível**, **Obrigatório** ou **Próxima janela** quando uma atualização está pendente.
1. Abra o cluster e escolha **Manutenção e backups** para ver os itens de **manutenção pendente** e agir de acordo com eles.
------
#### [ Using the AWS CLI ]
Corra `describe-pending-maintenance-actions` para ver o que está pendente. O exemplo a seguir mostra uma conta sem ações pendentes.
```
aws docdb describe-pending-maintenance-actions
```
A saída dessa operação é semelhante ao seguinte (formato JSON).
```
{
"PendingMaintenanceActions": []
}
```
Uma conta com uma ação pendente retorna uma saída semelhante a esta:
```
{
"PendingMaintenanceActions": [
{
"ResourceIdentifier": "arn:aws:rds:us-east-1:123456789012:cluster:sample-cluster",
"PendingMaintenanceActionDetails": [
{
"Action": "system-update",
"Description": "db-version-upgrade",
"CurrentApplyDate": "2026-05-15T03:01:00Z",
"AutoAppliedAfterDate": "2026-05-15T03:01:00Z"
}
]
}
]
}
```
Você pode definir o escopo da listagem para clusters específicos com`--filters`, no formulário`Name={{filter-name}},Values={{resource-id}},...`. O filtro aceito `Name` é`db-cluster-id`, que usa uma lista de identificadores de cluster ou ARNs.
**Example**
Para Linux, macOS ou Unix:
```
aws docdb describe-pending-maintenance-actions \
--filters Name=db-cluster-id,Values={{sample-cluster1}},{{sample-cluster2}}
```
Para Windows:
```
aws docdb describe-pending-maintenance-actions ^
--filters Name=db-cluster-id,Values={{sample-cluster1}},{{sample-cluster2}}
```
------
### Aplicar datas
Cada ação de manutenção pendente tem até três datas de aplicação. Eles aparecem na AWS CLI saída `describe-pending-maintenance-actions` e indicam quando a ação será executada. Os campos são `null` para manutenção opcional.
+ **CurrentApplyDate**—quando a ação está programada para ser executada, agora ou na próxima janela de manutenção. Preenchido para ações obrigatórias e forçadas.
+ **AutoAppliedAfterDate**—a data após a qual a aplicação automática começa durante a janela de manutenção do cluster ou da instância. Preenchido para as ações necessárias.
+ **ForcedApplyDate**—o prazo difícil. Após essa data, a ação é executada automaticamente, independentemente da janela de manutenção. Preenchido para ações forçadas.
Para adiar uma ação pendente, mova sua janela de manutenção para um dia anterior `AutoAppliedAfterDate` posterior. Depois de `AutoAppliedAfterDate` aprovada, a ação será aplicada automaticamente durante a próxima janela de manutenção. Uma vez `ForcedApplyDate` aprovado, nenhum adiamento adicional é possível. A janela exata de adiamento varia de acordo com o patch; as datas são publicadas na notificação do AHD e na AWS CLI saída.
## Atualizações do mecanismo do Amazon DocumentDB
Depois de identificar um patch de mecanismo pendente, use um dos procedimentos a seguir para aplicá-lo ou agendá-lo. Você pode executar esses procedimentos a partir do Console de gerenciamento da AWS ou do AWS CLI.
------
#### [ Using the Console de gerenciamento da AWS ]
**Para gerenciar a atualização de um cluster**
1. Faça login no e abra Console de gerenciamento da AWS o console do Amazon DocumentDB em. [https://console.aws.amazon.com/docdb](https://console.aws.amazon.com/docdb)
1. No painel de navegação, escolha **Clusters**.
1. Selecione o cluster que você deseja atualizar.
1. No menu **Ações**, escolha uma das seguintes opções:
+ **Atualize agora** — execute imediatamente a manutenção pendente.
+ **Atualize na próxima janela** — execute-o durante a próxima janela de manutenção do cluster.
Você também pode usar **Aplicar agora** ou **Aplicar na próxima janela de manutenção** na seção **Manutenção pendente** da guia **Manutenção e backups** do cluster (consulte[Consultar ações de manutenção pendentes do Amazon DocumentDB](#view-pending-maintenance)).
**nota**
Se nada estiver pendente, todas essas opções estarão inativas.
------
#### [ Using the AWS CLI ]
Aplique uma atualização pendente com`apply-pending-maintenance-action`.
**Parâmetros**
+ **--resource-identifier**—O Amazon DocumentDB Amazon Resource Name (ARN) do recurso alvo da ação pendente.
+ **--apply-action**—a ação de manutenção pendente a ser aplicada. Valores válidos: `system-update`, `db-upgrade`.
+ **--opt-in-type**—o tipo de solicitação de aceitação ou a possibilidade de desfazer uma. Valores válidos:
+ `immediate`—inscreva-se agora. Não pode ser desfeito depois de enviado.
+ `next-maintenance`—aplique durante a próxima janela de manutenção do recurso.
+ `undo-opt-in`—cancelar um `next-maintenance` opt-in existente.
**Example**
Para Linux, macOS ou Unix:
```
aws docdb apply-pending-maintenance-action \
--resource-identifier arn:aws:rds:us-east-1:{{123456789012}}:db:{{sample-cluster-instance-1}} \
--apply-action system-update \
--opt-in-type immediate
```
Para Windows:
```
aws docdb apply-pending-maintenance-action ^
--resource-identifier arn:aws:rds:us-east-1:{{123456789012}}:db:{{sample-cluster-instance-1}} ^
--apply-action system-update ^
--opt-in-type immediate
```
------
### Leia a disponibilidade durante a aplicação de patches
Os mecanismos 5.0 e 8.0 do Amazon DocumentDB preservam a disponibilidade de leitura durante a aplicação de patches quando o cluster tem várias instâncias. O Amazon DocumentDB corrige as instâncias dos leitores de forma contínua, em três grupos, para que os leitores restantes continuem fornecendo tráfego. O gravador está brevemente indisponível enquanto corrige. Para obter zero tempo de inatividade de leitura, defina sua preferência de leitura para que as leituras possam voltar para o redator: `secondaryPreferred` ou `primaryPreferred` funcionem; `primary` ou, `secondary` sozinhas, possam incorrer em tempo de inatividade de leitura.
| Modo de preferência de leitura | Durante a atualização do gravador | Durante a atualização do leitor | Número mínimo de leitores necessário para zero tempo de inatividade de leitura |
| --- | --- | --- | --- |
| primary | Read/write tempo de inatividade | Sem impacto | N/A |
| primaryPreferred | Anote o tempo de inatividade | Sem impacto | 1 |
| secondary | Anote o tempo de inatividade | Tempo de inatividade de leitura (se houver apenas um leitor) | 2 |
| secondaryPreferred | Anote o tempo de inatividade | Sem impacto | 1 |
| nearest | Anote o tempo de inatividade | Sem impacto | 1 |
Enquanto os leitores estão corrigindo, a taxa de transferência geral de leitura do cluster cai temporariamente. Para manter a produtividade estável, provisione leitores adicionais antes da atualização e remova-os após a conclusão.
Nos mecanismos 3.6 e 4.0, esses recursos de disponibilidade de leitura não se aplicam: um patch do mecanismo causa maior tempo de inatividade que afeta tanto as leituras quanto as gravações. Para fazer o upgrade para uma versão principal que funcione, consulte[Atualização da versão principal implementada do Amazon DocumentDB no local](docdb-mvu.md).
### Duração do tempo de inatividade do patch
Engine-patch o tempo de inatividade varia. Os maiores fatores são a utilização da CPU e a pressão da memória na instância no momento do patch, portanto, o dimensionamento correto de suas instâncias é importante. Para minimizar o tempo de inatividade, execute a versão mais recente do mecanismo principal do Amazon DocumentDB e distribua as instâncias em várias zonas de disponibilidade.
### Atualizações e substituições de patches
O Amazon DocumentDB monitora os patches após o lançamento. No caso raro de um problema ser identificado, o Amazon DocumentDB pausa a implantação enquanto prepara uma versão atualizada. Quando isso acontece, os clusters que ainda não receberam o patch não o veem mais como uma ação de manutenção disponível, e a notificação de alteração programada correspondente no Health Dashboard é retirada. Os clusters que já executam a versão afetada continuam operando normalmente e não exigem nenhuma ação de sua parte.
Um patch atualizado será lançado em breve. Quando estiver disponível em sua região, você receberá uma nova notificação por e-mail, conforme descrito em[Notificações para patches do mecanismo do Amazon DocumentDB](#patch-notifications). Health Dashboard
## Atualizações de versões secundárias
O Amazon DocumentDB publica versões secundárias além da versão principal 5.0 e posterior (por exemplo,). `5.0.1` Versões secundárias não são publicadas para versões principais anteriores à 5.0. As versões secundárias se comportam de maneira diferente dos patches de motor obrigatórios e opcionais:
+ Eles não aparecem como uma ação de manutenção pendente e nunca são aplicados automaticamente.
+ Eles não geram notificações AHD ou por e-mail. Novas versões secundárias são anunciadas nas notas de [lançamento](https://docs.aws.amazon.com/documentdb/latest/devguide/release-notes.html) do Amazon DocumentDB.
+ Para fazer o upgrade, você modifica a versão do mecanismo do cluster (imediatamente ou durante a próxima janela de manutenção). As atualizações de versões secundárias exigem um breve tempo de inatividade e são unidirecionais — você não pode fazer o downgrade para uma versão secundária anterior. Para clusters globais, atualize os clusters secundários antes do primário.
Leia mais:[Atualização da versão secundária do Amazon DocumentDB](docdb-minor-version-upgrade.md).
## Atualizações do sistema operacional do Amazon DocumentDB
Às vezes, as instâncias precisam de atualizações do sistema operacional. O Amazon DocumentDB atualiza o sistema operacional para melhorar o desempenho e aumentar a segurança. As atualizações do sistema operacional deixam a versão do mecanismo de cluster e a classe da instância inalteradas. Assim como os patches do mecanismo, as atualizações do sistema operacional usam o ciclo de vida opcional/obrigatório/forçado descrito na parte superior deste tópico; diferentemente dos patches do mecanismo, uma atualização do sistema operacional pode passar por essas categorias ao longo do tempo se você adiá-la. Aplique as atualizações do sistema operacional assim que elas estiverem disponíveis e defina a janela de manutenção da instância para um horário adequado à sua empresa.
Para receber um evento quando uma nova atualização opcional chegar, inscreva-se `RDS-EVENT-0230` na categoria de eventos de patches de segurança. Para obter detalhes, consulte [Assinatura de assinaturas de eventos do Amazon DocumentDB](https://docs.aws.amazon.com/documentdb/latest/devguide/event-subscriptions.subscribe.html). Depois de receber uma notificação, você pode aplicar automaticamente o patch do sistema operacional a cada instância.
Ao corrigir um cluster, atualize primeiro as instâncias do leitor e, por último, o gravador. Evite aplicar patches aos leitores e ao gravador simultaneamente — um failover durante o patch pode prolongar o tempo de inatividade. A manutenção na instância primária aciona um failover, portanto, execute mais de uma instância por cluster para permanecer disponível. Para obter detalhes, consulte [Failover do Amazon DocumentDB](failover.md).
**Importante**
Sua instância do Amazon DocumentDB fica off-line para a atualização do sistema operacional. Multi-instance os clusters minimizam o impacto. Se você executar um cluster de instância única, poderá adicionar temporariamente um secundário para o upgrade e removê-lo posteriormente. O secundário incorre nas cobranças usuais enquanto existe.
**nota**
Manter-se atualizado sobre as atualizações opcionais e obrigatórias pode ser necessário para fins de conformidade. Aplique as atualizações disponíveis rotineiramente durante suas janelas de manutenção.
As atualizações do sistema operacional estão vinculadas a versões específicas do mecanismo e classes de instância, portanto, instâncias diferentes se tornam elegíveis em momentos diferentes. Quando uma instância está qualificada, a atualização aparece no console; você também pode vê-la por meio do AWS CLI `describe-pending-maintenance-actions` comando ou da `DescribePendingMaintenanceActions` API.
**nota**
Se seu cluster não estiver na versão de patch mais recente do mecanismo Amazon DocumentDB, uma atualização do sistema operacional pode não aparecer como disponível. Aplique primeiro o patch de motor mais recente e, em seguida, verifique novamente.
Use o Console de gerenciamento da AWS ou AWS CLI para verificar se há uma atualização disponível.
------
#### [ Using the Console de gerenciamento da AWS ]
Para verificar se há uma atualização do sistema operacional no console:
1. Faça login no e abra Console de gerenciamento da AWS o console do Amazon DocumentDB em. [https://console.aws.amazon.com/docdb](https://console.aws.amazon.com/docdb)
1. No painel de navegação, escolha **Clusters**. A lista mostra os clusters e as instâncias dentro deles, diferenciados pela coluna **Role**.
1. Selecione a linha cuja **função** é **Instância** (não a linha do cluster). As atualizações do sistema operacional se aplicam a instâncias, não a clusters.
1. Escolha **Manutenção**.
1. Consulte a atualização do sistema operacional em **Manutenção pendente**.
Na seção **Manutenção pendente**, selecione a atualização do sistema operacional e escolha **Aplicar agora** ou **Aplicar na próxima janela de manutenção**. Se o valor da manutenção estiver **na próxima janela**, você poderá adiar a atualização com **Defer upgrade**, desde que ela ainda não tenha sido iniciada.
Você também pode fazer isso na lista de **clusters: no painel de navegação, escolha Clusters**, selecione a linha cuja **função** é **Instância** e escolha **Aplicar agora ou Aplicar** **na próxima janela de manutenção** no menu **Ações**.
------
#### [ Using the AWS CLI ]
A partir do AWS CLI, execute`describe-pending-maintenance-actions`:
```
aws docdb describe-pending-maintenance-actions
```
```
{
"PendingMaintenanceActions": [
{
"ResourceIdentifier": "arn:aws:rds:us-east-1:123456789012:db:sample-cluster-instance-1",
"PendingMaintenanceActionDetails": [
{
"Action": "system-update",
"Description": "New Operating System update is available"
}
]
}
]
}
```
------
## User-initiated atualizações
Algumas mudanças são iniciadas por você mesmo, por exemplo, trocando uma classe de instância por outra com mais ou menos memória ou alterando o grupo de parâmetros do cluster. O Amazon DocumentDB trata essas atualizações de forma diferente das atualizações que ele inicia. Para obter detalhes, consulte:
+ [Modificar um cluster do Amazon DocumentDB](db-cluster-modify.md)
+ [Modificar uma instância do Amazon DocumentDB](db-instance-modify.md)
Para listar as alterações iniciadas pelo usuário que ainda estão pendentes:
**Example**
**Para listar alterações pendentes iniciadas pelo usuário em suas instâncias**
Para Linux, macOS ou Unix:
```
aws docdb describe-db-instances \
--query 'DBInstances[*].[DBClusterIdentifier,DBInstanceIdentifier,PendingModifiedValues]'
```
Para Windows:
```
aws docdb describe-db-instances ^
--query 'DBInstances[*].[DBClusterIdentifier,DBInstanceIdentifier,PendingModifiedValues]'
```
A saída dessa operação é semelhante ao seguinte (formato JSON).
Neste exemplo, `sample-cluster-instance` tem uma alteração pendente para`db.r5.xlarge`; não `sample-cluster-instance-2` tem nenhuma.
```
[
[
"sample-cluster",
"sample-cluster-instance",
{
"DBInstanceClass": "db.r5.xlarge"
}
],
[
"sample-cluster",
"sample-cluster-instance-2",
{}
]
]
```
## Correção de clusters globais
Em um cluster global, cada cluster membro — primário e secundário — é atualizado durante sua própria janela de manutenção. Quando um patch de motor necessário está disponível em todas as regiões, você recebe uma notificação por AHD e por e-mail. Patches opcionais e novas versões secundárias não geram notificações; confira as [notas de lançamento do Amazon DocumentDB para saber](https://docs.aws.amazon.com/documentdb/latest/devguide/release-notes.html) mais.
Se você se inscrever automaticamente, sempre corrija os secundários primeiro e os primários por último. Esse pedido mantém o failover e o switchover disponíveis durante todo o lançamento.
**Importante**
Se você corrigir o primário primeiro por engano, coloque todos os secundários na mesma versão o mais rápido possível. O failover e o switchover permanecem desativados até que todos os clusters estejam na mesma versão.
Se você não realizar nenhuma ação, o patch será aplicado automaticamente durante a próxima janela de manutenção de cada cluster: primeiro os secundários, depois o primário em sua janela quando os secundários forem concluídos.
Mantenha os clusters de banco de dados primário e secundário na mesma versão. O failover gerenciado entre regiões só funciona em um banco de dados global quando cada cluster compartilha a mesma versão do mecanismo e nível de patch. O mesmo se aplica se você adicionar um novo secundário que usa uma versão de mecanismo mais recente que a principal — crie novos secundários na versão primária antes de juntá-los ao banco de dados global.
Após uma notificação de patch, atualize a primária e a secundária para a versão mais recente na primeira oportunidade de manter o failover e o switchover funcionando. Se uma solicitação de failover ou alternância for rejeitada, compare as versões de patch do mecanismo em todos os clusters; se elas não corresponderem, aplique o patch disponível nos clusters atrasados.