Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
In dit artikel wordt beschreven hoe u werkelijke of waargenomen gegevensverlies kunt diagnosticeren die kunnen optreden in Azure Managed Redis.
Opmerking
Verschillende van de stappen voor probleemoplossing in deze handleiding bevatten instructies voor het uitvoeren van Redis-opdrachten en het bewaken van verschillende prestatiegegevens. Zie de artikelen in de gerelateerde inhoud voor meer informatie en instructies.
Gedeeltelijk verlies van sleutels
Azure Managed 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 via de CLI.
Sleutels die naar het primaire knooppunt in een Azure Managed Redis-exemplaar zijn geschreven, zijn mogelijk ook niet meteen 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 | Beschrijving |
---|---|
Verlooptijd van sleutel | Sleutels worden verwijderd vanwege de 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. |
Verlooptijd van sleutel
Azure Managed Redis verwijdert automatisch een sleutel als aan de sleutel een time-out is toegewezen en die periode is verstreken. Raadpleeg de documentatie van het EXPIRE-commando voor meer informatie over het vervallen van Redis-sleutels. Time-outwaarden kunnen ook worden ingesteld door de SET, SETEX, GETSET en andere *STORE opdrachten te gebruiken.
Gebruik de opdracht INFO om statistieken te verkrijgen van het aantal verlopen sleutels. In Stats
de sectie wordt het totale aantal verlopen sleutels weergegeven. De Keyspace
sectie bevat 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 de diagnostische metrische gegevens voor uw cache onderzoeken om te zien of er een correlatie is tussen wanneer de sleutel ontbreekt en een piek in verwijderde sleutels.
Sleutelverwijdering
Azure Managed Redis vereist geheugenruimte om gegevens op te slaan. Er worden sleutels verwijderd om het beschikbare geheugen vrij te maken wanneer dat nodig is. Wanneer de waarden used_memory of used_memory_rss in de INFO opdracht de geconfigureerde maxmemory instelling benaderen, begint Azure Managed Redis sleutels uit het geheugen te verwijderen op basis van het cachebeleid.
U kunt het aantal verwijderde sleutels controleren met behulp van de opdracht INFO :
# Stats
evicted_keys:13224
Sleutelverwijdering
Redis-clients kunnen de opdracht DEL of HDEL uitgeven om expliciet sleutels uit Azure Managed Redis te verwijderen. 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
Een Beheerd Redis-exemplaar van Azure waarvoor hoge beschikbaarheid is ingeschakeld, 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. De redis.io-website beschrijft hoe Redis-gegevensreplicatie in het algemeen werkt. Voor scenario's waarbij clients vaak naar Redis schrijven, kan gedeeltelijk gegevensverlies optreden omdat replicatie niet gegarandeerd onmiddellijk kan zijn. Als de primaire server bijvoorbeeld uitvalt nadat een client er een sleutel naar schrijft, maar voordat het achtergrondproces de kans heeft om die sleutel naar de replica te verzenden, gaat de sleutel verloren wanneer de replica overneemt als de nieuwe primaire server.
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 | Beschrijving |
---|---|
Sleutel leegmaken | Sleutels zijn handmatig verwijderd. |
Fout in Redis-instantie | De Redis-server is niet beschikbaar. |
Sleutel leegmaken
Clients kunnen de opdracht FLUSHDB of FLUSHALL aanroepen om alle sleutels uit het Redis-exemplaar te verwijderen. Als u wilt weten of sleutels zijn geflusht, gebruikt u de INFO opdracht. In Commandstats
de sectie ziet u of een van beide 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
Fout in Redis-instantie
Redis is een gegevensarchief in het geheugen. Gegevens worden bewaard op de fysieke of virtuele machines (VM) die als host fungeren voor de Redis-cache. Azure Managed Redis-caches bieden hoge tolerantie tegen gegevensverlies door standaard Zone Resilient-caches te bieden. Wanneer de primaire shard in een dergelijke cache uitvalt, neemt de replica-shard automatisch gegevens over. 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 mogelijk nog steeds samen omlaag gaan. In deze zeldzame gevallen gaan uw gegevens verloren.
Overweeg redis-gegevenspersistentie en geo-replicatie te gebruiken om de beveiliging van uw gegevens te verbeteren tegen deze infrastructuurfouten.