Problemen met gegevensverlies in Azure Cache voor Redis oplossen
In dit artikel wordt beschreven hoe u een diagnose kunt stellen van werkelijk of vermeend gegevensverlies dat kan optreden in Azure Cache voor Redis.
Notitie
Een aantal van de stappen voor probleemoplossing in deze handleiding bevat instructies voor het uitvoeren van Redis-opdrachten en het bewaken van verschillende metrische prestatiegegevens. Zie de artikelen in de sectie Aanvullende informatie voor meer informatie en instructies.
Gedeeltelijk verlies van sleutels
Azure Cache voor Redis verwijdert sleutels niet willekeurig nadat ze in het geheugen zijn opgeslagen. Sleutels worden echter wel verwijderd als reactie op verloopbeleid, verwijderingsbeleid en expliciete opdrachten voor het verwijderen van sleutels. U kunt deze opdrachten uitvoeren op de console of via de CLI.
Sleutels die naar het primaire knooppunt in een Premium- of Standard-Azure Cache voor Redis-exemplaar zijn geschreven, zijn mogelijk niet direct beschikbaar op een replica. Gegevens worden op een asynchrone en niet-blokkerende manier van de primaire naar de replica gerepliceerd.
Als u merkt dat sleutels uit uw cache zijn verdwenen, controleert u de volgende mogelijke oorzaken:
| Oorzaak | Description |
|---|---|
| Sleutelverlooptijd | Sleutels worden verwijderd vanwege time-outs die erop zijn ingesteld. |
| Sleutelverwijdering | Sleutels worden verwijderd onder geheugendruk. |
| Sleutelverwijdering | Sleutels worden verwijderd door expliciete verwijderopdrachten. |
| Asynchrone replicatie | Sleutels zijn niet beschikbaar op een replica vanwege vertragingen bij gegevensreplicatie. |
Sleutelverlooptijd
Azure Cache voor Redis verwijdert een sleutel automatisch als aan de sleutel een time-out is toegewezen en die periode is verstreken. Zie de documentatie voor de opdracht EXPIRE voor meer informatie over het verlopen van redis-sleutels. Time-outwaarden kunnen ook worden ingesteld met behulp van de opdrachten SET, SETEX, GETSET en andere *STORE-opdrachten.
Als u statistieken wilt ophalen over het aantal sleutels dat is verlopen, gebruikt u de opdracht INFO . In Stats de sectie wordt het totale aantal verlopen sleutels weergegeven. De Keyspace sectie biedt meer informatie over het aantal sleutels met time-outs en de gemiddelde time-outwaarde.
# Stats
expired_keys:46583
# Keyspace
db0:keys=3450,expires=2,avg_ttl=91861015336
U kunt ook de diagnostische metrische gegevens voor uw cache bekijken om te zien of er een verband is tussen het moment waarop de sleutel ontbreekt en een piek in verlopen sleutels. Zie de bijlage bij foutopsporing in Redis Keyspace Misses voor informatie over het gebruik van keyspace meldingen of MONITOR voor het opsporen van fouten in dit soort problemen.
Sleutelverwijdering
Azure Cache voor Redis vereist geheugenruimte om gegevens op te slaan. Sleutels worden gewist om beschikbaar geheugen vrij te maken wanneer dat nodig is. Wanneer de used_memory of used_memory_rss waarden in de opdracht INFO de geconfigureerde instelling maxmemory benaderen, begint Azure Cache voor Redis sleutels uit het geheugen te verwijderen op basis van cachebeleid.
U kunt het aantal verwijderde sleutels controleren met behulp van de opdracht INFO :
# Stats
evicted_keys:13224
U kunt ook diagnostische metrische gegevens voor uw cache bekijken om te zien of er een verband is tussen het moment waarop de sleutel ontbreekt en een piek in verwijderde sleutels. Zie de bijlage met foutopsporing in Redis Keyspace Misses voor informatie over het gebruik van keyspace-meldingen of MONITOR om dit soort problemen op te sporen.
Sleutelverwijdering
Redis-clients kunnen de DEL- of HDEL-opdracht geven om sleutels expliciet te verwijderen uit Azure Cache voor Redis. U kunt het aantal verwijderbewerkingen bijhouden met behulp van de opdracht INFO . Als DEL - of HDEL-opdrachten zijn aangeroepen, worden deze weergegeven in de Commandstats sectie.
# Commandstats
cmdstat_del:calls=2,usec=90,usec_per_call=45.00
cmdstat_hdel:calls=1,usec=47,usec_per_call=47.00
Asynchrone replicatie
Elk Azure Cache voor Redis exemplaar in de Standard- of Premium-laag wordt geconfigureerd met een primair knooppunt en ten minste één replica. Gegevens worden asynchroon gekopieerd van de primaire naar een replica met behulp van een achtergrondproces. Op de website redis.io wordt beschreven hoe Redis-gegevensreplicatie in het algemeen werkt. In scenario's waarin clients vaak naar Redis schrijven, kan gedeeltelijk gegevensverlies optreden omdat replicatie niet gegarandeerd onmiddellijk plaatsvindt. Als de primaire sleutel bijvoorbeeld uitvalt nadat een client een sleutel naar de replica heeft geschreven, maar voordat het achtergrondproces de kans krijgt om die sleutel naar de replica te verzenden, gaat de sleutel verloren wanneer de replica het overneemt als de nieuwe primaire.
Groot of volledig verlies van sleutels
Als u merkt dat de meeste of alle sleutels uit uw cache zijn verdwenen, controleert u de volgende mogelijke oorzaken:
| Oorzaak | Description |
|---|---|
| Sleutel leegmaken | Sleutels zijn handmatig opgeschoond. |
| Onjuiste databaseselectie | Azure Cache voor Redis is ingesteld op het gebruik van een niet-standaarddatabase. |
| Fout in Redis-exemplaar | De Redis-server is niet beschikbaar. |
Sleutel leegmaken
Clients kunnen de opdracht FLUSHDB aanroepen om alle sleutels in één database te verwijderen of FLUSHALL om alle sleutels uit alle databases in een Redis-cache te verwijderen. Als u wilt weten of de sleutels zijn leeggemaakt, gebruikt u de opdracht INFO . In Commandstats de sectie ziet u of een van de FLUSH opdrachten is aangeroepen:
# Commandstats
cmdstat_flushall:calls=2,usec=112,usec_per_call=56.00
cmdstat_flushdb:calls=1,usec=110,usec_per_call=52.00
Onjuiste databaseselectie
Azure Cache voor Redis maakt standaard gebruik van de db0 database. Als u overschakelt naar een andere database (bijvoorbeeld db1) en sleutels probeert te lezen, vindt Azure Cache voor Redis deze daar niet. Elke database is een logisch gescheiden eenheid en bevat een andere gegevensset. Gebruik de opdracht SELECT om andere beschikbare databases te gebruiken en te zoeken naar sleutels in elk van deze databases.
Fout in Redis-exemplaar
Redis is een gegevensarchief in het geheugen. Gegevens worden bewaard op de fysieke of virtuele machines die als host fungeren voor de Redis-cache. Een Azure Cache voor Redis-exemplaar in de Basic-laag wordt uitgevoerd op slechts één virtuele machine (VM). Als die VM niet beschikbaar is, gaan alle gegevens die u in de cache hebt opgeslagen, verloren.
Caches in de lagen Standard en Premium bieden een veel hogere tolerantie tegen gegevensverlies door gebruik te maken van twee VM's in een gerepliceerde configuratie. Wanneer het primaire knooppunt in een dergelijke cache uitvalt, neemt het replicaknooppunt het over om gegevens automatisch te leveren. Deze VM's bevinden zich in afzonderlijke domeinen voor fouten en updates, om de kans te minimaliseren dat beide gelijktijdig niet beschikbaar zijn. Als er echter een grote storing in het datacenter optreedt, kunnen de VM's nog steeds samen uitvallen. In deze zeldzame gevallen gaan uw gegevens verloren.
Overweeg het gebruik van Redis-gegevenspersistentie en geo-replicatie om de beveiliging van uw gegevens tegen deze infrastructuurfouten te verbeteren.
Aanvullende informatie
Deze artikelen bieden meer informatie over het voorkomen van gegevensverlies: