Freigeben über

Datenpersistenz im Azure-Cache für Redis

  • Gilt für:: ✅ Azure Cache for Redis

Wenn ein Azure-Cache für Redis-Cachefehler auftritt, ist der Datenverlust möglich, wenn Knoten ausfallen. Redis Persistenz ermöglicht es Ihnen, die in Cacheinstanzen gespeicherten Daten beizubehalten. Im Falle eines Hardwarefehlers wird die Cache-Instanz mit Daten aus der Persistenzdatei aktiviert, wenn die Instanz wieder online ist.

In diesem Artikel wird die Redis-Persistenz und das Konfigurieren und Verwalten der Datenpersistenz in Ihren Azure Redis-Cacheinstanzen auf Premium- und Enterprise-Ebene beschrieben. Die Datenpersistenzfunktion ist in den Stufen "Einfach" und "Standard" nicht verfügbar und befindet sich in der Vorschau in den Enterprise- und Enterprise Flash-Stufen.

Die Möglichkeit zum Speichern von Daten ist eine wichtige Möglichkeit, die Haltbarkeit einer Cacheinstanz zu erhöhen, da alle Cachedaten im Arbeitsspeicher gespeichert werden. Persistenz sollte ein wichtiger Bestandteil Ihrer Azure Redis-Strategie für hohe Verfügbarkeit und Notfallwiederherstellung sein.

Wichtig

Die Datenpersistenzfunktionalität bietet Resilienz für unerwartete Redis-Knotenfehler. Die Datenpersistenz ist kein Datensicherungs- oder Zeitwiederherstellungsfeature (TIME Recovery, PITR). Wenn beschädigte Daten in die Redis-Instanz geschrieben werden, werden die beschädigten Daten ebenfalls beibehalten. Verwenden Sie zum Erstellen von Sicherungen Ihrer Redis-Instanz das Feature "Exportieren ".

Wichtig

Wenn Sie Persistenz im Premium-Tarif verwenden, überprüfen Sie, ob für Ihr Speicherkonto vorläufiges Löschen aktiviert ist, bevor Sie das Datenpersistenzfeature verwenden. Die Verwendung von Datenpersistenz mit vorläufigem Löschen verursacht hohe Speicherkosten. Weitere Informationen finden Sie unter "Soll ich "Vorläufiges Löschen" aktivieren?

Umfang der Verfügbarkeit

Tarif Basis, Standard Prämie Enterprise, Enterprise Flash
Verfügbar Nein Ja Ja (Vorschau)

Typen von Redis-Datenpersistenz

Azure Redis bietet zwei Arten von Datenpersistenz, das Redis-Datenbankformat (RDB) und das Append-only File (AOF)-Format.

  • RDB-Persistenz behält eine Momentaufnahme Ihres Caches in einem Binärformat bei und speichert sie in einem Azure Storage-Konto. Sie konfigurieren die Sicherungshäufigkeit, um zu bestimmen, wie oft die Momentaufnahme beibehalten werden soll. Wenn ein katastrophales Ereignis auftritt, das sowohl den primären als auch den Replikatcache deaktiviert, wird der Cache automatisch mithilfe der neuesten Momentaufnahme rekonstruiert. Weitere Informationen finden Sie unter RDB-Vor- und RDB-Nachteile.

  • AOF Persistenz speichert jeden Schreibvorgang in einem Protokoll und speichert das Protokoll einmal pro Sekunde in einem Azure Storage-Konto. Wenn ein katastrophales Ereignis auftritt, das sowohl den primären als auch den Replikatcache deaktiviert, wird der Cache automatisch mithilfe der gespeicherten Schreibvorgänge rekonstruiert. Weitere Informationen finden Sie unter AOF-Vor- und AOF-Nachteile.

