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á.
# Atualizações de serviço no MemoryDB
O MemoryDB monitora automaticamente sua frota de clusters e nós para aplicar atualizações de serviço à medida que elas são disponibilizadas. Normalmente, você configura uma janela de manutenção predefinida para que o MemoryDB possa aplicar essas atualizações. No entanto, em alguns casos, você pode achar que essa abordagem é muito rígida e que provavelmente restringirá os fluxos de negócios.
Com [Atualizações de serviço no MemoryDB](#service-updates), é possível controlar quando e quais atualizações são aplicadas. Também é possível monitorar o andamento dessas atualizações dos clusters do MemoryDB selecionados em tempo real.
# 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.
**Topics**
+ [Visão geral da manutenção gerenciada e das atualizações de serviço do Amazon MemoryDB](#managing-updates-maintenance)
## Visão geral da manutenção gerenciada e das atualizações de serviço do Amazon MemoryDB
Atualizamos frequentemente nossa frota do MemoryDB, com patches e upgrades aplicados a instâncias de forma contínua. Fazemos isso de duas formas:
1. Manutenção gerenciada contínua.
1. Atualizações de serviço.
Essas atualizações de serviço e manutenções são necessárias para aplicar upgrades que fortalecem a segurança, a confiabilidade e o desempenho operacional.
A manutenção gerenciada contínua acontece de tempos em tempos e diretamente nas 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 não há opção de não aderir a esse serviço. É 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 que você as aplique por conta própria. Elas têm um horário programado e podem ser movidas para a janela de manutenção para serem aplicadas por nós após o vencimento da data prevista.
Você pode gerenciar as atualizações aplicando-as o mais rápido possível ou substituindo os nós, já que as atualizações são aplicadas automaticamente durante a substituição. Não haverá atividade de atualização durante as janelas de manutenção futuras se as atualizações já tiverem sido aplicadas a todos os nós anteriores.
### Atualizações de serviço
[Atualizações de serviço no MemoryDB](service-updates.md) permitem aplicar 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 dos seus clusters.
O valor dessas atualizações de serviço é que é possível controlar quando aplicar a atualização (por exemplo, você pode adiar a aplicação de atualizações de serviço quando há 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](mdbevents.sns.md), Dashboard e eventos [AWS Health da CloudWatch ](https://docs.aws.amazon.com/health/latest/ug/getting-started-health-dashboard.html) [Amazon](monitoring-cloudwatch.md) 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
O 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 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 caso o status não mude para “concluído” automaticamente.
#### Impacto e tempo de inatividade das atualizações de serviço
Quando você ou o Amazon MemoryDB aplica uma atualização de serviço a um ou mais clusters do MemoryDB, ela é 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 apresentarão um tempo de inatividade de alguns segundos, enquanto o restante do cluster continuará fornecendo tráfego.
+ Não haverá alteração na configuração do cluster.
+ Você verá um atraso em suas CloudWatch métricas que se recuperarão o mais rápido possível.
**Como a substituição de um nó afeta a aplicação?** – Para nós do MemoryDB, o processo de substituição foi projetado para garantir durabilidade e disponibilidade. Para clusters de nó único do MemoryDB, este cria dinamicamente uma réplica, restaura os dados de nossos componentes de durabilidade e, depois, faz failover para ela. 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 um nó, portanto, nesse cenário, a substituição do primário aciona um failover em uma réplica de leitura. As substituições planejadas de nós são concluídas enquanto o cluster continua atendendo às solicitações de escrita 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 fica 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 para 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. É possível provisionar réplicas primárias e de leitura em diferentes zonas de disponibilidade ativando a Multi-AZ. Nesse caso, quando um nó é substituído, o perfil principal fará failover 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 a 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 programar 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 da aplicação 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, a aplicação deve confirmar o perfil do nó e atualizar todos os endpoints de leitura para garantir que você não esteja causando uma carga excessiva no primário. Da mesma forma, evite sobrecarregar as réplicas com solicitações de leitura durante as janelas de manutenção. Uma forma de fazer 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](maintenance-window.md). 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.
A segurança em AWS é uma responsabilidade compartilhada. É altamente recomendável aplicar a atualização o quanto antes.
**Optar por não receber atualizações de serviço**: você 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 atualizar. Ainda assim, se você aplicar a atualização de 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](applying-updates.md).
**Por que as atualizações de 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](memorydb-compliance.md) compatíveis com o MemoryDB podem optar por não aplicar essas atualizações ou por 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 vale somente quando o atributo “Data de início da atualização automática” de uma atualização de serviço não está atribuído. Para obter mais informações, consulte [Validação de conformidade para MemoryDB](memorydb-compliance.md).
**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 de serviço são programadas e permitem que você controle quando deseja aplicá-las pela “Data de início da atualização automática”. Se ainda não forem aplicadas até essa data, o MemoryDB pode agendá-las na sua janela de manutenção.
### Atualizações da manutenção gerenciada contínua
Essas atualizações são obrigatórias e são aplicadas diretamente nas janelas de manutenção sem a necessidade de nenhuma ação de sua parte. Essas atualizações são distintas das oferecidas pelas atualizações de serviço.
#### Tempo de inatividade e impacto da manutenção contínua
**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 a aplicação?** – 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 mais detalhes na seção acima Tempo de inatividade e impacto das atualizações de serviço.
**Como gerenciar as substituições de nós por conta própria?** – Você tem a opção de gerenciar essas substituições a qualquer momento antes da janela agendada para a substituição do nó. Se optar por gerenciar a substituição por conta própria, você poderá realizar várias ações, dependendo do seu caso de uso.
+ [Substitua um nó no cluster por um ou mais fragmentos](nodes.nodereplacement.md): você pode usar [backup e restauração](snapshots-restoring.md) ou aumentar e, depois, reduzir a escala horizontalmente para [substituir os nós](cluster-resharding-online.md).
+ [Altere sua janela de manutenção](maintenance-window.md): além disso, você pode alterar a janela de manutenção do cluster. Para alterar sua janela de manutenção para um horário mais conveniente posteriormente, você pode usar a [UpdateCluster API](clusters.modify.md), a [CLI do cluster de atualização](https://docs.aws.amazon.com/cli/latest/reference/memorydb/update-cluster.html) ou clicar em [Modificar](clusters.modify.md) no console de gerenciamento do MemoryDB. Depois de alterar a janela de manutenção, o MemoryDB agendará a manutenção do nó durante a janela que você acabou de especificar.
Para ver isso na prática, digamos que seja quinta-feira, 9/11, às 15h e a próxima janela de manutenção seja sexta-feira, 10/11, às 17h. Aqui estão três cenários:
+ Você altera a janela de manutenção para sexta-feira, às 16h (após a data e hora atual e antes da próxima janela de manutenção programada). O nó será substituído na sexta-feira, 10 de novembro, 16h.
+ Você altera a janela de manutenção para sábado, 16h (após a data e hora atual e a próxima janela de manutenção programada). O nó será substituído no sábado, 11 de novembro, 16h.
+ Você altera a janela de manutenção para quarta-feira, 16h (dia da semana anterior à data e hora atual). O nó será substituído na próxima quarta-feira, 15 de novembro, 16h.
Para obter mais informações, consulte [Gerenciamento da manutenção](maintenance-window.md).
Observe que os nós em diferentes clusters de diferentes regiões podem ser substituídos ao mesmo tempo, desde que a janela de manutenção desses clusters seja a mesma.
**Como posso 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](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeServiceUpdates.html).
**Por que estão sendo feitas essas substituições de nós?** – Essas substituições são necessárias para aplicar as atualizações obrigatórias de software ao 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.
# Como aplicar as atualizações de serviço
Será possível começar a aplicar as atualizações de serviços à sua frota desde o momento em que as atualizações tiverem um status **disponível**. As atualizações de serviço são cumulativas. Em outras palavras, qualquer atualização que você ainda não tiver aplicado serão incluídas na sua atualização mais recente.
Se uma atualização de serviço tiver a atualização automática habilitada, será possível optar por não realizar nenhuma ação quando ela estiver disponível. O MemoryDB agendará a aplicação da atualização durante a janela de manutenção dos clusters após a **Data de início da atualização automática**. Você receberá notificações relacionadas a cada etapa da atualização.
**nota**
É possível aplicar somente as atualizações de serviço que tenham um status **disponível** ou **programado**.
Para obter mais informações sobre a análise e a aplicação de qualquer atualização específica ao serviço aos clusters do MemoryDB aplicáveis, consulte [Aplicação de atualizações de serviço usando o console](#applying-updates-console-APIReferenceconsole).
Quando uma nova atualização de serviço está disponível para um ou mais dos seus clusters do MemoryDB, você pode usar o console do MemoryDB, a API ou aplicar AWS CLI a atualização. As seções a seguir explicam as opções que você pode usar para aplicar as atualizações.
## Aplicação de atualizações de serviço usando o console
Para visualizar a lista de atualizações de serviço disponíveis, além de outras informações, acesse a página **Atualizações de serviço** no console.
1. Faça login no Console de gerenciamento da AWS e abra o console do MemoryDB em. [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/)
1. No painel de navegação, selecione **Atualizações de serviço**.
Em **Atualizações de serviço**, é possível visualizar o seguinte:
+ **Nome da atualização de serviço**: o nome exclusivo da atualização de serviço
+ **Atualização de serviço**: fornece informações detalhadas sobre a atualização de serviço
+ **Data de início da atualização automática**: se esse atributo for definido, o MemoryDB começará a programar seus clusters para serem atualizados automaticamente nas janelas de manutenção apropriadas após essa data. Você receberá notificações com antecedência sobre a janela exata de manutenção programada, que pode não ser a imediata após a **data de início da atualização automática**. Você ainda pode aplicar a atualização aos seus clusters sempre que quiser. Se o atributo não estiver definido, a atualização do serviço não estará habilitada para atualização automática e o MemoryDB não atualizará seus clusters automaticamente.
Em **Status da atualização do cluster**, é possível visualizar uma lista de clusters nos quais a atualização do serviço não foi aplicada ou acabou de ser aplicada recentemente. Para cada cluster, é possível visualizar o seguinte:
+ **Nome do cluster**: o nome do cluster
+ **Nós atualizados:** a proporção de nós individuais dentro de um cluster específico que foram atualizados ou permanecem disponíveis para a atualização de serviço específica.
+ **Tipo de atualização**: o tipo da atualização de serviço, que é **security-update** (atualização-de-segurança) ou **engine-update** (atualização-de-mecanismo)
+ **Status**: o status da atualização de serviço no cluster, que é um dos seguintes:
+ *disponível*: a atualização está disponível para clusters de requisito.
+ *em andamento*: a atualização está sendo aplicada a esse cluster.
+ *programada*: a data de atualização foi programada.
+ *concluída*: a atualização foi aplicada com êxito. O cluster com status completo será exibido por 7 dias após sua conclusão.
Se você escolheu qualquer um ou todos os clusters com o status **disponível** ou **programado** e, em seguida, escolheu **Aplicar agora**, a atualização começará a ser aplicada nesses clusters.
## Aplicando as atualizações do serviço usando o AWS CLI
Depois de receber a notificação de que há atualizações de serviços disponíveis, você poderá inspecioná-las e aplicá-las usando a AWS CLI:
+ Para recuperar uma descrição das atualizações de serviços disponíveis, execute o seguinte comando:
`aws memorydb describe-service-updates --status available`
Para obter mais informações, consulte [describe-service-updates](https://docs.aws.amazon.com/cli/latest/reference/memorydb/describe-service-updates.html).
+ Para aplicar uma atualização de serviço em uma lista de clusters, execute o seguinte comando:
`aws memorydb batch-update-cluster --service-update ServiceUpdateNameToApply=sample-service-update --cluster-names cluster-1 cluster2`
Para obter mais informações, consulte [batch-update-cluster](https://docs.aws.amazon.com/cli/latest/reference/memorydb/batch-update-cluster.html).