Felsöka dataförlust i Azure Cache for Redis

Den här artikeln beskriver hur du diagnostiserar faktiska eller uppfattade dataförluster som kan uppstå i Azure Cache for Redis.

Partiell förlust av nycklar

Azure Cache for Redis tar inte bort nycklar slumpmässigt när de har lagrats i minnet. Den tar dock bort nycklar som svar på förfallo- eller borttagningsprinciper och explicita kommandon för borttagning av nycklar. Nycklar som har skrivits till den primära noden i en Premium- eller Standard Azure Cache for Redis instans kanske inte heller är tillgängliga på en replik direkt. Data replikeras från den primära till repliken på ett asynkront och icke-blockerande sätt.

Om du upptäcker att nycklarna har försvunnit från cacheminnet kontrollerar du följande möjliga orsaker:

Nyckelförfallotid

Azure Cache for Redis tar bort en nyckel automatiskt om nyckeln tilldelas en time out och perioden har passerat. Mer information om förfallodatum för Redis-nycklar finns i kommandodokumentationen FÖRFALLER. Time out-värden kan också anges med hjälp av kommandona SET, SETEX, GETSEToch andra * STORE.

Om du vill få statistik om hur många nycklar som har upphört att gälla använder du kommandot INFO. Avsnittet Stats visar det totala antalet utgångna nycklar. Avsnittet Keyspace innehåller mer information om antalet nycklar med time out-värden och det genomsnittliga time out-värdet.

# Stats

expired_keys:46583

# Keyspace

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

Du kan också titta på diagnostikmått för cacheminnet för att se om det finns en korrelation mellan när nyckeln saknades och en topp i utgångna nycklar. Information om hur du använder keyspace-meddelanden eller MONITOR för att felsöka dessa typer av problem finns i tillägget för felsökning av Redis Keyspace-fel.

Avlägsning av nyckel

Azure Cache for Redis kräver minne för att lagra data. Den tar bort nycklar för att frigöra tillgängligt minne vid behov. När used_memory eller used_memory_rss i INFO-kommandoinställningen den konfigurerade maxmemory-inställningen Azure Cache for Redis att ta bort nycklar från minnet baserat på cacheprincipen.

Du kan övervaka antalet avlägsnade nycklar med hjälp av kommandot INFO:

# Stats

evicted_keys:13224

Du kan också titta på diagnostikmått för cacheminnet för att se om det finns en korrelation mellan när nyckeln saknades och en topp i avlägsnade nycklar. Information om hur du använder keyspace-meddelanden eller MONITOR för att felsöka dessa typer av problem finns i tillägget för felsökning av Redis Keyspace-fel.

Borttagning av nyckel

Redis-klienter kan utfärda KOMMANDOT DEL eller HDEL för att uttryckligen ta bort nycklar från Azure Cache for Redis. Du kan spåra antalet borttagningsåtgärder med hjälp av info-kommandot. Om DEL- eller HDEL-kommandon har anropats visas de i Commandstats avsnittet .

# Commandstats

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

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

Asynkron replikering

Alla Azure Cache for Redis på standard- eller Premium-nivån konfigureras med en primär nod och minst en replik. Data kopieras från den primära till en replik asynkront med hjälp av en bakgrundsprocess. Webbplatsen redis.io beskriver hur Redis-datareplikering fungerar i allmänhet. I scenarier där klienter ofta skriver till Redis kan partiell dataförlust inträffa eftersom den här replikeringen inte är garanterad att ske omedelbart. Om den primära till exempel ligger nere efter att en klient skriver en nyckel till den, men innan bakgrundsprocessen har möjlighet att skicka nyckeln till repliken, går nyckeln förlorad när repliken tar över som den nya primära.

Större eller fullständig förlust av nycklar

Om de flesta eller alla nycklar har försvunnit från cacheminnet kontrollerar du följande möjliga orsaker:

Nyckel flushing

Klienter kan anropa FLUSHDB-kommandot för att ta bort alla nycklar i en enkel databas eller FLUSHALL för att ta bort alla nycklar från alla databaser i en Redis-cache. Om du vill ta reda på om nycklarna har rensats använder du info-kommandot. Avsnittet Commandstats visar om endera FLUSH-kommandot har anropats:

# Commandstats

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

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

Felaktigt val av databas

Azure Cache for Redis använder db0-databasen som standard. Om du växlar till en annan databas (till exempel db1) och försöker läsa nycklar från den Azure Cache for Redis inte hitta dem där. Varje databas är en logiskt separat enhet och innehåller en annan datauppsättning. Använd kommandot SELECT för att använda andra tillgängliga databaser och leta efter nycklar i var och en av dem.

Redis-instansfel

Redis är ett minnes minnesutrymme. Data sparas på de fysiska eller virtuella datorer som är värdar för Redis-cachen. En Azure Cache for Redis-instans på Basic-nivån körs bara på en enda virtuell dator (VM). Om den virtuella datorn är nere går alla data som du har lagrat i cacheminnet förlorade.

Cacheminnen på nivåerna Standard och Premium ger mycket högre återhämtning vid dataförlust genom att använda två virtuella datorer i en replikerad konfiguration. När den primära noden i en sådan cache misslyckas tar repliknoden över för att betjäna data automatiskt. Dessa virtuella datorer finns på separata domäner för fel och uppdateringar, för att minimera risken för att båda blir otillgängliga samtidigt. Men om ett större datacenteravbrott inträffar kan de virtuella datorerna fortfarande gå ned tillsammans. Dina data går förlorade i dessa sällsynta fall.

Överväg att använda Redis datapersistence och geo-replikering för att förbättra skyddet av dina data mot dessa infrastrukturfel.

Ytterligare information

• Felsöka problem på Azure Cache for Redis-serversidan
• Välja rätt nivå
• Övervaka Azure Cache for Redis
• Hur kör jag Redis-kommandon?