Anforderungen und Einschränkungen

  • Datenpersistenzfunktionen bieten Resilienz für unerwartete Redis-Knotenfehler. Die Datenpersistenz ist kein Datensicherungs- oder PITR-Feature. Wenn beschädigte Daten in die Redis-Instanz geschrieben werden, bleiben die beschädigten Daten ebenfalls erhalten. Um Ihre Redis-Instanz zu sichern, verwenden Sie die Funktion „Exportieren“.

  • Azure Cache für Redis-Persistenzfunktionen sind dafür vorgesehen, Daten nach einem Datenverlust automatisch im gleichen Cache wiederherzustellen. Sie können gespeicherte Datendateien nicht in einen neuen oder vorhandenen Cache importieren.

    • Verwenden Sie zum Verschieben von Daten zwischen Caches die Features " Importieren und Exportieren von Daten ".

    • Um Sicherungen von Daten zu generieren, die einem neuen Cache hinzugefügt werden können, können Sie automatisierte Skripts mit PowerShell oder Azure CLI verwenden, die Daten regelmäßig exportieren.

  • Persistenz wird bei Caches, die passive Georeplikation oder aktive Georeplikation verwenden, nicht unterstützt.

  • Auf der Premium-Ebene werden Daten direkt in einem Azure Storage-Konto gespeichert, das Sie besitzen und verwalten.

  • Das Speicherkonto für die Premium-Datenpersistenz muss sich in derselben Region wie die Cacheinstanz befinden. Sie können jedoch ein Speicherkonto in einem anderen Abonnement verwenden, um Daten zu speichern, wenn Sie verwaltete Identität verwenden, um eine Verbindung mit dem Speicherkonto herzustellen.

  • Am besten deaktivieren Sie das "Soft Delete"-Feature auf dem Speicherkonto, das Sie für die Datenpersistenz der Premium-Stufe verwenden. Die Verwendung von Datenpersistenz mit vorläufigem Löschen verursacht hohe Speicherkosten. Weitere Informationen finden Sie unter "Preise und Abrechnung" , und sollte ich "Vorläufiges Löschen" aktivieren?

  • RDB-Dateien werden in Form von Seitenblobs in Speicher gesichert. Seitenblobs werden in Speicherkonten mit aktiviertem hierarchischen Namespace (HNS) nicht unterstützt, z. B. Azure Data Lake Storage Gen2, sodass Persistenz in diesen Speicherkonten tendenziell fehlschlägt.

  • Auf der Premium-Ebene wird die AOF-Persistenz nicht mit mehreren Replikaten unterstützt.

Datenverschlüsselung

Da die Redis-Persistenz Daten im Ruhezustand erstellt, ist es wichtig, diese Daten zu verschlüsseln. Die Verschlüsselungsoptionen variieren je nach der verwendeten Azure Redis-Ebene.

Für die Premium-Ebene werden Datenströme direkt von der Cacheinstanz zu Azure Storage übertragen, wenn persistenz initiiert wird. Azure Storage verschlüsselt Daten automatisch, wenn sie beibehalten werden. Sie können jedoch mehrere Verschlüsselungsmethoden verwenden, darunter microsoftverwaltete Schlüssel (MMKs), vom Kunden verwaltete Schlüssel (CUSTOMER Managed Keys, CMKs) und vom Kunden bereitgestellte Schlüssel. Weitere Informationen finden Sie unter Azure Storage-Verschlüsselung für ruhende Daten und vom Kunden verwaltete Schlüssel für die Azure Storage-Verschlüsselung.

Einrichten der Datenpersistenz

Sie können das Azure-Portal, Azure Resource Manager (ARM)-Vorlagen, PowerShell oder Azure CLI zum Erstellen und Einrichten der Datenpersistenz für Azure Redis-Caches der Premium- oder Enterprise-Ebene verwenden.

Voraussetzungen

  • Zum Erstellen und Hinzufügen von Persistenz zu Azure Redis-Caches benötigen Sie Schreibzugriff und Berechtigungen zum Erstellen von Premium- oder Enterprise-Caches in einem Azure-Abonnement.
  • Für Premium-Ebenen-Caches benötigen Sie ein Azure Storage-Konto in derselben Region wie Ihr Cache, um die Cachedaten zu speichern. Wenn Sie verwaltete Identität als Authentifizierungsmethode verwenden, können Sie ein Speicherkonto in einem anderen Abonnement als Ihrem Cache verwenden.
  • Für die Azure PowerShell-Verfahren benötigen Sie Azure PowerShell installiert oder Azure Cloud Shell mit der PowerShell-Umgebung im Azure-Portal verwenden.
  • Für die Azure CLI-Verfahren benötigen Sie entweder ein installiertes Azure CLI oder Sie verwenden die Azure Cloud Shell mit der Bash-Umgebung im Azure-Portal.

