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 Valkey, Redis OSS e Memcached.
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 MINOR e a versão do PATCH software 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 MAJOR versão estiver disponível, o ElastiCache Serverless enviará uma notificação no console e um evento no. EventBridge Você pode optar por atualizar seu cache para a versão principal mais recente modificando seu cache usando o console ou API selecionando a versão mais recente do mecanismo. CLI
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 Você pode controlar quando atualizar seu cache para as PATCH versões e versões mais recentes disponíveisMAJOR. MINOR 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 OSS cluster Valkey ou Redis 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 As versões (RedisOSS) são identificadas com uma versão semântica que compreende um componente e. MAJOR MINOR Por exemplo, no Redis OSS 6.2, a versão principal é 6 e a versão secundária 2. Ao operar clusters autoprojetados, ElastiCache (RedisOSS) também expõe o PATCH componente, por exemplo, Redis OSS 6.2.1, e a versão do patch é 1.
MAJORas versões são para alterações API incompatíveis e as MINOR versões são para novas funcionalidades adicionadas de forma compatível com versões anteriores. PATCHas versões são para correções de bugs compatíveis com versões anteriores e alterações não funcionais.
Com o Valkey e o RedisOSS, você inicia os upgrades da versão do mecanismo em 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 fazer o upgrade 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 OSS cluster Valkey ou Redis 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.
Começando com o Valkey 7.2 e o Redis OSS 6.0, ElastiCache oferecerá uma única versão para cada lançamento menor, em vez de oferecer várias versões de patch.
A partir da versão 5.0.6 OSS do mecanismo Redis, você pode atualizar sua versão de 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 levar a um tempo maior de failover durante a DNS propagação (30s-1m).
-
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 (RedisOSS) foi projetado para fazer o melhor esforço para reter seus dados existentes e requer uma replicação bem-sucedida do RedisOSS.
-
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 que você implemente as melhores práticas para OSS clientes Redis com novas tentativas de erro e recuo exponencial, além das melhores práticas para minimizar o tempo de inatividade durante a manutenção.
-
Você não pode atualizar diretamente do Valkey ou do Redis OSS (modo de cluster desativado) para o Valkey ou Redis OSS (modo de cluster ativado) ao atualizar seu mecanismo. O procedimento a seguir mostra como fazer o upgrade do Valkey ou do Redis OSS (modo de cluster desativado) para o Valkey ou Redis OSS (modo de cluster ativado).
Para atualizar de uma versão do mecanismo Valkey ou Redis OSS (modo de cluster desativado) para Valkey ou Redis OSS (modo de cluster ativado)
-
Faça um backup do seu cluster ou grupo de replicação Valkey ou Redis OSS (modo de cluster desativado). Para obter mais informações, consulte Realização de backups manuais.
-
Use o backup para criar e semear um cluster Valkey ou Redis OSS (modo de cluster ativado) 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: semeando um novo cluster autoprojetado com um backup criado externamente.
-
Exclua o antigo cluster ou grupo de replicação Valkey ou Redis OSS (modo de cluster desativado). Para obter mais informações, consulte Excluindo um cluster no ElastiCache ou Exclusão de um grupo de replicação.
-
Dimensione o novo cluster ou grupo de replicação Valkey ou Redis OSS (modo de cluster ativado) para o número de fragmentos (grupos de nós) necessários. Para obter mais informações, consulte Dimensionamento de clusters em Valkey ou Redis OSS (modo de cluster ativado)
-
-
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 únicos e OSS clusters com o Multi-AZ desativado, recomendamos que seja disponibilizada memória suficiente para o Redis, OSS conforme descrito em. Garantindo que você tenha memória suficiente para criar um instantâneo do Valkey ou do 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 OSS clusters Redis com o Multi-AZ ativado, 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 superior, 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 projetado por você mesmo, 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.
