Freigeben über

Konfigurieren der Datenpersistenz für eine Azure Managed Redis (Vorschau)-Instanz

  • Artikel

Redis-Persistenz ermöglicht die persistente Speicherung von Daten, die in der Cache-Instanz gespeichert sind. Im Falle eines Hardwarefehlers wird die Cache-Instanz mit Daten aus der Persistenzdatei aktiviert, wenn die Instanz wieder online ist. Die persistente Speicherung von Daten ist eine wichtige Maßnahme zur Erhöhung der Dauerhaftigkeit einer Cache-Instanz, da alle Cachedaten im Arbeitsspeicher gespeichert werden. Sollte ein Fehler auftreten, wenn Cacheknoten ausgefallen sind, können Daten verloren gehen. Persistenz sollte ein wichtiger Aspekt Ihrer Strategie für Hochverfügbarkeit und Notfallwiederherstellung mit Azure Managed Redis (Vorschau) sein.

Wichtig

Die Datenpersistenz soll eine Resilienz für unerwartete Redis-Knotenfehler bereitstellen, es handelt sich jedoch nicht um eine Datensicherung oder ein Time Recovery-Feature (PITR). Wenn beschädigte Daten in die Redis-Instanz geschrieben werden, werden diese Daten ebenfalls beibehalten. Verwenden Sie das Exportfeature, um Sicherungen Ihrer Redis-Instanz zu erstellen.

Umfang der Verfügbarkeit

Tarif Arbeitsspeicheroptimiert, Ausgeglichen, Für Compute optimiert Flash-optimiert
Verfügbar Ja Ja

Arten von Datenpersistenz in Redis

Für Persistenz mit Azure Managed Redis stehen zwei Optionen zur Verfügung – das RDB-Format (Redis-Datenbank) und das AOF-Format (Append-Only File):

  • RDB-Persistenz: Wenn Sie RDB-Persistenz verwenden, speichert Azure Managed Redis dauerhaft eine Momentaufnahme Ihres Caches in einem binären Format. Die Momentaufnahme wird auf einem verwalteten Datenträger gespeichert, der an die Redis-Instanz bereitgestellt wird. Die konfigurierbare Sicherungshäufigkeit bestimmt, wie oft die Momentaufnahme dauerhaft gespeichert werden soll. Bei einem schwerwiegenden Fehler, bei dem der primäre sowie der Replikatcache deaktiviert werden, wird der Cache automatisch mithilfe der neuesten Momentaufnahme wiederhergestellt. Erfahren Sie mehr über die Vorteile und Nachteile der RDB-Persistenz.
  • AOF-Persistenz: Wenn Sie AOF-Persistenz verwenden, speichert Azure Managed Redis jeden Schreibvorgang in einem Protokoll. Das Protokoll wird einmal pro Sekunde auf einem verwalteten Datenträger gespeichert, der an die Redis-Instanz bereitgestellt wird. Bei einem schwerwiegenden Fehler, bei dem der primäre sowie der Replikatcache deaktiviert werden, wird der Cache automatisch mithilfe der gespeicherten Schreibvorgänge wiederhergestellt. Erfahren Sie mehr über die Vorteile und Nachteile der AOF-Persistenz.

Wichtig

Die Persistenzfunktionen von Azure Managed Redis sind dazu gedacht, Daten nach einem Datenverlust automatisch im gleichen Cache wiederherzustellen. Auf die gespeicherten RDB/AOF-Datendateien kann weder von Benutzern zugegriffen noch in einen neuen oder vorhandenen Cache importiert werden. Wenn Sie Daten in einen anderen Cache verschieben möchten, verwenden Sie das Import/Export-Feature. Weitere Informationen und Anweisungen finden Sie unter Importieren und Exportieren von Daten im Azure Managed Redis.

Wenn Sie Sicherungen von Daten generieren möchten, die einem neuen Cache hinzugefügt werden können, können Sie mithilfe von PowerShell oder mithilfe der Azure CLI automatisierte Skripts schreiben, die regelmäßig Daten exportieren.