Einrichten der Datenpersistenz im Azure-Portal

Im Azure-Portal können Sie die Datenpersistenz einrichten, wenn Sie Ihre Azure Redis Premium- oder Enterprise-Cacheinstanz erstellen.

Hinweis

Sie können einem zuvor erstellten Cache auch Persistenz hinzufügen, indem Sie unter "Einstellungen" im linken Navigationsmenü für Den Cache zu "Datenpersistenz" navigieren.

  1. Um einen Premium-Cache im Azure-Portal zu erstellen, folgen Sie den Anweisungen unter "Schnellstart": Erstellen eines Open-Source-Redis-Caches, und wählen Sie "Premium " für die Cache-SKU auf der Registerkarte " Grundlagen " aus.

    Screenshot: Formular zum Erstellen einer Azure Cache for Redis-Ressource.

  2. Wenn Sie die Registerkarte "Erweitert " ausfüllen, wählen Sie entweder RDB - oder AOF-Persistenz für Sicherungsdatei unter "Datenpersistenz" aus, und konfigurieren Sie die relevanten Einstellungen.

    Screenshot der Einstellungen für die RDB-Datenpersistenz.

    • Konfigurieren Sie für RDB die folgenden Einstellungen:

      Einstellung Wert BESCHREIBUNG
      Authentifizierungsmethode Verwaltete Identität oder Speicherschlüssel auswählen Mithilfe der verwalteten Identität können Sie ein Speicherkonto in einem anderen Abonnement als Ihrem Cache verwenden.
      Abonnement Wählen Sie das Abonnement aus, das Ihre verwaltete Identität enthält. Dieses Element wird nur angezeigt, wenn Sie die Verwaltete Identitätsauthentifizierung ausgewählt haben.
      Sicherungshäufigkeit Wählen Sie ein Sicherungsintervall aus: 15 Minuten, 30 Minuten, 60 Minuten, 6 Stunden, 12 Stunden oder 24 Stunden. Dieses Intervall wird ab dem Moment rückwärts gezählt, an dem der vorherige Sicherungsvorgang erfolgreich abgeschlossen wird. Wenn das Intervall verstrichen ist, wird eine neue Sicherung gestartet.
      Speicherkonto Wählen Sie dann Ihr Speicherkonto aus. Das Speicherkonto muss sich in derselben Region wie der Cache befinden. Ein Premium-Speicherkonto wird empfohlen, da es einen höheren Durchsatz aufweist.
      Storage Key (Speicherschlüssel) Wählen Sie entweder den Primärschlüssel oder den sekundären Schlüssel aus, der verwendet werden soll. Dieses Element wird nur angezeigt, wenn Sie die Speicherschlüsselauthentifizierung ausgewählt haben. Wenn der Speicherschlüssel für Ihr Persistenzspeicherkonto neu generiert wird, müssen Sie den Schlüssel aus der Dropdownliste " Speicherschlüssel " neu konfigurieren.

    • Konfigurieren Sie für AOF die folgenden Einstellungen:

      Einstellung Wert BESCHREIBUNG
      Authentifizierungsmethode Verwaltete Identität oder Speicherschlüssel auswählen Mithilfe der verwalteten Identität können Sie ein Speicherkonto in einem anderen Abonnement als Ihrem Cache verwenden.
      Abonnement Wählen Sie das Abonnement aus, das Ihre verwaltete Identität enthält. Dieses Element wird nur angezeigt, wenn Sie die Verwaltete Identitätsauthentifizierung ausgewählt haben.
      Erstes Speicherkonto Wählen Sie dann Ihr Speicherkonto aus. Das Speicherkonto muss sich in derselben Region wie der Cache befinden. Ein Premium-Speicherkonto wird empfohlen, da es einen höheren Durchsatz aufweist.
      Erster Speicherschlüssel Wählen Sie entweder den Primärschlüssel oder Sekundärschlüssel zur Verwendung aus. Dieses Element wird nur angezeigt, wenn Sie die Speicherschlüsselauthentifizierung ausgewählt haben. Wenn der Speicherschlüssel neu generiert wird, müssen Sie den Schlüssel aus der Dropdownliste " Speicherschlüssel " neu konfigurieren.
      Zweites Speicherkonto Wählen Sie optional ein sekundäres Speicherkonto aus. Wenn Sie ein sekundäres Speicherkonto konfigurieren, werden die Schreibvorgänge in den Replikatcache in diesem zweiten Speicherkonto beibehalten.
      Zweiter Speicherschlüssel Wählen Sie entweder den Primärschlüssel oder sekundären Schlüssel aus, um ihn zu verwenden. Dieses Element wird nur angezeigt, wenn Sie die Speicherschlüsselauthentifizierung ausgewählt haben. Wenn der Speicherschlüssel neu generiert wird, müssen Sie den Schlüssel neu konfigurieren.

  3. Schließen Sie alle Registerkarten ab, und beenden Sie die Erstellung des Caches, indem Sie die restlichen Anweisungen in der Schnellstartanleitung befolgen: Erstellen Sie einen Open-Source-Redis-Cache.

Mit RDB-Persistenz beginnt die erste Sicherung, sobald das Backup-Frequenzintervall verstrichen ist.

Mit AOF-Persistenz schreiben Sie Vorgänge in den Cachespeicher im benannten Speicherkonto oder den benannten Speicherkonten. Wenn ein katastrophaler Fehler auftritt, der sowohl die primären als auch die Replikatcaches herunternimmt, wird das gespeicherte AOF-Protokoll verwendet, um den Cache neu zu erstellen.

Einrichten der Datenpersistenz mithilfe von Azure PowerShell

Sie können Azure PowerShell verwenden, um die Datenpersistenz einzurichten, wenn Sie einen Azure Redis Premium- oder Enterprise-Ebenen-Cache erstellen oder einem zuvor erstellten Cache Persistenz hinzufügen.

Sie können den Befehl "New-AzRedisCache" verwenden, um einen neuen Azure Redis Premium-Cache zu erstellen, der die Datenpersistenz verwendet.

Um vorhandene Caches zur Verwendung der Datenpersistenz zu aktualisieren, führen Sie den Befehl "Set-AzRedisCache " aus. Anweisungen finden Sie unter Hinzufügen von Persistenz zu einem vorhandenen Cache.

Einrichten der Datenpersistenz mithilfe von Azure CLI

Sie können Azure CLI verwenden, um die Datenpersistenz einzurichten, wenn Sie einen Azure Redis Premium- oder Enterprise-Ebenen-Cache erstellen oder einem zuvor erstellten Cache Persistenz hinzufügen.

Sie können den Befehl "az redis create " verwenden, um einen neuen Premium-Cache zu erstellen, der die Datenpersistenz verwendet. Beispiel:

az redis create --location westus2 --name MyRedisCache --resource-group MyResourceGroup --sku Premium --vm-size p1 --redis-configuration @"config_rdb.json"

Verwenden Sie den Befehl "az redis update" , um einen vorhandenen Cache zu aktualisieren. Beispiel:

az redis update --name MyRedisCache --resource-group MyResourceGroup --set "redisConfiguration.rdb-storage-connection-string"="BlobEndpoint=https//..." "redisConfiguration.rdb-backup-enabled"="true" "redisConfiguration.rdb-backup-frequency"="15" "redisConfiguration.rdb-backup-max-snapshot-count"="1"

Persistenz – häufig gestellte Fragen

Dieser Abschnitt enthält Antworten auf häufig gestellte Fragen zur Persistenz des Azure Redis-Caches.

RDB-Persistenz

AOF-Persistenz

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

Ja, Sie können die Persistenz bei der Cacheerstellung und in vorhandenen Premium-, Enterprise- oder Enterprise Flash-Caches konfigurieren.

Kann ich AOF- und RDB-Persistenz gleichzeitig aktivieren?

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

