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 autoprojetados
nota
As considerações a seguir só se aplicam ao atualizar clusters autoprojetados. Eles não se aplicam ao ElastiCache Serverless.
Considerações sobre Valkey e Redis OSS
Ao atualizar um cluster autoprojetado, 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 com novas tentativas de erro e recuo exponencial e as práticas recomendadas para minimizar o tempo de inatividade durante a manutenção.
-
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)
-
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.
-
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 autoprojetado com um backup criado externamente.
-
Exclua o antigo cluster do Valkey ou Redis OSS (modo cluster desabilitado) ou o grupo de replicação. Para ter mais informações, consulte Excluindo um cluster no ElastiCache ou Exclusão de um grupo de replicação.
-
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).
-
-
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 Redis OSS de nó único e clusters Redis individuais com o Multi-AZ desabilitado, 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. 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 com o Multi-AZ habilitado, também recomendamos que você programe atualizações do mecanismo durante períodos de baixo tráfego de gravações recebidas. 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 autoprojetado, 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.