Voraussetzungen und Einschränkungen

Persistenzfunktionen sind dafür gedacht, Daten nach einem Datenverlust im gleichen Cache wiederherzustellen.

  • Persistent gespeicherte RDB/AOF-Datendateien können nicht in einen neuen oder den vorhandenen Cache importiert werden. Verwenden Sie stattdessen das Import/Export-Feature.
  • Persistenz wird bei Caches mit aktiver Georeplikation nicht unterstützt.
  • Der verwaltete Datenträger mit den persistenten Datendateien wird standardmäßig mit von Microsoft verwalteten Schlüsseln (MMK) verschlüsselt. Es können jedoch auch von Kunden verwaltete Schlüssel (CMK) verwendet werden. Weitere Informationen finden Sie unter Verwalten der Datenverschlüsselung.

Einrichten von Datenpersistenz über das Azure-Portal

  1. Melden Sie sich beim Azure-Portal an, und folgen Sie der Anleitung unter Schnellstart: Azure Managed Redis.

  2. Wenn Sie die Registerkarte Erweitert erreichen, wählen Sie im Abschnitt Datenpersistenz die Option RDB oder AOF aus.

    Screenshot: Registerkarte „Erweitert“ im Enterprise-Tarif. Der Abschnitt „Datenpersistenz“ ist mit einem roten Kasten hervorgehoben.

  3. Zum Aktivieren der RDB-Persistenz wählen Sie RDB aus, und konfigurieren Sie die Einstellungen.

    Einstellung Vorgeschlagener Wert BESCHREIBUNG
    Sicherungshäufigkeit Wählen Sie in der Dropdownliste ein Sicherungsintervall aus. Zur Auswahl stehen 60 Minuten, 6 Stunden und 12 Stunden. Dieses Intervall wird ab dem Moment rückwärts gezählt, an dem der vorherige Sicherungsvorgang erfolgreich abgeschlossen wird. Wenn das Intervall abgelaufen ist, wird eine neue Sicherung gestartet.

  4. Um die AOF-Persistenz zu aktivieren, wählen Sie AOF aus. Es ist nur eine Sicherungshäufigkeitsoption verfügbar.

  5. Folgen Sie der restlichen Anleitung unter Schnellstart: Azure Managed Redis, um die Erstellung des Caches abzuschließen.

Hinweis

Sie können einer zuvor erstellten Azure Managed Redis-Instanz jederzeit Persistenz hinzufügen, indem Sie im Ressourcenmenü zu Erweiterte Einstellungen navigieren.

Einrichten von Datenpersistenz mithilfe von PowerShell und Azure CLI

PowerShell

Der Befehl New-AzRedisEnterpriseCache kann verwendet werden, um eine neue Azure Managed Redis-Instanz zu erstellen. Verwenden Sie die Parameter RdbPersistenceEnabled, RdbPersistenceFrequency, AofPersistenceEnabled und AofPersistenceFrequency, um die Persistenz zu konfigurieren. In diesem Beispiel wird eine neue Balanced B10-Instanz mit RDB-Persistenz mit einer Stundenfrequenz erstellt:

New-AzRedisEnterpriseCache -Name "MyCache" -ResourceGroupName "MyGroup" -Location "West US" -Sku "Balanced_B10" -RdbPersistenceEnabled -RdbPersistenceFrequency "1h"

Bereits vorhandene Caches können mithilfe des Befehls Update-AzRedisEnterpriseCacheDatabase aktualisiert werden. In diesem Beispiel wird einer bereits vorhandenen Instanz RDB-Persistenz mit einer Frequenz von 12 Stunden hinzugefügt:

Update-AzRedisEnterpriseCacheDatabase -Name "MyCache" -ResourceGroupName "MyGroup" -RdbPersistenceEnabled -RdbPersistenceFrequency "12h"

Verwenden der Azure CLI

Der Befehl az redisenterprise create kann verwendet werden, um eine neue Azure Managed Redis-Instanz zu erstellen. Verwenden Sie die Parameter rdb-enabled, rdb-frequency, aof-enabled und aof-frequency, um die Persistenz zu konfigurieren. In diesem Beispiel wird eine neue Balanced B10-Instanz mit RDB-Persistenz mit einer Stundenfrequenz erstellt:

az redisenterprise create --cluster-name "cache1" --resource-group "rg1" --location "East US" --sku "Balanced_B10" --persistence rdb-enabled=true rdb-frequency="1h"

Bereits vorhandene Caches können mithilfe des Befehls az redisenterprise database update aktualisiert werden. In diesem Beispiel wird einer bereits vorhandenen Cache-Instanz RDB-Persistenz mit einer Frequenz von 12 Stunden hinzugefügt:

az redisenterprise database update --cluster-name "cache1" --resource-group "rg1" --persistence rdb-enabled=true rdb-frequency="12h"

Verwalten der Datenverschlüsselung

Da durch Redis-Persistenz ruhende Daten erzeugt werden, ist die Verschlüsselung dieser Daten ein wichtiges Anliegen für viele Benutzer*innen. Auf Azure Managed Redis werden Daten auf einem verwalteten Datenträger gespeichert, der an die Cache-Instanz bereitgestellt wird. Standardmäßig werden der Datenträger mit den Persistenzdaten sowie der Betriebssystemdatenträger mit von Microsoft verwalteten Schlüsseln verschlüsselt. Es kann aber auch ein kundenseitig verwalteter Schlüssel (Customer-Managed Key, CMK) verwendet werden, um die Datenverschlüsselung zu steuern. Anweisungen finden Sie unter Verschlüsselung unter Azure Managed Redis.

Persistenz – häufig gestellte Fragen

Die folgende Liste enthält Antworten auf häufig gestellte Fragen zur Persistenz von Azure Managed Redis-Instanzen.

RDB-Persistenz

AOF-Persistenz

Kann ich die Persistenz für einen bereits erstellten Cache aktivieren?

Ja, Persistenz kann sowohl bei der Cacheerstellung als auch in vorhandenen Azure Managed Redis-Instanzen konfiguriert werden.

Kann ich AOF- und RDB-Persistenz gleichzeitig aktivieren?

Nein, Sie können RDB oder AOF aktivieren, aber nicht beide Optionen gleichzeitig.

Wie funktioniert Persistenz bei der Georeplikation?

Wenn Sie Datenpersistenz aktivieren, kann die Georeplikation für Ihren Cache nicht aktiviert werden. Dies liegt daran, dass die aktive Georeplikation eine bessere Ausfallsicherheit bietet als die Datenpersistenz bei einem regionalen Ausfall. Wenn Sie eine Kopie Ihrer Daten als Sicherung exportieren müssen, verwenden Sie stattdessen das Exportfeature.

Welches Persistenzmodell sollte ich auswählen?

AOF-Persistenz speichert jeden Schreibvorgang in einem Protokoll, was erhebliche Auswirkungen auf den Durchsatz haben kann. RDB-Persistenz speichert Sicherungen basierend auf dem konfigurierten Sicherungsintervall mit minimaler Auswirkung auf die Leistung. Wählen Sie AOF-Persistenz, wenn Ihr primäres Ziel die Minimierung von Datenverlusten ist und die Verringerung des Durchsatzes für Ihren Cache kein Problem darstellt. Wählen Sie die RDB-Persistenz aus, wenn Sie einen optimalen Durchsatz für Ihren Cache wünschen, aber trotzdem einen Mechanismus zur Datenwiederherstellen benötigen.

Weitere Informationen zur Leistung mit AOF-Persistenz finden Sie unter Hat AOF-Persistenz Auswirkungen auf den Durchsatz, die Wartezeit oder die Leistung meines Caches?.

Hat AOF-Persistenz Auswirkungen auf den Durchsatz, die Wartezeit oder die Leistung meines Caches?

