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

Gerenciamento das atualizações de serviços

As atualizações de serviços do MemoryDB são liberadas regularmente. Se você tiver um ou mais clusters qualificados para essas atualizações de serviço, receberá notificações por e-mail, SNS, Personal Health Dashboard (PHD) e CloudWatch eventos da Amazon quando as atualizações forem lançadas. As atualizações também são exibidas na página Atualizações de serviços no console do Atualizações de serviços. Usando este painel, é possível visualizar todas as atualizações de serviço e os status em relação à sua frota do MemoryDB.

Você controla quando aplicar uma atualização antes do início da atualização automática. É altamente recomendável que você aplique qualquer atualização do tipo atualização de segurança o mais rápido possível para garantir que seu MemoryDB esteja sempre com os patches de segurança atuais. up-to-date

As seguintes seções analisam essas opções em detalhes.

Visão geral das atualizações gerenciadas de manutenção e serviços do Amazon MemoryDB

Frequentemente atualizamos nossa frota de MemoryDB, com patches e atualizações sendo aplicados às instâncias sem problemas. Fazemos isso de uma das duas maneiras:

Essas atualizações de manutenção e serviço são necessárias para aplicar atualizações que fortaleçam a segurança, a confiabilidade e o desempenho operacional.

A manutenção gerenciada contínua acontece de tempos em tempos e diretamente em suas janelas de manutenção, sem exigir nenhuma ação de sua parte. É importante observar que as janelas de manutenção são obrigatórias para todos os clientes e você não tem a opção de optar por não participar. É altamente recomendável evitar atividades críticas ou importantes durante essas janelas de manutenção estabelecidas. Além disso, esteja ciente de que atualizações críticas não podem ser ignoradas para garantir a segurança e o desempenho ideal do sistema.

As atualizações de serviço oferecem flexibilidade para aplicá-las por conta própria. Eles são cronometrados e podem ser movidos para a janela de manutenção para serem aplicados por nós após o término da data de vencimento.

Você pode gerenciar as atualizações aplicando-as o mais rápido possível ou substituindo os nós, pois as atualizações são aplicadas automaticamente na substituição. Não haverá atividade de atualização durante as janelas de manutenção recebidas se as atualizações tiverem sido aplicadas a todos os nós anteriores.

Atualizações de serviço

Atualizações de serviço no MemoryDBpermitem que você aplique determinadas atualizações de serviço a seu critério. Essas atualizações podem ser dos seguintes tipos: patches de segurança ou pequenas atualizações de software. Essas atualizações ajudam a fortalecer a segurança, a confiabilidade e o desempenho operacional de seus clusters.

O valor dessas atualizações de serviço é que você pode controlar quando aplicar a atualização (por exemplo, você pode adiar a aplicação de atualizações de serviço quando houver um evento comercial importante que exija disponibilidade 24 horas por dia, 7 dias por semana dos clusters do MemoryDB).

Se você tiver um ou mais clusters qualificados para essas atualizações de serviço, receberá notificações por e-mail, Amazon SNS, Dashboard e eventos AWS Health da CloudWatch Amazon quando as atualizações forem lançadas. As atualizações também são exibidas na página Atualizações de serviços no console do Atualizações de serviços. Usando este painel, é possível visualizar todas as atualizações de serviço e os status em relação à sua frota do MemoryDB.

Você controla quando aplicar uma atualização antes do início da atualização automática. É altamente recomendável que você aplique qualquer atualização do tipo atualização de segurança o mais rápido possível para garantir que seu MemoryDB esteja sempre com os patches de segurança atuais. up-to-date

Seu cluster pode fazer parte de diferentes atualizações de serviço. A maioria das atualizações não exige que você as aplique separadamente. A aplicação de uma atualização ao seu cluster marcará as outras atualizações como concluídas, sempre que aplicável. Talvez seja necessário aplicar várias atualizações ao mesmo cluster separadamente se o status não mudar para “concluído” automaticamente.

Impacto e tempo de inatividade das atualizações de serviços

