Solucionar problemas de perda de dados no Redis Gerenciado do Azure (versão prévia)
Este artigo discute como diagnosticar perdas de dados reais ou percebidas que podem ocorrer no Redis Gerenciado do Azure (versão prévia).
Observação
Várias das etapas de solução de problemas neste guia incluem instruções para executar comandos do Redis e monitorar diversas métricas de desempenho. Para obter mais informações, consulte os artigos na seção Informações adicionais .
Perda parcial de chaves
O Redis Gerenciado do Azure não exclui as chaves aleatoriamente após elas terem sido armazenadas na memória. No entanto, ele remove as chaves em resposta às políticas de término ou remoção e aos comandos explícitos de exclusão de chaves. Execute esses comandos por meio da CLI.
As chaves que foram gravadas no nó primário em uma instância do Redis Gerenciado do Azure também podem não estar disponíveis em uma réplica imediatamente. Os dados são replicados do principal para a réplica de maneira assíncrona e sem bloqueio.
Se você descobrir que as chaves desapareceram do cache, verifique as seguintes causas possíveis:
| Causa | Descrição |
|---|---|
| Expiração da chave | As chaves são removidas devido aos tempos limite definidos. |
| Remoção de chave | As chaves são removidas sob pressão de memória. |
| Exclusão de chave | As chaves são removidas por comandos de exclusão explícitos. |
| Replicação assíncrona | As chaves não estão disponíveis em uma réplica devido a atrasos na replicação de dados. |
Expiração da chave
O Redis Gerenciado do Azure removerá uma chave automaticamente se a chave tiver um tempo limite atribuído e esse período tiver passado. Para obter mais informações sobre o término da chave Redis, confira a documentação do comando EXPIRE. Os valores de tempo limite também podem ser definidos com o conjunto de comandos SET, SETEX, GETSET e outros comandos *STORE.
Para obter estatísticas sobre quantas chaves expiraram, use o comando INFO. A seção Stats mostra o número total de chaves expiradas. A seção Keyspace fornece mais informações sobre o número de chaves com tempos limite e o valor de tempo limite médio.
# 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 o cache para ver se há uma correlação entre quando a chave ficou ausente e um pico nas chaves expiradas. Confira o apêndice de Depuração de falhas de keyspace do Redis para obter informações sobre como usar notificações de keyspace ou MONITOR para depurar esses tipos de problemas.
Remoção de chave
O Redis Gerenciado do Azure requer espaço de memória para armazenar dados. Ele limpa as chaves para liberar a memória disponível quando necessário. Quando os valores used_memory ou used_memory_rss valores no comando INFO aproximam-se da configuração MaxMemory definida, o Redis Gerenciado do Azure inicia a remoção de 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 para o cache para ver se há uma correlação entre quando a chave ficou ausente e um pico nas chaves removidas. Confira o apêndice de Depuração de falhas de keyspace do Redis para obter informações sobre como usar notificações de keyspace ou MONITORAR a depurar desses tipos de problemas.
Exclusão de chave
Os clientes do Redis podem emitir o comando DEL ou HDEL para remover explicitamente as chaves do Redis Gerenciado do Azure. Você pode acompanhar o número de operações de exclusão usando o comando INFO. Se os comandos DEL ou HDEL tiverem sido chamados, eles serão listados na seção Commandstats.
# 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 Redis Gerenciado do Azure com alta disponibilidade habilitada é configurada com um nó primário e pelo menos uma réplica. Os dados são copiados do principal para uma réplica de maneira assíncrona usando 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 gravam em Redis com frequência, a perda de dados parcial pode ocorrer porque essa replicação não tem garantia de ser instantânea. Por exemplo, se o principal ficar inativo depois de um cliente gravar uma chave nele, mas antes de o processo em segundo plano ter a chance de enviar essa chave para a réplica, a chave será perdida quando a réplica assumir o controle como o novo principal.
Perda grande ou completa de chaves
Se a maioria das chaves ou todas elas tiverem desaparecido do seu cache, verifique as seguintes causas possíveis:
| Causa | Descrição |
|---|---|
| Liberação de chave | As chaves foram limpas manualmente. |
| Falha na instância do Redis | O servidor Redis não está disponível. |
Liberação de chave
Os clientes podem chamar o comando FLUSHDB ou FLUSHALL para remover todas as chaves da instância do Redis. Para descobrir se as chaves foram liberadas, use o comando INFO. A seção Commandstats mostra se o comando 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
Redis é um armazenamento de dados na memória. Os dados são mantidos nos computadores físicos ou nas VM (máquinas virtuais) que hospedam o Cache Redis. Os caches do Redis Gerenciados do Azure oferecem alta resiliência contra perda de dados fornecendo caches resilientes à zona por padrão. Quando o shard principal nesse cache falha, o shard da réplica assume para atender aos dados automaticamente. Essas VMs estão localizadas em domínios separados para falhas e atualizações para minimizar a chance de ambas ficarem não disponíveis simultaneamente. No entanto, se ocorrer uma interrupção de data center principal, as VMs ainda poderão ficar inativas ao mesmo tempo. Seus dados serão perdidos nesses casos raros.
Considere usar Persistência de dados do Redis e replicação geográfica para aprimorar 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: