Resolver problemas de perda de dados da Cache do Azure para Redis
Este artigo explica como diagnosticar perdas de dados reais ou percebidas que possam ocorrer na Cache do Azure para Redis.
Nota
Várias das etapas de solução de problemas neste guia incluem instruções para executar comandos Redis e monitorar várias métricas de desempenho. Para obter mais informações e instruções, consulte os artigos na seçã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. Você pode executar esses comandos no console 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. |
| Despejo de chaves | As chaves são removidas sob pressão da memória. |
| Exclusão de chave | 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
O Cache Redis do Azure remove uma chave automaticamente se for atribuído um tempo limite à chave e esse período tiver passado. Para obter mais informações sobre a expiração da chave Redis, consulte a documentação do comando EXPIRE . Os valores de tempo limite também podem ser definidos usando os comandos SET, SETEX, GETSET e outros *STORE .
Para obter estatísticas sobre quantas chaves expiraram, use o comando INFO . A Stats seção mostra o número total de chaves expiradas. A Keyspace seçã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
Você também pode examinar as métricas de diagnóstico para seu cache, para ver se há uma correlação entre quando a chave desapareceu e um pico de chaves expiradas. Consulte o Apêndice de depuração de falhas do Redis Keyspace para obter informações sobre como usar keyspace notificações ou MONITOR para depurar esses tipos de problemas.
Despejo de chaves
O Cache Redis do Azure requer espaço de memória para armazenar dados. Ele limpa as teclas para liberar memória disponível quando necessário. Quando os valores used_memory ou used_memory_rss no comando INFO se aproximam da configuração maxmemory configurada, o Cache Redis do Azure começa a remover chaves da memória com base na política de cache.
Você pode monitorar o número de chaves removidas usando o comando INFO :
# Stats
evicted_keys:13224
Você também pode examinar as métricas de diagnóstico do seu cache, para ver se há uma correlação entre quando a chave desapareceu e um pico nas chaves removidas. Consulte o Apêndice de depuração de falhas do Redis Keyspace para obter informações sobre como usar notificações de espaço de chave ou MONITOR para depurar esses tipos de problemas.
Exclusão de chave
Os clientes Redis podem emitir o comando DEL ou HDEL para remover explicitamente as chaves do Cache do Azure para Redis. Você pode controlar o número de operações de exclusão usando o comando INFO . Se os Commandstats comandos DEL ou HDEL tiverem sido chamados, eles serão listados na seçã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 do Cache do Azure para Redis na camada Standard ou Premium é configurada com um nó primário e pelo menos uma réplica. Os dados são copiados do primário para uma réplica de forma assíncrona usando um processo em segundo plano. O site redis.io descreve como a replicação de dados Redis funciona em geral. Para cenários em que os clientes gravam no Redis com frequência, a perda parcial de dados pode ocorrer porque não é garantido que a replicação seja instantânea. Por exemplo, se o primário ficar inativo depois que um cliente gravar uma chave nele, mas antes que o processo em segundo plano tenha a chance de enviar essa chave para a réplica, a chave será perdida quando a réplica assumir o controle como o novo primário.
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 |
|---|---|
| Lavagem de chaves | As chaves foram removidas manualmente. |
| Seleção incorreta do banco 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. |
Lavagem de chaves
Os clientes podem chamar o comando FLUSHDB para remover todas as chaves em um único banco de dados ou FLUSHALL para remover todas as chaves de todos os bancos de dados em um cache Redis. Para saber se as chaves foram liberadas, use o comando INFO . A Commandstats seção mostra se um dos comandos FLUSH 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 do banco de dados
O Cache Redis do Azure usa o db0 banco de dados por padrão. Se você alternar para outro banco de dados (por exemplo, db1) e tentar ler chaves dele, o Cache Redis do Azure 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.
Os caches nas camadas Standard e Premium oferecem uma resiliência muito maior contra perda de dados usando duas VMs em uma 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 o uso da persistência de dados Redis e da replicação geográfica para melhorar a proteção de seus dados contra essas falhas de infraestrutura.
Informações adicionais
Estes artigos fornecem mais informações sobre como evitar a perda de dados: