Solucionar problemas de perda de dados no Azure Managed Redis (visualização)
Este artigo discute como diagnosticar perdas de dados reais ou percebidas que podem ocorrer no Azure Managed Redis (visualização).
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
O Azure Managed Redis não elimina aleatoriamente chaves depois de terem sido 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 através da CLI.
As chaves que foram gravadas no nó primário em uma instância do Azure Managed Redis também podem não estar disponíveis em uma réplica imediatamente. 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 Azure Managed Redis remove uma chave automaticamente 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, 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 Azure Managed Redis 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 Azure Managed Redis 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 Azure Managed 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 Azure Managed Redis com alta disponibilidade habilitada é 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. |
| Falha na instância do Redis | O servidor Redis não está disponível. |
Lavagem de chaves
Os clientes podem chamar o comando FLUSHDB ou FLUSHALL para remover todas as chaves da instância do 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
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 (VM) que hospedam o cache Redis. Os caches Redis Gerenciados do Azure oferecem alta resiliência contra perda de dados fornecendo caches resilientes de zona por padrão. Quando o fragmento primário em tal cache falha, o fragmento de réplica assume o controle 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 grande interrupção do data center, as VMs ainda poderão cair juntas. 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: