Manutenção do Amazon DocumentDB

O Amazon DocumentDB executa periodicamente dois tipos de manutenção:

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:

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 (consulteAplicar datas). As notas de lançamento do Amazon DocumentDB 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.

Ações de manutenção para o Amazon DocumentDB

As seguintes ações de manutenção se aplicam aos clusters do Amazon DocumentDB:

As seguintes ações de manutenção se aplicam às instâncias do Amazon DocumentDB:

Numeração da versão do motor

O Amazon DocumentDB usa dois identificadores de versão separados:

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.

Para verificar a versão do patch que seu cluster está executando, conecte-se e executedb.runCommand({getEngineVersion: 1}).

Para ver a lista de versões lançadas de patches de motor e o que cada uma contém, consulteNotas da versão.

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.

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.

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 oAutoAppliedAfterDate, 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 tiposystem-update.

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 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.

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çãosystem-update, que abrange tanto os patches do mecanismo quanto as atualizações do sistema operacional.

Quando uma atualização está pendente, você pode:

A janela de manutenção controla quando as operações pendentes começam, não quanto tempo elas levam para serem concluídas.

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.

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.

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.

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, consulteAtualização da versão principal implementada do Amazon DocumentDB no local.

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 emNotificações para patches do mecanismo do Amazon DocumentDB. 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:

Leia mais:Atualização da versão secundária do Amazon DocumentDB.

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.

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.

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.

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 (consulteAtualizações do mecanismo do Amazon DocumentDB).

Use o Console de gerenciamento da AWS ou AWS CLI para verificar se uma atualização está disponível.

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:

Para listar as alterações iniciadas pelo usuário que ainda estão pendentes:

aws docdb describe-db-instances \
    --query 'DBInstances[*].[DBClusterIdentifier,DBInstanceIdentifier,PendingModifiedValues]'

aws docdb describe-db-instances ^
    --query 'DBInstances[*].[DBClusterIdentifier,DBInstanceIdentifier,PendingModifiedValues]'

[
    [
        "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 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.

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.