Anmerkung
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 tatsächliche oder wahrgenommene Datenverluste diagnostizieren, die in azure Managed Redis auftreten können.
Hinweis
Einige Schritte zur Problembehandlung in diesem Handbuch umfassen Anweisungen zum Ausführen von Redis-Befehlen und zum Überwachen von Leistungsmetriken. Weitere Informationen finden Sie in den Artikeln zu verwandten Inhalten.
Partieller Verlust von Schlüsseln
Azure Managed Redis löscht schlüssel nicht zufällig, nachdem sie im Speicher gespeichert wurden. Sie entfernt Schlüssel aufgrund von Ablaufrichtlinien, Löschrichtlinien oder expliziten Befehlen zum Löschen von Schlüsseln. Führen Sie diese Befehle mithilfe der CLI aus. Schlüssel, die in den primären Knoten in einer Azure Managed Redis-Instanz geschrieben wurden, sind möglicherweise nicht sofort für ein Replikat verfügbar. Daten werden asynchron und nicht blockiert von der primären in das Replikat repliziert.
Wenn Schlüssel aus Dem Cache verschwinden, überprüfen Sie die folgenden möglichen Ursachen:
| Ursache | BESCHREIBUNG |
|---|---|
| Ablauf von Schlüsseln | Schlüssel werden aufgrund von timeouts entfernt, die für sie festgelegt sind. |
| Entfernen von Schlüsseln | Schlüssel werden entfernt, wenn der Arbeitsspeicher niedrig ist. |
| Löschen von Schlüsseln | Clients entfernen Schlüssel, indem sie explizite Löschbefehle ausführen. |
| Asynchrone Replikation | Schlüssel sind aufgrund von Verzögerungen bei der Datenreplikation für ein Replikat nicht verfügbar. |
Ablauf von Schlüsseln
Azure Managed Redis entfernt automatisch einen Schlüssel, wenn das Timeout für diesen Schlüssel übergeben wird. Weitere Informationen zum Ablauf von Redis-Schlüsseln finden Sie in der Dokumentation des Befehls EXPIRE. Sie können auch Timeoutwerte festlegen, indem Sie die BEFEHLE SET, SETEX, GETSET und andere *STORE-Befehle verwenden.
Verwenden Sie den Befehl INFO , um zu sehen, 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
Überprüfen Sie die Diagnosemetriken für Ihren Cache, um festzustellen, ob eine Korrelation zwischen dem Fehlen des Schlüssels und einer Spitzen in den gelöschten Schlüsseln besteht.
Entfernen von Schlüsseln
Azure Managed Redis benötigt Speicherplatz zum Speichern von Daten. Es entfernt Schlüssel, um Arbeitsspeicher bei Bedarf 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.
Überwachen Sie die Anzahl der ausgestuften Tasten mithilfe des Befehls INFO :
# Stats
evicted_keys:13224
Löschen von Schlüsseln
Redis-Clients führen den BEFEHL DEL oder HDEL aus, um Schlüssel aus Azure Managed Redis zu entfernen. Verfolgen Sie die Anzahl der Löschvorgänge mithilfe des Befehls INFO . Wenn DEL- oder HDEL-Befehle ausgeführt 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
Wenn Sie hohe Verfügbarkeit in Azure Managed Redis aktivieren, erstellt der Dienst einen primären Knoten und mindestens ein Replikat. Das System kopiert Daten aus der primären Daten asynchron mithilfe eines Hintergrundprozesses in das Replikat. Weitere Details finden Sie in der Redis-Replikationsdokumentation .
Da die Replikation nicht sofort erfolgt, treten möglicherweise teilweise Datenverluste auf, wenn Clients häufig in Redis schreiben. Wenn beispielsweise der primäre Knoten fehlschlägt, nachdem ein Client einen Schlüssel schreibt, aber bevor der Hintergrundprozess repliziert wird, geht der Schlüssel verloren, wenn das Replikat zur neuen primären Wird.
Größerer oder kompletter Verlust von Schlüsseln
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 | Jemand hat die Schlüssel 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. Verwenden Sie den Befehl INFO , um zu überprüfen, ob Die Tasten geleert werden. Der Commandstats Abschnitt zeigt, ob beide FLUSH Befehle ausgeführt werden:
# 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 den physischen oder virtuellen Computern (VM), die den Redis-Cache hosten. Azure Managed Redis Caches bieten eine hohe Ausfallsicherheit gegenüber Datenverlust, indem zonenresiliente Caches standardmäßig bereitgestellt werden. Wenn der primäre Shard in diesem Cache fehlschlägt, übernimmt der Replikatshard automatisch die Daten. Diese virtuellen Computer befinden sich in separaten Domänen für Fehler und Updates, wodurch die Wahrscheinlichkeit minimiert wird, dass beide gleichzeitig nicht verfügbar werden. Wenn ein großer Rechenzentrumsausfall auftritt, können die virtuellen Computer weiterhin zusammengehen. In diesen seltenen Fällen verlieren Sie Ihre Daten.
Verwenden Sie Redis-Datenpersistenz und Georeplikation , um Ihre Daten besser vor diesen Infrastrukturfehlern zu schützen.