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á. # Considerações sobre atualização ao trabalhar com clusters baseados em nós **nota** As considerações a seguir só se aplicam ao atualizar clusters baseados em nós. Eles não se aplicam ao ElastiCache Serverless. **Considerações sobre Valkey e Redis OSS** Ao atualizar um cluster baseado em nós, leve em consideração o seguinte. + O gerenciamento da versão do mecanismo foi desenvolvido para que você possa ter o máximo controle possível sobre a execução de patches. No entanto, ElastiCache se reserva o direito de corrigir seu cluster em seu nome no caso improvável de uma vulnerabilidade crítica de segurança no sistema ou no software de cache. + Começando com a ElastiCache versão 7.2 para Valkey e a ElastiCache versão 6.0 para Redis OSS, ElastiCache oferecerá uma única versão para cada versão secundária, em vez de oferecer várias versões de patch. + A partir do mecanismo Redis OSS versão 5.0.6, você pode atualizar a versão do cluster com o mínimo de tempo de inatividade. O cluster estará disponível para leituras durante todo o processo de atualização e para gravações durante a maior parte da atualização, exceto durante a operação de failover que dura alguns segundos. + Você também pode atualizar seus ElastiCache clusters com versões anteriores à 5.0.6. O processo envolvido é o mesmo, mas pode incorrer em tempo de failover mais longo durante a propagação do DNS (30 s a 1 m). + A partir do Redis OSS 7, ElastiCache oferece suporte à alternância entre Valkey ou Redis OSS (modo de cluster desativado) e Valkey ou Redis OSS (modo de cluster ativado). + O processo de atualização do mecanismo Amazon ElastiCache for Redis OSS foi projetado para fazer o melhor esforço para reter seus dados existentes e requer uma replicação bem-sucedida do Redis OSS. + Ao atualizar o mecanismo, ElastiCache encerrará as conexões existentes do cliente. Para minimizar o tempo de inatividade durante as atualizações do mecanismo, recomendamos implementar [as práticas recomendadas para clientes do Redis OSS](BestPractices.Clients.redis.md) com novas tentativas de erro e recuo exponencial e as práticas recomendadas para [minimizar o tempo de inatividade durante a manutenção](BestPractices.MinimizeDowntime.md). + Não é possível atualizar diretamente do Valkey ou Redis OSS (modo cluster desabilitado) para o Valkey ou Redis OSS (modo cluster habilitado) ao atualizar seu mecanismo. O procedimento a seguir mostra como atualizar do Valkey ou Redis OSS (modo cluster desabilitado) para o Valkey ou Redis OSS (modo cluster habilitado). **Para atualizar de uma versão de mecanismo Valkey ou Redis OSS (modo cluster desabilitado) para Valkey ou Redis OSS (modo cluster habilitado)** 1. Faça um backup do seu cluster do Valkey ou Redis OSS (modo cluster desabilitado) ou do grupo de replicação. Para obter mais informações, consulte [Realização de backups manuais](backups-manual.md). 1. Use o backup para criar e propagar um cluster do Valkey ou Redis OSS (modo cluster habilitado) com um fragmento (grupo de nós). Especifique a nova versão do mecanismo e habilite o modo de cluster ao criar o cluster ou o grupo de replicação. Para obter mais informações, consulte [Tutorial: propagação de um novo cluster baseado em nós com um backup criado externamente](backups-seeding-redis.md). 1. Exclua o antigo cluster do Valkey ou Redis OSS (modo cluster desabilitado) ou o grupo de replicação. Para acessar mais informações, consulte [Excluindo um cluster no ElastiCache](Clusters.Delete.md) ou [Exclusão de um grupo de replicação](Replication.DeletingRepGroup.md). 1. Escale o novo cluster ou grupo de replicação do Valkey ou Redis OSS (modo cluster habilitado) para o número de fragmentos (grupos de nós) que você precisa. Para obter mais informações, consulte [Escalabilidade de clusters no Valkey ou Redis OSS (modo cluster habilitado)](scaling-redis-cluster-mode-enabled.md). + Ao atualizar as principais versões do mecanismo, por exemplo, de 5.0.6 para 6.0, também é necessário selecionar um novo grupo de parâmetros que seja compatível com a nova versão do mecanismo. + Para clusters únicos do Redis OSS e clusters Multi-AZ desativados, recomendamos que seja disponibilizada memória suficiente para o Redis OSS, conforme descrito em. [Garantir que você tem memória suficiente para criar um snapshot do Valkey ou Redis OSS](BestPractices.BGSAVE.md) Nesses casos, o primário não está disponível para solicitações de serviço durante o processo de atualização. + Para clusters Redis OSS Multi-AZ habilitados, também recomendamos que você agende atualizações do mecanismo durante períodos de baixo tráfego de gravação de entrada. Ao atualizar para o Redis OSS 5.0.6 ou posterior, o cluster primário continua disponível para solicitações de serviço durante o processo de atualização. Os clusters e os grupos de replicação com vários fragmentos são processados e corrigidos da seguinte forma: + Todos os estilhaços são processados em paralelo. Somente uma operação de atualização é realizada em um estilhaço por vez. + Em cada fragmento, todas as réplicas são processadas antes do processamento da primária. Caso haja menos réplicas em um fragmento, a primária nesse fragmento pode ser processada antes da conclusão do processamento das réplicas em outros fragmentos. + Em todos os fragmentos, os nós primários são processados em série. Somente um nó primário é atualizado por vez. + Caso a criptografia esteja habilitada no cluster ou no grupo de replicação atual, não será possível atualizar para uma versão de mecanismo que não ofereça suporte à criptografia, como de 3.2.6 a 3.2.10. **Considerações sobre o Memcached** Ao atualizar um cluster Memcached baseado em nós, considere o seguinte. + O gerenciamento da versão do mecanismo foi desenvolvido para que você possa ter o máximo controle possível sobre a execução de patches. No entanto, ElastiCache se reserva o direito de corrigir seu cluster em seu nome no caso improvável de uma vulnerabilidade crítica de segurança no sistema ou no software de cache. + Como o mecanismo Memcached não oferece suporte para persistência, as atualizações de versão do mecanismo Memcached são sempre um processo disruptivo que limpa todos os dados do cache no cluster.