Resolver problemas de perda de dados da Cache do Azure para Redis

  • Artigo

Este artigo explica como diagnosticar perdas de dados reais ou percebidas que possam ocorrer na Cache do Azure para Redis.

Nota

Vários dos passos de resolução de problemas neste guia incluem instruções para executar comandos redis e monitorizar várias métricas de desempenho. Para obter mais informações e instruções, consulte os artigos na secção Informações adicionais .

Perda parcial de chaves

A Cache do Azure para Redis não elimina aleatoriamente as chaves depois de serem armazenadas na memória. No entanto, remove as chaves em resposta a políticas de expiração, políticas de expulsão e comandos explícitos de eliminação de chaves. Pode executar estes comandos na consola ou através da CLI.

As chaves que foram escritas no nó primário numa instância da Cache do Azure para Redis Premium ou Standard também podem não ficar imediatamente disponíveis numa réplica. Os dados são replicados da réplica primária para a réplica de forma assíncrona e não bloqueada.

Se descobrir que as chaves desapareceram da cache, verifique as seguintes causas possíveis:

Causa Description
Expiração da chave As chaves são removidas devido aos tempos limite definidos.
Expulsão de chave As chaves são removidas sob pressão da memória.
Eliminação de chaves As chaves são removidas através de comandos de eliminação explícitos.
Replicação assíncrona As chaves não estão disponíveis numa réplica devido a atrasos na replicação de dados.

Expiração da chave

Cache do Azure para Redis remove automaticamente uma chave se lhe for atribuído um tempo limite e esse período tiver passado. Para obter mais informações sobre a expiração da chave Redis, veja a documentação do comando EXPIRE . Os valores de tempo limite também podem ser definidos com os comandos SET, SETEX, GETSET e outros *STORE .

Para obter estatísticas sobre quantas chaves expiraram, utilize o comando INFO . A Stats secção mostra o número total de chaves expiradas. A Keyspace secção fornece mais informações sobre o número de chaves com tempos limite e o valor médio de tempo limite.


# Stats

expired_keys:46583

# Keyspace

db0:keys=3450,expires=2,avg_ttl=91861015336

Também pode ver as métricas de diagnóstico da cache para ver se existe uma correlação entre quando a chave desapareceu e um pico nas chaves expiradas. Veja o Apêndice de Depurar Falhas do Espaço de Chaves de Redis para obter informações sobre como utilizar keyspace notificações ou MONITOR para depurar estes tipos de problemas.

Expulsão de chave

Cache do Azure para Redis requer espaço de memória para armazenar dados. Remove as chaves para libertar memória disponível quando necessário. Quando os valores used_memory ou used_memory_rss no comando INFO se aproximam da definição maxmemory configurada, Cache do Azure para Redis começa a expulsar chaves da memória com base na política de cache.

Pode monitorizar o número de chaves expulsas com o comando INFO :

# Stats

evicted_keys:13224

Também pode ver as métricas de diagnóstico da cache para ver se existe uma correlação entre quando a chave desapareceu e um pico nas chaves expulsas. Veja o Apêndice de Depurar Falhas do Espaço de Chaves de Redis para obter informações sobre como utilizar notificações do espaço de chaves ou MONITOR para depurar estes tipos de problemas.

Eliminação de chaves

Os clientes Redis podem emitir o comando DEL ou HDEL para remover explicitamente as chaves do Cache do Azure para Redis. Pode controlar o número de operações de eliminação com o comando INFO . Se os comandos DEL ou HDEL tiverem sido chamados, serão listados na Commandstats secção .

# Commandstats

cmdstat_del:calls=2,usec=90,usec_per_call=45.00

cmdstat_hdel:calls=1,usec=47,usec_per_call=47.00

Replicação assíncrona

Qualquer instância Cache do Azure para Redis no escalão Standard ou Premium é configurada com um nó primário e, pelo menos, uma réplica. Os dados são copiados do principal para uma réplica de forma assíncrona através de um processo em segundo plano. O site redis.io descreve como a replicação de dados do Redis funciona em geral. Para cenários em que os clientes escrevem frequentemente no Redis, a perda parcial de dados pode ocorrer porque a replicação não é garantida como instantânea. Por exemplo, se o principal ficar inativo depois de um cliente escrever uma chave no mesmo, mas antes de o processo em segundo plano ter a oportunidade de enviar essa chave para a réplica, a chave é perdida quando a réplica assume o comando como a nova primária.

Perda de chaves importante ou completa

Se a maioria ou a totalidade das chaves desaparecerem da cache, verifique as seguintes causas possíveis:

Causa Description
Descarga de teclas As chaves foram removidas manualmente.
Seleção incorreta da base de dados A Cache do Azure para Redis está definida para utilizar uma base de dados não predefinida.
Falha na instância do Redis O servidor Redis não está disponível.

Descarga de teclas

Os clientes podem chamar o comando FLUSHDB para remover todas as chaves numa base de dados individual ou FLUSHALL para remover todas as chaves de todas as bases de dados numa cache de Redis. Para saber se as chaves foram removidas da cache, utilize o comando INFO . A Commandstats secção mostra se um dos FLUSH comandos foi chamado:

# Commandstats

cmdstat_flushall:calls=2,usec=112,usec_per_call=56.00

cmdstat_flushdb:calls=1,usec=110,usec_per_call=52.00

Seleção incorreta da base de dados

Cache do Azure para Redis utiliza a db0 base de dados por predefinição. Se mudar para outra base de dados (por exemplo, db1) e tentar ler as chaves da mesma, Cache do Azure para Redis não as encontrará lá. Cada base de dados é uma unidade logicamente separada e contém um conjunto de dados diferente. Utilize o comando SELECT para utilizar outras bases de dados disponíveis e procurar chaves em cada uma delas.

Falha na instância do Redis

O Redis é um arquivo de dados na memória. Os dados são mantidos nas máquinas físicas ou virtuais que alojam a cache de Redis. Uma instância da Cache do Azure para Redis no escalão Básico é executada apenas numa única máquina virtual (VM). Se essa VM estiver inativa, todos os dados que armazenou na cache serão perdidos.

As caches nos escalões Standard e Premium oferecem uma resiliência muito maior face à perda de dados ao utilizar duas VMs numa configuração replicada. Quando o nó primário dessa cache falha, o nó de réplica assume o controlo para servir dados automaticamente. Estas VMs estão localizadas em domínios separados para falhas e atualizações, para minimizar a probabilidade de ambas ficarem indisponíveis simultaneamente. No entanto, se ocorrer uma falha importante no datacenter, as VMs poderão ficar inativas em conjunto. Nestes casos raros, os dados serão perdidos.

Considere utilizar a persistência de dados do Redis e a georreplicação para melhorar a proteção dos seus dados contra estas falhas de infraestrutura.

Informações adicionais

Estes artigos fornecem mais informações sobre como evitar a perda de dados: