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
<a name="VersionManagement"></a>

Gerencie como você gostaria de atualizar seus ElastiCache caches e clusters baseados em nós atualizados para os mecanismos OSS Valkey, Memcached e Redis.

## Gerenciamento de versões para ElastiCache cache sem servidor
<a name="VersionManagement-serverless"></a>

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 secundário e de 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 principal 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. Semelhante às atualizações secundárias e de patch, as atualizações da versão principal são realizadas sem tempo de inatividade do seu aplicativo.

## Gerenciamento de versões para clusters baseados em nós ElastiCache
<a name="VersionManagement-clusters"></a>

Ao trabalhar com ElastiCache clusters baseados em nós, você pode controlar quando o software que alimenta seu cluster é 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 é 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 maior e um menor. Por exemplo, no Redis OSS 6.2, a versão principal é a 6, a versão secundária é a 2. Ao operar clusters baseados em nós, ElastiCache para Redis OSS também expõe o componente de 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](Replication.Modify.md).

**Memcached**

Com o Memcached, para atualizar para uma versão mais recente, você deve modificar seu cluster 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](Clusters.Modify.md).

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](ParameterGroups.Engine.md#ParameterGroups.Memcached.Overhead).