Wie funktioniert Persistenz bei der Georeplikation?

Die Datenpersistenz funktioniert nicht mit aktivierter Georeplikation.

Welches Persistenzmodell sollte ich auswählen?

AOF-Persistenz schreibt einmal pro Sekunde in ein Protokoll, während RDB-Persistenz Sicherungen basierend auf dem konfigurierten Sicherungsintervall speichert. RDB-Persistenz wirkt sich weniger auf den Durchsatz und die Leistung aus als die AOF-Persistenz.

Wählen Sie AOF-Persistenz, wenn Ihr primäres Ziel darin besteht, Datenverluste zu minimieren, und Sie einen niedrigeren Durchsatz für den Cache verkraften können. Wählen Sie RDB-Persistenz aus, wenn Sie den optimalen Durchsatz im Cache beibehalten möchten, aber dennoch einen Mechanismus für die Datenwiederherstellung benötigen.

Weitere Informationen finden Sie unter RDB-Vorteile, RDB-Nachteile, AOF-Vor- und AOF-Nachteile.

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

Die AOF-Persistenz wirkt sich auf den Durchsatz aus. Da AOF sowohl im primären als auch im Replikatprozess ausgeführt wird, sehen Sie eine höhere CPU- und Serverlast für einen Cache mit AOF-Persistenz als für einen 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 Kompromiss besteht darin, dass AOF rechenintensiver ist.

Solange cpu- und Serverlast weniger als 90%sind, gibt es eine Strafe für den Durchsatz, aber der Cache funktioniert normal. Bei einer CPU- und Serverauslastung von über 90 % kann die Beeinträchtigung des Durchsatzes zunehmen, und die Wartezeit für alle Befehle, die vom Cache verarbeitet werden, erhöht sich. Die Latenz steigt, dass AOF-Persistenz sowohl auf den primären Prozess als auch auf den Replikatsprozess angewendet wird, wodurch sich die Auslastung des verwendeten Knotens erhöht und der kritische Pfad der Daten mit Persistenz versehen wird.

Was geschieht, wenn ich auf eine andere Größe skaliere und eine Sicherung wiederhergestellt wird, die vor dem Skalierungsvorgang vorgenommen wurde?

  • Wenn Sie auf eine größere Größe skaliert haben, hat dies keine Auswirkungen.
  • Wenn Sie auf eine kleinere Größe skaliert haben und über eine benutzerdefinierte Datenbankeinstellung verfügen, die größer als die Datenbankbeschränkung für Ihre neue Größe ist, werden Die Daten in diesen Datenbanken nicht wiederhergestellt. Weitere Informationen finden Sie unter Hat die Skalierung Auswirkungen auf meine benutzerdefinierte Einstellung für Datenbanken?
  • Wenn Sie auf eine kleinere Größe skaliert haben und nicht genügend Platz in der kleineren Größe vorhanden ist, um alle Daten aus der letzten Sicherung zu speichern, werden Schlüssel während des Wiederherstellungsvorgangs entfernt. Schlüssel werden in der Regel mithilfe der Entfernungsrichtlinie allkeys-lru entfernt.

Kann ich dasselbe Speicherkonto für Persistenz in zwei verschiedenen Caches verwenden?

Nein, Sie müssen unterschiedliche Speicherkonten verwenden. Jeder Cache muss über ein eigenes Speicherkonto verfügen, um die Persistenz zu erhalten.

Wichtig

Verwenden Sie außerdem separate Speicherkonten für Persistenz und regelmäßige Exportvorgänge in einem Cache.

Wird mir der für die Datenpersistenz verwendete Speicher in Rechnung gestellt?

  • Für Premium-Caches werden Ihnen die genutzten Speicherressourcen gemäß dem Preismodell des Speicherkontos in Rechnung gestellt.
  • Für Enterprise- und Enterprise Flash-Caches ist der verwaltete Datenträgerspeicher im Preis enthalten und verursacht keine zusätzlichen Gebühren.

Wie häufig schreiben RDB- und AOF-Persistenz in meine Blobs, und sollte ich vorläufiges Löschen aktivieren?

