Principais diferenças de comportamento e compatibilidade da versão do mecanismo com o Redis OSS

As versões principais são para alterações incompatíveis com a API

As versões secundárias são para novas funcionalidades adicionadas de forma compatível com versões anteriores

As versões de patch são para correções de bugs compatíveis com versões anteriores e alterações não funcionais

SCRIPT LOAD e SCRIPT FLUSH não são mais propagados para réplicas. Se você precisar ter alguma durabilidade para scripts, recomendamos que você considere usar as funções do Redis OSS.

Os canais Pubsub agora estão bloqueados por padrão para novos usuários de ACL.

O comando STRALGO foi substituído pelo comando LCS.

O formato de ACL GETUSER foi alterado para que todos os campos mostrem o padrão de cadeia de caracteres de acesso padrão. Se você teve automação usando ACL GETUSER, verifique se ela funcionará com qualquer um dos formatos.

As categorias de ACL para SELECT, WAIT, ROLE, LASTSAVE, READONLY, READWRITE e ASKING foram alteradas.

O comando INFO agora mostra estatísticas de comando por subcomando, em vez de nos comandos do contêiner de nível superior.

Os valores de retorno dos comandos LPOP, RPOP, ZPOPMIN e ZPOPMAX foram alterados em determinados casos de borda. Se você usar esses comandos, verifique as notas de release e avalie se foi afetado.

Os comandos SORT e SORT_RO agora exigem acesso a todo o espaço de teclas para usar os argumentos GET e BY.

Os sinalizadores ACL dos comandos TIME, ECHO, ROLE e LASTSAVE foram alterados. Isso pode fazer com que comandos que antes tinham permissão sejam rejeitados e vice-versa.

Ao atualizar do Redis OSS 6.0, a ordem dos pares chave/valor retornados de uma resposta de mapa para um script lua é alterada. Se os seus scripts usarem redis.setresp() ou retornarem um mapa (novo no Redis OSS 6.0), considere as implicações que o script pode quebrar nas atualizações.

O número máximo de bancos de dados permitidos foi reduzido de 1,2 milhão para 10 mil. O valor padrão é 16, e desencorajamos o uso de valores muito maiores do que isso, pois encontramos problemas de performance e memória.

Defina o AutoMinorVersionUpgrade parâmetro como sim e ElastiCache gerenciará a atualização da versão secundária por meio de atualizações de autoatendimento. Isso será tratado por meio de canais padrão de notificação do cliente por meio de uma campanha de atualização de autoatendimento. Para obter mais informações, consulte Atualizações de autoatendimento em ElastiCache.

Os scripts são replicados por efeitos em vez de reexecutar o script na réplica. Isso geralmente melhora a performance, mas pode aumentar a quantidade de dados replicados entre os primários e as réplicas. Há uma opção para voltar ao comportamento anterior que só está disponível na ElastiCache versão 5.0 para Redis OSS.

Se você estiver atualizando a partir do Redis OSS 4.0, alguns comandos em scripts LUA retornarão argumentos em uma ordem diferente daquela em versões anteriores. No Redis OSS 4.0, o Redis OSS ordenaria algumas respostas lexigraficamente para tornar as respostas determinísticas, essa ordem não é aplicada quando os scripts são replicados por efeitos.

No Redis OSS 5.0.3 e superior, ElastiCache para o Redis, o OSS descarregará parte do trabalho de E/S para núcleos em segundo plano em tipos de instância com mais de 4. VCPUs Isso pode alterar as características de performance do Redis OSS e alterar os valores de algumas métricas. Para obter mais informações, consulte Que métricas devo monitorar? para entender se você precisa alterar quais métricas você assiste.

O log lento agora registra dois argumentos adicionais, o nome e o endereço do cliente. Essa alteração deve ser compatível com versões anteriores, a menos que você confie explicitamente em cada entrada de log lenta contendo 3 valores.

O CLUSTER NODES agora retorna um formato ligeiramente diferente, que não é compatível com versões anteriores. Recomendamos que os clientes não usem esse comando para aprender sobre os nós presentes em um cluster e, em vez disso, eles usem CLUSTER SLOTS.

Não há mudanças de compatibilidade a serem destacadas para esta versão.

A partir do Redis OSS 2.8.22, o Redis OSS AOF não é mais suportado no Redis OSS. ElastiCache Recomendamos o uso do MemoryDB quando os dados precisam ser persistidos de forma duradoura.

A partir do Redis OSS 2.8.22, ElastiCache para Redis, o OSS não suporta mais a anexação de réplicas às primárias hospedadas nele. ElastiCache Durante a atualização, as réplicas externas serão desconectadas e não poderão se reconectar. Recomendamos usar o cache do lado do cliente, disponibilizado no Redis OSS 6.0 como uma alternativa às réplicas externas.

Os comandos TTL e PTTL agora retornarão -2 se a chave não existir e -1 se existir, mas não tiver expiração associada. O Redis OSS 2.6 e as versões anteriores costumavam retornar -1 para ambas as condições.

O SORT com ALPHA agora classificará de acordo com o local de agrupamento local, se nenhuma opção STORE for usada.