Quando você ou o Amazon MemoryDB aplicam uma atualização de serviço a um ou mais clusters do MemoryDB, a atualização é aplicada a no máximo um nó por vez em cada fragmento até que todos os clusters selecionados sejam atualizados. Os nós que estão sendo atualizados sofrerão um tempo de inatividade de alguns segundos, enquanto o restante do cluster continuará fornecendo tráfego.

Como a substituição de um nó afeta meu aplicativo? - Para nós MemoryDB, o processo de substituição foi projetado para garantir durabilidade e disponibilidade. Para clusters MemoryDB de nó único, o MemoryDB gira dinamicamente uma réplica, restaura os dados de nossos componentes de durabilidade e, em seguida, efetua o failover para eles. Para grupos de replicação que consistem em vários nós, o MemoryDB substitui as réplicas existentes e sincroniza os dados de nossos componentes de durabilidade com as novas réplicas. O MemoryDB só é Multi-AZ quando há mais de 1 nó, portanto, nesse cenário, a substituição do primário aciona um failover em uma réplica de leitura. As substituições planejadas dos nós são concluídas enquanto o cluster atende às solicitações de gravação recebidas. Se houver apenas um nó, o MemoryDB substituirá o primário e depois sincronizará os dados de nossos componentes de durabilidade. O nó primário não está disponível durante esse período, levando a uma interrupção mais longa da gravação.

Quais práticas recomendadas devo seguir para uma experiência de substituição tranquila e minimizar a perda de dados? - No MemoryDB, os dados são altamente duráveis e a perda de dados não é esperada, mesmo em implementações de um único nó. No entanto, é recomendável implementar estratégias Multi-AZ e de backup para minimizar as chances de perda no caso improvável de falha. Para uma experiência de substituição tranquila, tentamos substituir apenas nós suficientes do mesmo cluster por vez para manter o cluster estável. Você pode provisionar réplicas primárias e de leitura em diferentes zonas de disponibilidade ativando o Multi-AZ. Nesse caso, quando um nó for substituído, a função principal será transferida para uma réplica no fragmento. Esse fragmento agora atenderá ao tráfego e os dados serão restaurados a partir de seus componentes de durabilidade. Se sua configuração incluir somente uma réplica primária e uma única por fragmento, recomendamos adicionar outras réplicas antes da aplicação de patches. Isso evitará a redução da disponibilidade durante o processo de aplicação de patches. Recomendamos agendar a substituição durante um período com baixo tráfego de gravação de entrada.

Quais práticas recomendadas de configuração do cliente devo seguir para minimizar a interrupção do aplicativo durante a manutenção? - No MemoryDB, a configuração do modo de cluster está sempre ativada, o que fornece a melhor disponibilidade durante operações gerenciadas ou não gerenciadas. Os endpoints individuais dos nós de réplica podem ser usados para todas as operações de leitura. No MemoryDB, o failover automático está sempre ativado no cluster, o que significa que o nó primário pode mudar. Portanto, o aplicativo deve confirmar a função do nó e atualizar todos os endpoints de leitura para garantir que você não esteja causando uma grande carga no primário. Da mesma forma, evite sobrecarregar as réplicas com solicitações de leitura durante as janelas de manutenção. Uma maneira de conseguir isso é garantir que você tenha pelo menos duas réplicas de leitura para evitar qualquer interrupção de leitura durante a manutenção.

É importante testar os aplicativos cliente para confirmar se eles estão em conformidade com o protocolo Redis/Valkey Cluster e se as solicitações podem ser redirecionadas entre os nós adequadamente. É aconselhável implementar estratégias de recuo e repetição para evitar sobrecarregar os nós do MemoryDB durante as atividades de manutenção e substituição.

Reagendamento - Você pode adiar a atualização do serviço alterando a janela de manutenção. A atualização programada só será aplicada ao cluster se a data programada corresponder à janela de manutenção do cluster. Depois que você alterar a janela de manutenção e a data programada tiver passado, a atualização do serviço será reprogramada para a janela recém-especificada nas semanas seguintes. Você receberá uma nova notificação uma semana antes da nova data ser atingida.

