Problembehandlung bei Datenverlust in Azure Cache for Redis
In diesem Artikel wird erläutert, wie Sie tatsächliche oder erkannte Datenverluste, die in Azure Cache for Redis auftreten können, diagnostizieren.
Hinweis
Etliche Problembehandlungsschritte in diesem Leitfaden enthalten Anleitungen zum Ausführen von Redis-Befehlen und zum Überwachen verschiedener Leistungsmetriken. Weitere Informationen und Anleitungen finden Sie in den Artikeln im Abschnitt Weitere Informationen .
Partieller Verlust von Schlüsseln
Azure Cache for Redis löscht Schlüssel nicht nach dem Zufallsprinzip, nachdem sie im Arbeitsspeicher gespeichert wurden. Schlüssel werden jedoch als Reaktion auf Ablauf- oder Entfernungsrichtlinien sowie auf explizite Befehle zum Löschen von Schlüsseln entfernt. Sie können diese Befehle in der Konsole oder über die CLI ausführen.
Auch sind Schlüssel, die in den primären Knoten in einer Azure Cache for Redis-Instanz (Tarif „Standard“ oder „Premium“) geschrieben wurden, möglicherweise nicht sofort auf einem Replikat verfügbar. Daten werden asynchron und auf nicht blockierende Weise vom primären Knoten auf dem Replikat repliziert.
Wenn Sie feststellen, dass Schlüssel aus dem Cache verschwunden sind, sollten Sie auf folgende mögliche Ursachen prüfen:
| Ursache | BESCHREIBUNG |
|---|---|
| Ablauf von Schlüsseln | Schlüssel werden entfernt, weil für sie Timeouts festgelegt wurden. |
| Entfernen von Schlüsseln | Schlüssel werden bei hoher Arbeitsspeicherauslastung entfernt. |
| Löschen von Schlüsseln | Schlüssel werden durch explizite Löschbefehle entfernt. |
| Asynchrone Replikation | Schlüssel sind aufgrund von Verzögerungen bei der Datenreplikation auf einem Replikat nicht verfügbar. |
Ablauf von Schlüsseln
Azure Cache for Redis entfernt einen Schlüssel automatisch, wenn dem Schlüssel ein Timeout zugewiesen und der zugehörige Zeitraum abgelaufen ist. Weitere Informationen zum Ablauf von Redis-Schlüsseln finden Sie in der Dokumentation des Befehls EXPIRE. Timeoutwerte können auch über die Befehle SET, SETEX und GETSET sowie weitere *STORE-Befehle festgelegt werden.
Wenn Sie Statistiken abrufen möchten, wie viele Schlüssel abgelaufen sind, verwenden Sie den Befehl INFO. Im Abschnitt Stats wird die Gesamtzahl abgelaufener Schlüssel angezeigt. Der Abschnitt Keyspace enthält weitere Informationen zur Anzahl der Schlüssel mit Timeouts und zum durchschnittlichen Timeoutwert.
# Stats
expired_keys:46583
# Keyspace
db0:keys=3450,expires=2,avg_ttl=91861015336
Außerdem können Sie die Diagnosemetriken für Ihren Cache überprüfen, um festzustellen, ob es eine Korrelation zwischen dem fehlendem Schlüssel und einer Spitze bei den abgelaufenen Schlüsseln gibt. Im Anhang von Debuggen von Redis-Keyspace-Fehlern finden Sie Informationen zum Debuggen derartiger Probleme mithilfe von keyspace-Benachrichtigungen bzw. MONITOR.
Entfernen von Schlüsseln
Azure Cache for Redis benötigt Arbeitsspeicher, um Daten zu speichern. Es löscht bei Bedarf Schlüssel, um verfügbaren Speicher freizugeben. Wenn sich der Wert von used_memory oder used_memory_rss im Befehl INFO dem für die Einstellung maxmemory konfigurierten Wert nähert, beginnt Azure Cache for Redis aufgrund der Cacherichtlinie mit dem Entfernen von Schlüsseln.
Mit dem Befehl INFO können Sie die Anzahl der entfernten Schlüssel überwachen.
# Stats
evicted_keys:13224
Außerdem können Sie die Diagnosemetriken für Ihren Cache überprüfen, um festzustellen, ob es eine Korrelation zwischen dem fehlendem Schlüssel und einer Spitze bei den entfernten Schlüsseln gibt. Im Anhang von Debugging Redis Keyspace Misses finden Sie unter „Keyspace Notifications“ Informationen zur Verwendung von Keyspace-Benachrichtigungen sowie unter MONITOR Informationen, wie Probleme dieses Typs debuggt werden.
Löschen von Schlüsseln
Redis-Clients können den Befehl DEL oder HDEL ausgeben, um Schlüssel explizit aus Azure Cache for Redis zu entfernen. Mit dem Befehl INFO können Sie die Anzahl der Löschvorgänge verfolgen. Aufrufe von DEL- oder HDEL-Befehlen werden im Abschnitt Commandstats aufgelistet.
# 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
Jede Azure Cache for Redis-Instanz ist sowohl im Tarif „Standard“ als auch im Tarif „Premium“ mit einem primären Knoten und mindestens einem Replikat konfiguriert. Daten werden in einem Hintergrundprozess asynchron vom primären Knoten in ein Replikat kopiert. Auf der Website redis.io wird beschrieben, wie die Redis-Datenreplikation im Allgemeinen funktioniert. In Szenarien, in denen Clients häufig in Redis schreiben, kann ein partieller Datenverlust auftreten, weil nicht garantiert werden kann, dass diese Replikation sofort ausgeführt wird. Wenn beispielsweise der primäre Knoten heruntergefahren wird, nachdem ein Client einen Schlüssel in den Knoten geschrieben hat, aber bevor der Hintergrundprozess die Möglichkeit hatte, diesen Schlüssel an das Replikat zu senden, geht der Schlüssel verloren, wenn das Replikat als neuer primärer Knoten verwendet wird.
Größerer oder kompletter Verlust von Schlüsseln
Sind die meisten oder alle Schlüssel aus dem Cache verschwunden, sollten Sie auf folgende mögliche Ursachen prüfen:
| Ursache | BESCHREIBUNG |
|---|---|
| Leeren von Schlüsseln | Schlüssel wurden manuell gelöscht. |
| Falsche Datenbankauswahl | Azure Cache for Redis ist so festgelegt, dass eine Nicht-Standarddatenbank verwendet wird. |
| Redis-Instanzausfall | Der Redis-Server ist nicht verfügbar. |
Leeren von Schlüsseln
Clients können den Befehl FLUSHDB aufrufen, um alle Schlüssel in einer einzelnen Datenbank zu entfernen. Mit dem Befehl FLUSHALL werden alle Schlüssel aus allen Datenbanken in einem Redis-Cache entfernt. Wenn Sie feststellen möchten, ob Schlüssel geleert (entfernt) wurden, verwenden Sie den Befehl INFO. Im Commandstats-Abschnitt ist zu sehen, ob 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
Azure Cache for Redis verwendet standardmäßig die Datenbank db0. Wenn Sie zu einer anderen Datenbank wechseln (z. B. db1) und versuchen, Schlüssel aus ihr zu lesen, kann Azure Cache for Redis dort keine Schlüssel finden. Jede Datenbank ist eine logisch separate Einheit und enthält ein anderes Dataset. Wählen Sie mit dem Befehl SELECT andere verfügbare Datenbanken aus, und suchen Sie dort jeweils nach Schlüsseln.
Redis-Instanzausfall
Redis ist ein In-Memory-Datenspeicher. Daten verbleiben auf dem physischen oder virtuellen Computer, auf dem der Redis-Cache gehostet wird. Eine Azure Cache for Redis-Instanz im Tarif „Basic“ wird nur auf einem einzelnen virtuellen Computer (VM) ausgeführt. Wenn dieser virtuelle Computer ausfällt, gehen alle Daten verloren, die Sie im Cache gespeichert haben.
Caches der Tarife „Standard“ und „Premium“ bieten eine wesentlich höhere Resilienz vor Datenverlusten, da 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 getrennten Domänen für Ausfälle und Updates, um das Risiko zu minimieren, dass beide gleichzeitig nicht verfügbar sind. Kommt es zu einem größeren Ausfall des Rechenzentrums, können die virtuellen Computer dennoch gemeinsam ausfallen. In diesen seltenen Fällen gehen Ihre Daten verloren.
Um dies zu verhindern, können Sie Redis-Datenpersistenz und Georeplikation verwenden, um den Schutz Ihrer Daten vor derartigen Infrastrukturausfällen zu erhöhen.
Zusätzliche Informationen
Diese Artikel enthalten weitere Informationen zum Vermeiden von Datenverlusten: