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 de versões para ElastiCache
Gerencie como você gostaria de atualizar seus ElastiCache caches e clusters autoprojetados atualizados para os mecanismos OSS Valkey, Memcached e Redis.
Gerenciamento de versões para ElastiCache cache sem servidor
Gerencie se e quando o cache ElastiCache sem servidor é atualizado e realize atualizações de versão de acordo com seus próprios termos e cronogramas.
ElastiCache O Serverless aplica automaticamente a versão mais recente do software MINOR e PATCH ao seu cache, sem nenhum impacto ou tempo de inatividade em seu aplicativo. Não é necessária nenhuma ação de sua parte.
Quando uma nova versão MAJOR estiver disponível, o ElastiCache Serverless enviará uma notificação no console e um evento no. EventBridge Você pode optar por atualizar o cache para a versão principal mais recente modificando o cache usando o console, a CLI ou a API e selecionando a versão mais recente do mecanismo.
Gerenciamento de versões para clusters autoprojetados ElastiCache
Ao trabalhar com ElastiCache clusters autoprojetados, você pode controlar quando o software que alimenta seu cluster de cache é atualizado para novas versões suportadas pelo. ElastiCache É possível controlar quando atualizar o cache para as versões MAJOR, MINOR e PATCH mais recentes disponíveis. Você inicia atualizações de versão do mecanismo no seu cluster ou grupo de replicação, modificando-o e especificando uma nova versão do mecanismo.
Você pode controlar se e quando o software compatível com o protocolo que alimenta seu cluster de cache é atualizado para novas versões suportadas pelo. ElastiCache Esse nível de controle permite que você mantenha a compatibilidade com versões específicas, teste novas versões com seu aplicativo antes de implantar em produção e realize atualizações de versão em seus próprios termos e cronogramas.
Como as atualizações de versões podem envolver algum risco de compatibilidade, elas não ocorrem automaticamente. Você deve iniciá-las.
Clusters Valkey e Redis OSS
nota
-
Se um cluster Valkey ou Redis OSS for replicado em uma ou mais regiões, a versão do mecanismo será atualizada para regiões secundárias e depois para a região primária.
ElastiCache para Redis, as versões OSS são identificadas com uma versão semântica que compreende um componente MAJOR e MINOR. Por exemplo, no Redis OSS 6.2, a versão principal é a 6, a versão secundária é a 2. Ao operar clusters autoprojetados, o OSS ElastiCache para Redis também expõe o componente PATCH, por exemplo, Redis OSS 6.2.1, e a versão do patch é 1.
As versões PRINCIPAIS são para alterações incompatíveis da API e as versões SECUNDÁRIAS são para novas funcionalidades adicionadas de forma compatível com as versões anteriores As versões do PATCH são para correções de bugs compatíveis com versões anteriores e mudanças não funcionais.
Com o Valkey e Redis OSS, você inicia atualizações de versão do mecanismo no seu cluster ou grupo de replicação, modificando-o e especificando uma nova versão do mecanismo. Para obter mais informações, consulte Modificação de um grupo de replicação.
Memcached
Com o Memcached, para atualizar para uma versão mais recente, você deve modificar seu cluster de cache e especificar a nova versão do mecanismo que deseja usar. Atualizar para uma versão do Memcached mais recente é um processo destrutivo. Você perde seus dados e começa com um cache frio. Para obter mais informações, consulte Modificando um cluster ElastiCache .
Você deve estar ciente dos seguintes requisitos ao atualizar de uma versão mais antiga do Memcached para o Memcached versão 1.4.33 ou posterior. CreateCacheCluster e ModifyCacheCluster falham nas seguintes condições:
-
Se
slab_chunk_max > max_item_size. -
Se
max_item_size modulo slab_chunk_max != 0. -
Se
max_item_size > ((max_cache_memory - memcached_connections_overhead) / 4).O valor
(max_cache_memory - memcached_connections_overhead)é a memória do nó utilizável para dados. Para obter mais informações, consulte Sobrecarga de conexões do Memcached.
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.
