Problembehandlung bei Datenverlusten in Azure Managed Redis (Vorschau)
In diesem Artikel wird erläutert, wie Sie tatsächliche oder vermeintliche Datenverluste diagnostizieren, die in Azure Managed Redis (Vorschau) auftreten können.
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 Managed 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 über die CLIausführen.
Schlüssel, die in den primären Knoten in einer Azure Managed Redis-Instanz geschrieben wurden, sind möglicherweise auch nicht sofort für ein 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 Managed Redis entfernt einen Schlüssel automatisch, wenn dem Schlüssel ein Timeout zugewiesen und dieser 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 Managed Redis benötigt Arbeitsspeicher, um Daten zu speichern. Es löscht bei Bedarf Schlüssel, um verfügbaren Speicher freizugeben. Wenn sich die Werte von used_memory oder used_memory_rss im Befehl INFO dem für die Einstellung maxmemory konfigurierten Wert nähert, beginnt Azure Managed Redis basierend auf 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 Managed 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 Managed Redis-Instanz mit aktivierter Hochverfügbarkeit ist 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. |
| Redis-Instanzausfall | Der Redis-Server ist nicht verfügbar. |
Leeren von Schlüsseln
Clients können den Befehl FLUSHDB oder FLUSHALL aufrufen, um alle Schlüssel aus der Redis-Instanz zu entfernen. 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
Redis-Instanzausfall
Redis ist ein In-Memory-Datenspeicher. Daten verbleiben auf dem physischen oder virtuellen Computer (der VM), auf dem der Redis-Cache gehostet wird. Azure Managed Redis-Caches bieten eine hohe Resilienz gegenüber Datenverlust, indem standardmäßig zonenresiliente Caches bereitgestellt werden. Wenn der primäre Shard für einen solchen Cache ausfällt, übernimmt der Replikatshard automatisch die Verarbeitung 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 VMs 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: