Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
In diesem Artikel wird erläutert, wie Sie partielle oder vollständige Datenverluste diagnostizieren, die im Azure-Cache für Redis auftreten.
Von Bedeutung
Azure Cache for Redis hat den Auslaufzeitplan für alle SKUs angekündigt. Es wird empfohlen, Ihren vorhandenen Azure-Cache für Redis-Instanzen in Azure Managed Redis zu verschieben, sobald Möglich.
Weitere Informationen zur Einstellung finden Sie unter:
Teilweiser Schlüsselverlust
Azure Cache für Redis löscht Schlüssel nach dem Speichern im Arbeitsspeicher nicht zufällig, entfernt jedoch Schlüssel als Reaktion auf Ablaufrichtlinien, Löschrichtlinien und explizite Befehle zum Löschen von Schlüsseln. Sie können diese Befehle auf der Konsole oder über die Redis CLI ausführen.
Schlüssel, die in den primären Knoten in einer Premium- oder Standard Azure Redis-Instanz geschrieben wurden, sind möglicherweise nicht sofort in einem Replikat verfügbar. Daten werden von der primären in das Replikat auf asynchrone und nicht blockierende Weise repliziert.
Wenn einige Schlüssel aus dem Cache verschwinden, überprüfen Sie die folgenden möglichen Ursachen:
| Ursache | BESCHREIBUNG |
|---|---|
| Ablauf von Schlüsseln | Schlüssel wurden entfernt, weil für sie Timeouts festgelegt wurden. |
| Entfernen von Schlüsseln | Schlüssel wurden bei hoher Arbeitsspeicherauslastung entfernt. |
| Löschen von Schlüsseln | Schlüssel wurden durch explizite Löschbefehle entfernt. |
| Asynchrone Replikation | Schlüssel waren aufgrund von Datenreplikationsverzögerungen für ein Replikat nicht verfügbar. |
Ablauf von Schlüsseln
Azure Cache für Redis entfernt automatisch einen Schlüssel, wenn dem Schlüssel ein Timeout zugewiesen ist und dieser Zeitraum verstrichen ist. Weitere Informationen zum Ablauf von Redis-Schlüsseln finden Sie in der Dokumentation des Redis-Befehls EXPIRE. Timeoutwerte können auch mithilfe von SET, SETEX, GETSET und anderen *STORE Befehlen festgelegt werden.
Verwenden Sie den Befehl INFO , um Statistiken darüber zu erhalten, wie viele Tasten abgelaufen sind. Im Abschnitt Stats wird die Gesamtzahl abgelaufener Schlüssel angezeigt. Der Keyspace Abschnitt enthält weitere Informationen zur Anzahl der Schlüssel mit Timeouts und dem durchschnittlichen Timeoutwert.
# Stats
expired_keys:46583
# Keyspace
db0:keys=3450,expires=2,avg_ttl=91861015336
Entfernen von Schlüsseln
Azure Cache for Redis erfordert Speicherplatz zum Speichern von Daten und löscht Schlüssel, um bei Bedarf verfügbaren Speicher freizugeben. Wenn die used_memory oder used_memory_rss Werte sich der konfigurierten maxmemory Einstellung nähern, beginnt Azure Redis damit, Schlüssel gemäß der Cache-Richtlinie aus dem Speicher zu entfernen.
Mit dem Befehl INFO können Sie die Anzahl der entfernten Schlüssel überwachen.
# Stats
evicted_keys:13224
Löschen von Schlüsseln
Redis-Clients können die Befehle "Redis DEL" oder "HDEL " ausstellen, um Schlüssel explizit aus Azure Redis zu entfernen. Mit dem Befehl INFO können Sie die Anzahl der Löschvorgänge verfolgen. Wenn DEL oder HDEL Befehle aufgerufen wurden, werden sie im Commandstats Abschnitt aufgeführt.
# Commandstats
cmdstat_del:calls=2,usec=90,usec_per_call=45.00
cmdstat_hdel:calls=1,usec=47,usec_per_call=47.00
Asynchrone Replikation
Der Standard- oder Premium-Azure-Cache für Redis-Instanzen wird mit einem primären Knoten und mindestens einem Replikat konfiguriert. Daten werden in einem Hintergrundprozess asynchron vom primären Knoten in ein Replikat kopiert.
Die Redis-Replikation auf der Redis-Website beschreibt, wie Die Redis-Datenreplikation im Allgemeinen funktioniert. In Szenarien, in denen Clients häufig in Redis schreiben, kann ein teilweiser Datenverlust auftreten, da die Replikation nicht sofort konzipiert ist.
Wenn beispielsweise der Primärserver ausfällt, nachdem ein Client einen Schlüssel darauf geschrieben hat, aber bevor der Hintergrundprozess die Möglichkeit hat, diesen Schlüssel an das Replikat zu senden, geht der Schlüssel verloren, wenn das Replikat als neuer Primärserver übernommen wird.
Vollständiger Schlüsselverlust
Wenn die meisten oder alle Schlüssel aus Dem Cache verschwinden, überprüfen Sie die folgenden möglichen Ursachen:
| Ursache | BESCHREIBUNG |
|---|---|
| Leeren von Schlüsseln | Schlüssel wurden manuell gelöscht. |
| Falsche Datenbankauswahl | Azure Redis ist auf die Verwendung einer nicht standardmäßigen Datenbank festgelegt. |
| Redis-Instanzausfall | Der Redis-Server ist nicht verfügbar. |
Leeren von Schlüsseln
Azure Redis-Clients können den Befehl Redis FLUSHDB aufrufen, um alle Schlüssel in einer einzelnen Datenbank oder FLUSHALL zu entfernen, um alle Schlüssel aus allen Datenbanken in einem Redis-Cache zu entfernen. Um herauszufinden, ob Tasten geleert wurden, verwenden Sie den Befehl INFO . Der Commandstats Abschnitt zeigt an, ob beide FLUSH Befehle aufgerufen wurden.
# Commandstats
cmdstat_flushall:calls=2,usec=112,usec_per_call=56.00
cmdstat_flushdb:calls=1,usec=110,usec_per_call=52.00
Falsche Datenbankauswahl
Jede Datenbank ist eine logisch separate Einheit und enthält ein anderes Dataset. Azure Cache for Redis verwendet standardmäßig die Datenbank db0. Wenn Sie zu einer anderen Datenbank wechseln, z db1 . B. und versuchen, Schlüssel daraus zu lesen, findet Azure Redis sie nicht. Verwenden Sie den Befehl "Redis SELECT ", um nach Schlüsseln in anderen verfügbaren Datenbanken zu suchen.
Redis-Instanzausfall
Redis speichert Daten im Arbeitsspeicher auf den physischen oder virtuellen Computern (VMs), die den Redis-Cache hosten. Eine Basic-Tier Azure Cache for Redis-Instanz wird nur auf einer einzigen virtuellen Maschine (VM) ausgeführt. Wenn dieser virtuelle Computer heruntergeht, gehen alle Daten, die Sie im Cache gespeichert haben, verloren.
Caches in den Ebenen "Standard" und "Premium" bieten eine höhere Resilienz gegenüber Datenverlust, indem zwei virtuelle Computer in einer replizierten Konfiguration verwendet werden. Wenn der primäre Knoten für einen solchen Cache ausfällt, übernimmt der Replikatknoten automatisch die Bereitstellung der Daten.
Diese virtuellen Computer befinden sich in separaten Domänen für Fehler und Updates, um die Wahrscheinlichkeit zu minimieren, dass beide virtuellen Computer gleichzeitig nicht verfügbar sind. Wenn jedoch ein großer Rechenzentrumsausfall auftritt, können beide VMs ausfallen. In diesen seltenen Fällen gehen Ihre Daten verloren. Erwägen Sie die Verwendung von Datenpersistenz und georeplikation , um den Datenschutz vor Infrastrukturfehlern zu verbessern.