Die Verwendung der AOF-Persistenz wirkt sich auf den Durchsatz aus. AOF wird in allen primären Prozessen ausgeführt. Daher kommt es bei einem Cache mit AOF-Persistenz zu einer höheren CPU- und Serverauslastung als bei einem identischen Cache ohne AOF-Persistenz. AOF bietet die beste Konsistenz mit den Daten im Arbeitsspeicher, da jeder Schreib- und Löschvorgang mit nur wenigen Sekunden Verzögerung persistent gespeichert wird. Der Nachteil: AOF ist rechenintensiver.

Was geschieht, wenn ich auf eine andere Größe skaliert habe und eine Wiederherstellung aus einer Sicherung vorgenommen wird, die vor der Skalierung erstellt wurde?

Für RDB- und AOF-Persistenz gilt Folgendes:

  • Wenn Sie auf eine größere Größe skaliert haben, hat dies keine Auswirkungen.
  • Wenn Sie auf eine kleinere Größe skaliert haben und dort nicht genug Platz für alle Daten aus der letzten Sicherung ist, werden beim Wiederherstellungsvorgang Schlüssel entfernt. Schlüssel werden in der Regel mithilfe der Entfernungsrichtlinie allkeys-lru entfernt.

Wird mir der für die Datenpersistenz verwaltete Datenträger in Rechnung gestellt?

Der verwaltete Datenträgerspeicher wird Ihnen nicht in Rechnung gestellt. Es ist im Preis inbegriffen.

Kann ich die Sicherungshäufigkeit für RDB-Persistenz ändern, nachdem ich den Cache erstellt habe?

Ja. Sie können die Sicherungsfrequenz für RDB-Persistenz über das Azure-Portal, mithilfe der CLI oder per PowerShell ändern.

Warum liegen mehr als 60 Minuten zwischen Sicherungen, wenn ich eine RDB-Sicherungshäufigkeit von 60 Minuten festgelegt habe?

Das Intervall für die Sicherungshäufigkeit bei der RDB-Persistenz beginnt erst, nachdem der vorherige Sicherungsvorgang erfolgreich abgeschlossen wurde. Wenn für die Sicherungshäufigkeit 60 Minuten festgelegt sind und der Sicherungsvorgang nach 15 Minuten beendet wird, wird der nächste Sicherungsvorgang 75 Minuten nach der Startzeit des vorherigen Sicherungsvorgangs gestartet.

Was geschieht mit den alten RDB-Sicherungen, wenn eine neue Sicherung durchgeführt wird?

Alle Sicherungen, mit Ausnahme der jeweils letzten Sicherung, werden bei der RDB-Persistenz automatisch gelöscht. Dieser Löschvorgang wird möglicherweise nicht sofort durchgeführt, ältere Sicherungen werden jedoch nicht dauerhaft gespeichert.

Was ist das Neuschreiben, und wie wirkt es sich auf meinen Cache aus?

Wenn die AOF-Datei groß genug ist, wird automatisch ein Neuschreibevorgang in die Warteschlange des Caches gestellt. Beim Neuschreiben wird die Größe der AOF-Datei um den minimalen Satz von Vorgängen geändert, die erforderlich sind, um das aktuelle DataSet zu erstellen. Während des Neuschreibens können Sie davon ausgehen, dass die Leistungsgrenzwerte früher erreicht werden – dies gilt insbesondere bei sehr großen Datasets. Erneute Generierungen treten seltener auf, wenn die AOF-Datei größer wird, dauern dann aber ziemlich lange.

Was kann ich bei der Skalierung eines Caches mit aktivierter AOF-Persistenz erwarten?

Wenn die AOF-Datei zum Zeitpunkt der Skalierung groß ist, dauert der Skalierungsvorgang länger als normal, da die Datei nach Abschluss der Skalierung erneut geladen wird.

Weitere Informationen zur Skalierung finden Sie unter Was geschieht, wenn ich auf eine andere Größe skaliert habe und eine Wiederherstellung aus einer Sicherung vorgenommen wird, die vor der Skalierung erstellt wurde?.

Nächste Schritte