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-0230para 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 (consulteAplicar datas). As notas de versão 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.
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.minor5.0.0ou5.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.patch3.0.17983) que identifica o nível do patch aplicado ao seu cluster. O dígito médio é sempre0. 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. |
3.6 |
2.0. |
4,0 |
3.0. |
5,0 |
4.0. |
8.0 |
Para verificar a versão do patch que seu cluster está executando, conecte-se e executedb.runCommand({getEngineVersion: 1}).
Para ver a lista das versões de patch de mecanismo lançadas 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.
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.
-
Para uma instância: consulte Modificar uma instância do Amazon DocumentDB.
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 tiposystem-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 executandodb.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 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.
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:
-
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 vezForcedApplyDateaprovado, 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.
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.
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, 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 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 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 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 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.
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. 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.
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.
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:
Para listar as alterações iniciadas pelo usuário que ainda estão pendentes:
exemplo
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 paradb.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 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.