RDB- und AOF-Persistenz kann so häufig wie jede Stunde, alle paar Minuten oder jede Sekunde in Ihre Speicher-Blobs schreiben. Vorläufiges Löschen wird bei den typischen Datengrößen eines Caches, der auch Schreibvorgänge im Sekundentakt ausführt, schnell teuer. Das Aktivieren des vorläufigen Löschens für ein Speicherkonto bedeutet auch, dass Azure Redis die Speicherkosten nicht minimieren kann, indem die alten Sicherungsdaten gelöscht werden.

Es ist am besten, die Aktivierung der Softlöschung für Speicherkonten zu vermeiden, die Sie für die Azure Redis Premium-Tier-Datenpersistenz verwenden. Weitere Informationen zu den Kosten des vorläufigen Löschens finden Sie unter Preise und Abrechnung.

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

Ja, Sie können die Sicherungshäufigkeit für RDB-Persistenz ändern, indem Sie das Azure-Portal, die Azure CLI oder Azure PowerShell verwenden.

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 die Sicherungshäufigkeit 60 Minuten beträgt und ein Sicherungsvorgang 15 Minuten dauert, beginnt die nächste Sicherung erst 75 Minuten nach der Startzeit der vorherigen Sicherung.

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. Wenn Sie die Premium-Stufe für Persistenz verwenden und das vorläufige Löschen für Ihr Speicherkonto aktiviert ist, befinden sich die vorhandenen Sicherungen weiterhin im Zustand "Vorläufiges Löschen".

Wann sollte ich ein zweites Speicherkonto verwenden?

Verwenden Sie ein zweites Speicherkonto für die AOF-Persistenz, wenn Sie erwarten, dass sie über höhere als übliche SET-Vorgänge im Cache verfügen. Die Verwendung des sekundären Speicherkontos trägt dazu bei, dass Ihr Cache keine Speicherbandbreitengrenzwerte erreicht. Diese Option ist nur für Premium-Ebenen-Caches verfügbar.

Wie kann ich das zweite Speicherkonto entfernen?

Sie können das sekundäre Speicherkonto für die AOF Persistenz entfernen, indem Sie für das zweite Speicherkonto denselben Wert wie für das erste Speicherkonto festlegen. Um die Einstellungen für vorhandene Caches zu ändern, wählen Sie "Datenpersistenz " unter "Einstellungen" im linken Navigationsmenü der Cacheseite aus. Um die Persistenz vollständig zu deaktivieren, wählen Sie auf der Seite "Datenpersistenz" die Option "Deaktiviert" aus.

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

Wenn eine AOF-Datei groß genug wird, wird eine Neuschreibung automatisch im Cache in die Warteschlange 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. Rewrites treten weniger häufig auf, da die AOF-Datei größer wird, aber eine erhebliche Zeit in Anspruch nehmen, wenn sie auftreten.

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

Wenn die AOF-Datei zum Zeitpunkt der Skalierung groß ist, erwarten Sie, dass der Skalierungsvorgang länger dauert als üblich, da sie die Datei nach Abschluss der Skalierung erneut lädt. Sehen Sie sich auch an, was passiert, wenn ich auf eine andere Größe skaliere und eine Sicherung wiederhergestellt wird, die vor dem Skalierungsvorgang vorgenommen wurde?

Wie werden meine AOF-Daten im Speicher organisiert?

Im Premium-Tarif werden in AOF-Dateien gespeicherte Daten auf mehrere Seitenblobs pro Shard aufgeteilt. Standardmäßig wird die eine Hälfte der Blobs im primären und die andere im sekundären Speicherkonto gespeichert. Das Aufteilen der Daten über mehrere Seiten-Blobs und zwei verschiedene Speicherkonten verbessert die Leistung.

Wenn die Spitzenrate von Schreibvorgängen im Cache nicht hoch ist, ist diese zusätzliche Leistung möglicherweise nicht erforderlich. In diesem Fall kann die Konfiguration des sekundären Speicher-Accounts entfernt werden, und alle AOF-Dateien werden im primären Speicher-Account gespeichert. In der folgenden Tabelle wird angezeigt, wie viele Gesamtseitenblobs jede Preisstufe verwendet.

Premium-Tarif BLOBs
P1 8 pro Shard
P2 16 pro Shard
Seite 3 32 pro Shard
P4 40 pro Shard

Wenn das Clustering aktiviert ist, verfügt jeder Shard im Cache über einen eigenen Satz von Seitenblobs entsprechend der vorherigen Tabelle. Bei einem P2-Cache mit drei Shards wird die AOF-Datei beispielsweise auf 48 Seitenblobs verteilt: sechzehn Blobs pro Shard, bei drei Shards.

Nach dem Neuschreiben sind zwei Sätze von AOF-Dateien im Speicher vorhanden. Neuschreibevorgänge werden im Hintergrund ausgeführt und fügen an den ersten Satz von Dateien an. SET-Vorgänge, die während des Umschreibens an den Cache gesendet werden, werden an den zweiten Satz von Dateien angehängt.

Wenn während eines Umschreibens ein Fehler auftritt, wird eine Sicherung vorübergehend gespeichert. Die Sicherung wird nach Abschluss des Überschreibens umgehend gelöscht. Wenn vorläufiges Löschen für Ihr Speicherkonto aktiviert ist, gilt die Einstellung für vorläufiges Löschen, und vorhandene Sicherungen bleiben im Zustand des vorläufigen Löschens.

Wirken sich Firewall-Ausnahmen auf das Speicherkonto auf die Persistenz aus?

Ja. Zur Persistenz auf der Premium-Ebene kann die Verwendung von Firewalleinstellungen für das Speicherkonto verhindern, dass das Persistenzfeature funktioniert.

Sie können auf Fehler beim Speichern von Daten überprüfen, indem Sie die Fehlermetrik anzeigen. Diese Metrik gibt an, ob der Cache aufgrund von Firewalleinschränkungen für das Speicherkonto oder andere Probleme keine Daten speichern kann.

Um die Datenpersistenz mit einem Speicherkonto zu verwenden, das eine Firewall eingerichtet hat, verwenden Sie die verwaltete identitätsbasierte Authentifizierung , um eine Verbindung mit dem Speicher herzustellen. Durch die Verwendung der verwalteten Identität wird der Liste der vertrauenswürdigen Dienste die Cacheinstanz hinzugefügt, wodurch Firewall-Ausnahmen einfacher angewendet werden können. Wenn Sie das Speicherkonto mithilfe eines Schlüssels anstelle der verwalteten Identität autorisieren, führt die Verwendung von Firewall-Ausnahmen für das Speicherkonto dazu, den Persistenzprozess zu unterbrechen.

Kann ich die AOF-Persistenz aktivieren, wenn ich über mehr als ein Replikat verfüge?

Mit der Premium-Stufe können Sie keine AOF-Persistenz mit mehreren Replikaten verwenden. In den Enterprise- und Enterprise Flash-Ebenen ist die Replikatarchitektur komplizierter, aber AOF-Persistenz wird unterstützt, wenn Unternehmenscaches in zonenredundanten Bereitstellungen verwendet werden.

Wie überprüfe ich, ob vorläufiges Löschen für mein Speicherkonto aktiviert ist?

Wählen Sie im Azure-Portal das Speicherkonto aus, das Ihr Cache für Persistenz verwendet, und wählen Sie den Datenschutz unter "Datenverwaltung " im linken Navigationsmenü aus. Überprüfen Sie auf der Seite "Datenschutz ", ob " Vorläufiges Löschen für Blobs aktivieren " aktiviert ist. Weitere Informationen zum vorläufigen Löschen in Azure-Speicherkonten finden Sie unter Aktivieren des vorläufigen Löschens für Blobs.

Kann ich ein Speicherkonto in einem anderen Abonnement als das Konto verwenden, in dem sich mein Cache befindet?

Sie können ein Speicherkonto nur in einem anderen Abonnement auswählen, wenn Sie verwaltete Identität als Authentifizierungsmethode für Speicherkonten verwenden.

Verwandte Inhalte

Erfahren Sie mehr über Azure Cache for Redis-Features.