Versões do mecanismo
Esta seção aborda as versões compatíveis dos mecanismos Valkey e Redis OSS.
Tópicos
MemoryDB versão 7.2.6
Em 8 de outubro de 2024, o Valkey 7.2.6 foi lançado. O Valkey 7.2.6 tem diferenças de compatibilidade semelhantes às versões anteriores do Redis OSS 7.2.5. Aqui estão as principais diferenças entre o Valkey e o Redis OSS 7.0 e 7.1:
Nova opção WITHSCORE para os comandos ZRANK e ZREVRANK
CLIENT NO-TOUCH para que os clientes executem comandos sem afetar a LRU/LFU das chaves.
Novo comando CLUSTER MYSHARDID que retorna o ID do fragmento do nó para agrupar logicamente os nós no modo de cluster com base na replicação.
Otimizações de desempenho e memória para vários tipos de dados.
Aqui estão as mudanças de comportamento que podem causar interrupção entre o Valkey 7.2 e o Redis OSS 7.1 (ou 7.0):
Ao chamar PUBLISH com um cliente RESP3 que também está inscrito no mesmo canal, o pedido é alterado e a resposta é enviada antes da mensagem publicada.
O rastreamento do lado do cliente para scripts agora rastreia as chaves que são lidas pelo script, em vez das chaves declaradas pelo chamador de EVAL/FCALL.
A amostragem de tempo de congelamento ocorre durante a execução do comando e nos scripts.
Ao desbloquear um comando bloqueado, verificações como ACL, OOM e outras são reavaliadas.
O texto da mensagem de erro de falha da ACL e os códigos de erro são unificados.
Um comando de fluxo bloqueado que é lançado quando a chave não existe mais carrega um código de erro diferente (-NOGROUP ou -WRONGTYPE em vez de -UNBLOCKED).
As estatísticas do comando são atualizadas para comandos bloqueados somente quando o comando realmente é executado.
O armazenamento interno dos usuários da ACL não remove mais as regras redundantes de comando e categoria. Isso pode alterar a forma como essas regras são exibidas como parte de ACL SAVE, ACL GETUSER e ACL LIST.
Todas as conexões de cliente criadas para replicação baseada em TLS usam SNI, se possível.
XINFO STREAM: o campo de resposta seen-time agora indica a última tentativa de interação em vez da última interação bem-sucedida. O novo campo de resposta active-time agora indica a última interação bem-sucedida.
XREADGROUP e X[AUTO]CLAIM criam o consumidor independentemente de ele ter sido capaz de realizar alguma leitura/reivindicação. [TBD - o que é “isso” aqui?]
Sinalizador sanitize-payload definido pelo usuário padrão da ACL recém-criado em ACL LIST/GETUSER.
O comando HELLO não afeta o estado do cliente, a menos que seja bem-sucedido.
As respostas NAN são normalizadas para um único tipo nan, semelhante ao comportamento atual de inf.
Para ter mais informações sobre o Valkey, consulte Valkey
Para ter mais informações sobre o Valkey versão 7.2, consulte Redis OSS 7.2.4 Release Notes
MemoryDB versão 7.1 (aprimorado)
O MemoryDB versão 7.1 adiciona suporte a recursos de pesquisa vetorial em todas as regiões, bem como correções de bugs críticos e aprimoramentos de desempenho.
Recurso de pesquisa vetorial: a pesquisa vetorial pode ser usada com a funcionalidade existente do MemoryDB. As aplicações que não usam a pesquisa vetorial não serão afetadas por sua presença. A pesquisa vetorial está disponível no MemoryDB versão 7.1 em diante em todas as regiões. Consulte aqui a documentação para ter informações adicionais.
nota
O MemoryDB versão 7.1 é compatível com o Redis OSS v7.0. Para ter mais informações sobre o Redis OSS 7.0, consulte Redis OSS 7.0 Release Notes
MemoryDB versão 7.0 (aprimorado)
O MemoryDB 7.0 adiciona várias melhorias e suporte para novas funcionalidades:
-
Funções
: o MemoryDB 7 adiciona suporte a funções e fornece uma experiência gerenciada que permite que os desenvolvedores executem scripts LUA com a lógica da aplicação armazenada no cluster do MemoryDB, sem exigir que os clientes reenviem os scripts para o servidor com cada conexão. -
Melhorias na ACL
: o MemoryDB 7 adiciona suporte para a próxima versão das listas de controle de acesso (ACLs). Com o MemoryDB OSS Valkey 7 ou Redis OSS 7, os clientes agora podem especificar vários conjuntos de permissões em chaves ou espaços de chave específicos. -
Pub/Sub fragmentado
: o MemoryDB 7 adiciona suporte para executar a funcionalidade Pub/Sub de forma fragmentada ao executar o MemoryDB no modo de cluster habilitado (CME). Os recursos de Pub/Sub permitem que os publicadores enviem mensagens para qualquer número de assinantes em um canal. Com o Amazon MemoryDB Valkey 7 e Redis OSS 7, os canais são vinculados a um fragmento no cluster do MemoryDB, eliminando a necessidade de propagar as informações do canal entre os fragmentos. Isso resulta em melhor escalabilidade. -
Multiplexação de E/S aprimorada: o MemoryDB Valkey 7 e Redis OSS versão 7 apresenta a multiplexação de E/S aprimorada, que proporciona maior throughput e menor latência para workloads de alto throughput com muitos clientes conectados simultaneamente a um cluster do MemoryDB. Por exemplo, ao usar um cluster de nós r6g.4xlarge e executar 5.200 clientes simultâneos, você pode alcançar até 46% de aumento no throughput (operações de leitura e gravação por segundo) e redução de até 21% na latência P99, em comparação com o MemoryDB versão 6.
Para ter mais informações sobre o Valkey, consulte Valkey
Para ter mais informações sobre o Valkey versão 7.2, consulte Redis OSS 7.2.4 Release Notes
MemoryDB com Redis OSS versão 6.2 (aprimorado)
O MemoryDB apresenta a próxima versão do mecanismo Redis OSS, que inclui Autenticação de usuários com listas de controle de acesso (ACLs), suporte à atualização automática de versão, armazenamento em cache do lado do cliente e melhorias operacionais significativas.
A versão 6.2.6 do mecanismo Redis também inclui suporte ao formato JavaScript Object Notation (JSON) nativo, que é uma maneira simples e sem esquema de codificar conjuntos de dados complexos em clusters do Redis OSS. Com o suporte a JSON, é possível aproveitar o desempenho e as APIs do Redis OSS para aplicações que operam em JSON. Para ter mais informações, consulte Conceitos básicos do JSON. Também inclui a métrica JsonBasedCmds relacionada ao JSON, que é incorporada ao CloudWatch para monitorar o uso desse tipo de dados. Para ter mais informações, consulte Métricas para MemoryDB.
Com o Redis OSS 6, o MemoryDB oferecerá uma única versão para cada versão secundária do Redis OSS, em vez de oferecer várias versões de patch. Isso foi projetado para minimizar a confusão e a ambiguidade de ter que escolher entre várias versões secundárias. O MemoryDB também gerenciará automaticamente a versão secundária e a versão de correção de seus clusters em execução, garantindo melhor desempenho e segurança aprimorada. Isso será tratado por meio de canais padrão de notificação ao cliente por meio de uma campanha de atualização de serviço. Para ter mais informações, consulte Atualizações de serviço no MemoryDB.
Se você não especificar a versão do mecanismo durante a criação, o MemoryDB selecionará automaticamente a versão preferida do Redis OSS para você. Por outro lado, se você especificar a versão do mecanismo usando 6.2, o MemoryDB invocará automaticamente a versão de patch preferida do Redis OSS 6.2 que estiver disponível.
Por exemplo, quando você criar um cluster, você definirá o parâmetro --engine-version como 6.2. O cluster será iniciado com a versão de patch preferencial atual disponível no momento da criação. Qualquer solicitação com um valor de versão completa do mecanismo será rejeitada, uma exceção será lançada e o processo falhará.
Ao chamar a API DescribeEngineVersions, o valor do parâmetro EngineVersion será definido como 6.2 e a versão real completa do mecanismo será retornada no campo EnginePatchVersion.
Para ter mais informações sobre o Redis OSS versão 6.2, consulte Redis 6.2 Release Notes
Atualização de versões de mecanismos
Por padrão, o MemoryDB gerencia automaticamente a versão do patch de seus clusters em execução por meio de atualizações de serviço. Além disso, você pode desativar a atualização automática de versões secundárias se definir a propriedade AutoMinorVersionUpgrade dos seus clusters como “false”. No entanto, você não pode cancelar a atualização automática da versão do patch.
Você pode controlar se e quando os softwares compatíveis com o protocolo que alimenta seu cluster são atualizados para novas versões com suporte pelo MemoryDB antes do início do upgrade automático. 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.
Você também pode realizar a atualização de um MemoryDB existente com mecanismo Redis OSS para um mecanismo Valkey.
Você pode iniciar os upgrades da versão do mecanismo em seu cluster das seguintes maneiras:
Ao atualizá-lo e especificar uma nova versão do mecanismo. Para ter mais informações, consulte Modificar um cluster do MemoryDB.
Aplicando a atualização do serviço para a versão do mecanismo correspondente. Para ter mais informações, consulte Atualizações de serviço no MemoryDB.
Observe o seguinte:
Você pode atualizar para uma versão de mecanismo mais recente, mas não pode fazer downgrade para uma versão de mecanismo mais antiga. Se quiser usar uma versão de mecanismo mais antiga, você deverá excluir o cluster existente e criá-lo novamente com a versão mais antiga do mecanismo.
Recomendamos atualizar periodicamente para a versão principal mais recente, já que a maioria das melhorias principais não são transferidas para versões mais antigas. À medida que o MemoryDB expande a disponibilidade para uma nova região da AWS, o MemoryDB oferece suporte às duas versões
MAJOR.MINORmais recentes à época para a nova região. Por exemplo, se uma nova região da AWS for inicializada e as versõesMAJOR.MINORmais recentes do MemoryDB forem 7.0 e 6.2, o MemoryDB oferecerá suporte às versões 7.0 e 6.2 na nova região da AWS. À medida que novas versõesMAJOR.MINORdo MemoryDB forem lançadas, o MemoryDB adicionará suporte às versões recém-lançadas do MemoryDB. Para saber mais sobre como escolher regiões para o MemoryDB, consulte Regiões e endpoints com suporte.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, o MemoryDB reserva o direito de executar patches no cluster em seu nome caso ocorra uma vulnerabilidade de segurança crítica no sistema ou software.
O MemoryDB oferecerá uma única versão para cada versão secundária do Valkey ou Redis OSS, em vez de oferecer várias versões de patch. Isso foi projetado para minimizar a confusão e a ambiguidade de ter que escolher entre várias versões. O MemoryDB também gerenciará automaticamente a versão secundária e a versão de correção de seus clusters em execução, garantindo melhor desempenho e segurança aprimorada. Isso será tratado por meio de canais padrão de notificação ao cliente por meio de uma campanha de atualização de serviço. Para ter mais informações, consulte Atualizações de serviço no MemoryDB.
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.
-
Recomendamos que você faça atualizações do mecanismo durante períodos de baixo tráfego de gravação de entrada.
Os clusters com vários fragmentos são processados e corrigidos da seguinte forma:
-
Apenas uma operação de upgrade é realizada por fragmento a qualquer momento.
-
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.
-
Tópicos
Como atualizar as versões dos mecanismos
Você inicia as atualizações de versão do seu cluster modificando-o usando o console do MemoryDB, o AWS CLI ou a API do MemoryDB e especificando uma versão mais recente do mecanismo. Para obter mais informações, consulte os tópicos a seguir.
Resolver bloqueios de atualização do mecanismo Redis OSS
Conforme mostrado na tabela a seguir, a operação de atualização do mecanismo Redis OSS será bloqueada se você tiver uma operação pendente de aumento vertical da escala.
| Operações pendentes | Operações bloqueadas |
|---|---|
| Amplie a sua capacidade | Atualização imediata do mecanismo |
| Atualização do mecanismo | Expansão imediata |
| Expansão e atualização do mecanismo | Expansão imediata |
| Atualização imediata do mecanismo |