A segurança em AWS é uma responsabilidade compartilhada. É altamente recomendável que você aplique a atualização o mais rápido possível.

Optar por não receber atualizações de serviço - Você pode determinar se pode optar por não receber uma atualização de serviço verificando o valor do atributo “Data de início da atualização automática”. Se o valor do atributo “Data de início da atualização automática” de uma atualização de serviço for definido, o MemoryDB agendará a atualização do serviço para todos os clusters restantes para a próxima janela de manutenção, e não será possível optar por não participar. Ainda assim, se você aplicar a atualização do serviço aos clusters restantes antes da janela de manutenção, o MemoryDB não reaplicará a atualização do serviço durante a janela de manutenção. Para obter mais informações, consulte Como aplicar as atualizações de serviço.

Por que as atualizações do serviço não podem ser aplicadas diretamente pelo MemoryDB durante as janelas de manutenção? - Observe que o objetivo das atualizações de serviço é oferecer flexibilidade sobre quando aplicá-las. Os clusters que não participam dos programas de conformidade suportados pelo MemoryDB podem optar por não aplicar essas atualizações ou aplicá-las com uma frequência reduzida ao longo do ano. No entanto, é recomendável aplicar as atualizações para manter a conformidade com os regulamentos. Isso é verdade somente quando o valor do atributo “Data de início da atualização automática” de uma atualização de serviço não está presente. Para obter mais informações, consulte Validação de conformidade para MemoryDB.

Como as atualizações aplicadas na janela de manutenção são diferentes das atualizações de serviço? - As atualizações aplicadas por meio da manutenção gerenciada contínua são programadas diretamente em suas janelas de manutenção, sem a necessidade de nenhuma ação de sua parte. As atualizações do serviço são cronometradas e permitem que você controle quando deseja se inscrever até a “Data de início da atualização automática”. Se elas ainda não forem aplicadas até lá, o MemoryDB poderá agendar essas atualizações em sua janela de manutenção.

Atualizações contínuas de manutenção gerenciada

Essas atualizações são obrigatórias e aplicadas diretamente em suas janelas de manutenção, sem a necessidade de nenhuma ação de sua parte. Essas atualizações são separadas das oferecidas pelas atualizações de serviço.

Impacto da manutenção contínua e tempo de inatividade

Quanto tempo demora a substituição de um nó? - A substituição normalmente é concluída em 30 minutos. A substituição pode levar mais tempo em determinadas configurações de instância e padrões de tráfego.

Como a substituição de um nó afeta meu aplicativo? - As atualizações contínuas de manutenção gerenciada são aplicadas da mesma forma que as “atualizações de serviço”, por meio da substituição de nós. Consulte a seção Impacto e tempo de inatividade das atualizações do serviço acima para obter detalhes.

Como faço para gerenciar as substituições de nós sozinho? - Você mesmo tem a opção de gerenciar essas substituições a qualquer momento antes da janela de substituição programada do nó. Se você optar por gerenciar a substituição sozinho, poderá realizar várias ações, dependendo do seu caso de uso.

Como faço para saber mais sobre as próximas substituições programadas? - Você deve receber uma notificação de saúde no painel AWS de saúde. Além disso, você pode encontrar o status de diferentes atualizações de serviços com a DescribeServiceUpdates API. Observe que nos esforçamos para notificar proativamente os clientes sobre substituições previsíveis. No entanto, em casos excepcionais, como falhas imprevisíveis, pode haver substituições sem aviso prévio.

Posso alterar a manutenção programada em um horário mais adequado? - Sim, você pode adiar a manutenção programada para um horário mais adequado alterando a janela de manutenção.

Por que você está fazendo essas substituições de nós? - Essas substituições são necessárias para aplicar as atualizações obrigatórias de software ao seu host subjacente. As atualizações ajudam a fortalecer nossa segurança, confiabilidade e desempenho operacional.

Essas substituições afetam meus nós em várias zonas de disponibilidade e clusters de diferentes regiões ao mesmo tempo? - As substituições podem ser executadas em várias zonas de disponibilidade ou regiões em paralelo, dependendo da janela de manutenção dos clusters.