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 executa 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 de mecanismo e as atualizações do sistema operacional usam as mesmas três categorias de ciclo de vida — * opcional **, * obrigatório e * forçado * — com a mesma notificação e comportamento de aplicação para cada categoria. As versões do motor 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; inscreva-se 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 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`AutoAppliedAfterDate`. Você pode adiar alterando a janela de manutenção antes dessa data.
+ **Forçado ** — uma correçã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 do mecanismo) — uma versão numerada do mecanismo sobre 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. As versões secundárias não são publicadas para as versões principais anteriores à 5.0.
Os patches do motor são lançados em uma única categoria (opcional, obrigatória ou forçada) e permanecem lá. Progresso das atualizações do sistema operacional: a maioria começa como opcional e, se não for aplicada, passa para necessária e, eventualmente, forçada. O tempo exato depende do patch e é publicado nos campos de notificação e data do AHD retornados por `describe-pending-maintenance-actions` (consulte[Aplicar datas](#db-instance-updates-apply-date)). As notas de [ lançamento do Amazon DocumentDB ](https://docs.aws.amazon.com/documentdb/latest/devguide/release-notes.html) usam esses nomes de categorias ao anunciar mudanças no mecanismo.
A aplicação de qualquer patch de mecanismo deixa o cluster off-line 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 funcionam as atualizações do sistema operacional e como lidar com clusters globais.
**Topics**
+ [Ações de manutenção para o Amazon DocumentDB](#maintenance-actions)
+ [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)
+ [Aplicação de patches em clusters globais](#global-clusters-patching)
## Ações de manutenção para o Amazon DocumentDB
As seguintes ações de manutenção se aplicam aos clusters do Amazon DocumentDB:
+ `system-update`— Atualize o patch do mecanismo para o cluster Amazon DocumentDB. Para obter mais informações, consulte [Atualizações do mecanismo do Amazon DocumentDB](#db-instance-updates-apply).
+ `os-upgrade`— Atualize os sistemas operacionais de todas as instâncias de banco de dados no cluster Amazon DocumentDB usando atualizações contínuas. Para obter mais informações, consulte [Atualizações do sistema operacional do Amazon DocumentDB](#os-system-updates).
As seguintes ações de manutenção se aplicam às instâncias do Amazon DocumentDB:
+ `system-update`— Atualize o sistema operacional da instância Amazon DocumentDB. Em vez disso, recomendamos que você use a ação de `os-upgrade` manutenção em nível de cluster. Para obter mais informações, consulte [Atualizações do sistema operacional do Amazon DocumentDB](#os-system-updates).
## 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 formato `{{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 com o MongoDB; a terceira parte é a versão secundária, incrementada quando o Amazon DocumentDB publica uma versão secundária contendo correções de erros 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 formato `{{major}}.0.{{patch}}` (por exemplo,`3.0.17983`) que identifica o nível de patch aplicado ao seu cluster. O dígito do meio é 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 de versões lançadas de patches de motor 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 tempo.
Se você não escolher uma janela ao criar o recurso, o Amazon DocumentDB atribui uma aleatoriamente em 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 é disponibilizado 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 do usuário raiz da AWS conta). Uma notificação é entregue por versão afetada do mecanismo Amazon DocumentDB. Você pode encontrá-los em Mudanças ** 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.
Os patches de motor necessários seguem um único prazo de entrega de aproximadamente 30 dias. Quando um patch é disponibilizado em sua região, o Amazon DocumentDB envia a notificação descrita acima. Nesse ponto, o patch `AutoAppliedAfterDate` está configurado para aproximadamente 30 dias depois. Até essa data, o patch permanece pendente: você pode aplicá-lo a qualquer momento ou adiá-lo movendo a janela de manutenção do cluster para um dia posterior. Em ou após o`AutoAppliedAfterDate`, o patch se aplica automaticamente durante a próxima janela de manutenção do cluster.
Por exemplo, um patch obrigatório que se torna disponível em 1º de junho de 2026 tem um `AutoAppliedAfterDate` de aproximadamente 1º de julho de 2026. Você recebe a notificação em 1º de junho de 2026 e, se não fizer nada, o patch será aplicado automaticamente durante a primeira janela de manutenção do cluster, em ou após 1º de julho de 2026.
Você tem duas opções depois de receber a notificação: aplicar o patch automaticamente antes da data de aplicação automática ou esperar que ele seja aplicado automaticamente durante uma próxima janela de manutenção (o padrão). Para se inscrever automaticamente, 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 ** em ** andamento ** 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 por e-mail ou AHD. Para rastreá-los, assista às notas [ de ](https://docs.aws.amazon.com/documentdb/latest/devguide/release-notes.html) lançamento do Amazon DocumentDB.
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 integra-se à 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 de acordo com o 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 do 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 imediatamente.
+ Agende-o para a próxima janela de manutenção.
+ Adie-o (somente patches de motor 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 fizer nada, 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 levam 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 a janela ** Disponível ****, ** ** Obrigatória ou Próxima ** 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 sobre 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 parecida com 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 de `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 rígido. 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 posterior. `AutoAppliedAfterDate` 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 motor pendente, use um dos procedimentos a seguir para aplicá-lo ou programá-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 a manutenção pendente imediatamente.
+ **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**—Amazon DocumentDB Amazon Resource Name (ARN) do recurso que a ação pendente visa.
+ **--apply-action**—a ação de manutenção pendente a ser aplicada. Use `system-update` para aplicar um patch de motor.
+ **--opt-in-type**—o tipo de solicitação de aceitação ou se deseja 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 instâncias de leitores de forma contínua, em três grupos, para que os leitores restantes continuem fornecendo tráfego. O escritor está brevemente indisponível enquanto faz o patch. Para atingir zero tempo de inatividade de leitura, defina sua preferência de leitura para que as leituras possam voltar para o redator: `secondaryPreferred` ou `primaryPreferred` trabalhar; `primary` ou `secondary` sozinhas, podem causar inatividade de leitura.
| Modo de preferência de leitura | Durante a atualização do escritor | Durante a atualização do leitor | Número mínimo de leitores necessários 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 for 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 diminui temporariamente. Para manter a taxa de transferência estável, provisione leitores adicionais antes da atualização e remova-os após sua 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 atualizar 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 de memória na instância no momento do patch, portanto, dimensionar corretamente 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 o lançamento 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 ele 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`). As versões secundárias não são publicadas para as 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 por AHD ou por e-mail. Novas versões secundárias são anunciadas nas notas [ de ](https://docs.aws.amazon.com/documentdb/latest/devguide/release-notes.html) lançamento do Amazon DocumentDB.
+ Para atualizar, você modifica a versão do mecanismo do cluster (imediatamente ou durante a próxima janela de manutenção). Os upgrades 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 dos primários.
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 reforçar 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/exigido/forçado descrito no início 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 as janelas de manutenção de clusters e instâncias para horários que atendam às suas necessidades comerciais.
Use a ação de `os-upgrade` manutenção em nível de cluster para aplicar atualizações do sistema operacional em todas as instâncias em um cluster. O Amazon DocumentDB atualiza as instâncias de forma contínua, algumas de cada vez, e atualiza a instância primária por último para minimizar os failovers. A atualização é executada durante a janela de manutenção do cluster, não a janela de manutenção de instâncias individuais, que você configura.
Depois que uma instância recebe uma atualização do sistema operacional, seu cache de buffer começa vazio. Até que o conjunto de trabalho seja repreenchido a partir do volume de armazenamento, as consultas nessa instância podem ter uma latência maior e menor. `BufferCacheHitRatio`
Quando o Amazon DocumentDB atualiza a instância primária, um failover promove uma réplica como a nova primária. Use o endpoint do cluster para que seu aplicativo processe isso de forma transparente. Para manter a disponibilidade de leitura enquanto as instâncias estão sendo atualizadas, defina sua preferência `secondaryPreferred` de leitura para que as leituras `primaryPreferred` possam voltar para uma instância disponível. Mantenha os possíveis alvos de failover (réplicas com o nível de maior prioridade) na mesma classe de instância da primária. Isso evita a degradação do desempenho de gravação após a promoção. Para obter detalhes, consulte [Failover do Amazon DocumentDB](failover.md).
As ações em nível de cluster `os-upgrade` e de instância podem aparecer simultaneamente como `system-update` ações disponíveis. `describe-pending-maintenance-actions` No entanto, você não pode agendar os dois ao mesmo tempo. Se `system-update` as ações no nível da instância estiverem ativamente agendadas em qualquer instância, você deverá cancelá-las ou concluí-las antes de programar a ação no nível do cluster `os-upgrade` e vice-versa.
**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 a atualização e removê-lo posteriormente. O secundário incorre nas cobranças usuais enquanto existe.
**nota**
A `system-update` ação no nível da instância ainda está disponível para compatibilidade com versões anteriores. Se você precisar usá-lo, atualize as réplicas primeiro e a principal por último — evite corrigi-las simultaneamente, pois um failover durante o patch pode prolongar o tempo de inatividade.
Para receber um evento quando uma nova atualização opcional do sistema operacional chegar, inscreva-se `RDS-EVENT-0230` na categoria de eventos de patches de segurança. Para obter mais informações, consulte [Tornar-se assinante de eventos do Amazon DocumentDB](event-subscriptions.subscribe.md).
**nota**
Manter-se atualizado sobre as atualizações opcionais e obrigatórias pode ser necessário para fins de conformidade. Aplique `os-upgrade` ações rotineiramente durante suas janelas de manutenção.
As atualizações do sistema operacional estão vinculadas a classes de instâncias específicas, portanto, instâncias diferentes se tornam elegíveis em momentos diferentes. Se seu cluster não estiver no patch de mecanismo mais recente, a atualização do sistema operacional pode não aparecer — aplique primeiro o patch de mecanismo mais recente (consulte[Atualizações do mecanismo do Amazon DocumentDB](#db-instance-updates-apply)).
Use o Console de gerenciamento da AWS ou AWS CLI para verificar se uma atualização está 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 ** e selecione o nome do cluster.
1. Escolha a ** guia ** Manutenção e backups.
1. Em Manutenção ** pendente**, a `os-upgrade` ação aparece se uma atualização do sistema operacional estiver disponível.
1. Selecione a `os-upgrade` ação e escolha ** Aplicar agora ** ou ** Aplicar na próxima janela de manutenção**. Se o valor for a ** próxima janela**, você poderá adiar com ** Adiar a atualização, ** desde que a ação não tenha sido iniciada.
------
#### [ Using the AWS CLI ]
Verifique se há uma atualização pendente do sistema operacional:
```
aws docdb describe-pending-maintenance-actions
```
```
{
"PendingMaintenanceActions": [
{
"ResourceIdentifier": "arn:aws:rds:aa-example-1:111122223333:cluster:sample-cluster",
"PendingMaintenanceActionDetails": [
{
"Action": "os-upgrade",
"Description": "New Operating System update is available"
}
]
},
{
"ResourceIdentifier": "arn:aws:rds:aa-example-1:111122223333:db:sample-cluster-instance-1",
"PendingMaintenanceActionDetails": [
{
"Action": "system-update",
"Description": "New Operating System update is available"
}
]
},
{
"ResourceIdentifier": "arn:aws:rds:aa-example-1:111122223333:db:sample-cluster-instance-2",
"PendingMaintenanceActionDetails": [
{
"Action": "system-update",
"Description": "New Operating System update is available"
}
]
}
]
}
```
As atualizações do sistema operacional aparecem no nível do cluster como `os-upgrade` e no nível da instância como`system-update`. Use a ação em nível de cluster`os-upgrade`.
**Example**
O exemplo a seguir aplica a atualização do sistema operacional imediatamente.
Para Linux, macOS ou Unix:
```
aws docdb apply-pending-maintenance-action \
--resource-identifier arn:aws:rds:{{aa-example-1}}:{{111122223333}}:cluster:{{sample-cluster}} \
--apply-action os-upgrade \
--opt-in-type immediate
```
Para Windows:
```
aws docdb apply-pending-maintenance-action ^
--resource-identifier arn:aws:rds:{{aa-example-1}}:{{111122223333}}:cluster:{{sample-cluster}} ^
--apply-action os-upgrade ^
--opt-in-type immediate
```
------
## User-initiated atualizações
Algumas mudanças são iniciadas por você mesmo, por exemplo, trocando uma classe de instância por uma 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 as 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 em`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",
{}
]
]
```
## Aplicação de patches em 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; verifique as notas de [ lançamento do Amazon DocumentDB ](https://docs.aws.amazon.com/documentdb/latest/devguide/release-notes.html) para ver essas notificações.
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 cada cluster esteja na mesma versão.
Se você não fizer nada, o patch se aplicará automaticamente durante a próxima janela de manutenção de cada cluster: primeiro as secundárias, depois as primárias em sua janela quando as secundárias estiverem concluídas.
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 de 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 nova do que a primária — crie novos secundários na versão primária antes de juntá-los ao banco de dados global.
Depois de 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 switchover for rejeitada, compare as versões do patch do mecanismo entre os clusters; se elas não corresponderem, aplique o patch disponível nos clusters atrasados.