Konfigurieren von Datenpersistenz für eine Azure Cache for Redis-Instanz
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 Cache for Redis sein.
Warnung
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 sehr hohe Speicherkosten. Weitere Informationen finden Sie unter Soll ich vorläufiges Löschen aktivieren?.
Warnung
Die Option Immer schreiben für die AOF-Persistenz auf den Enterprise- und Enterprise Flash-Ebenen wird am 1. April 2025 eingestellt. Diese Option weist erhebliche Leistungseinschränkungen auf, die nicht mehr empfohlen werden. Es wird empfohlen, stattdessen die Option Bei jeden zweiten Vorgang schreiben oder die RDB-Persistenz zu verwenden.
Umfang der Verfügbarkeit
| Tarif | Basic, Standard | Premium | Enterprise, Enterprise Flash |
|---|---|---|---|
| Verfügbar | Nein | Ja | Ja (Vorschau) |
Arten von Datenpersistenz in Redis
Für Persistenz mit Azure Cache for 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 Cache for Redis dauerhaft eine Momentaufnahme Ihres Caches in einem binären Format. Die Momentaufnahme wird in einem Azure Storage-Konto gespeichert. 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 Cache for Redis jeden Schreibvorgang in einem Protokoll. Das Protokoll wird mindestens einmal pro Sekunde in einem Azure Storage-Konto gespeichert. 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.
Die Persistenzfunktionen von Azure Cache for Redis sind dazu gedacht, Daten nach einem Datenverlust automatisch im gleichen Cache wiederherzustellen. Die persistent gespeicherten RDB/AOF-Datendateien können nicht in einen neuen oder den 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 Cache für 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 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 passiver Georeplikation oder aktiver Georeplikation nicht unterstützt.
- Im Tarif Premium wird AOF-Persistenz mit mehreren Replikaten nicht unterstützt.
- Im Tarif Premium muss sich das Speicherkonto, in dem Daten persistent gespeichert werden, in der gleichen Region befinden wie die Cache-Instanz.
- Auf der Ebene Premium können Speicherkonten in verschiedenen Abonnements verwendet werden, um Daten beizubehalten, wenn eine verwaltete Identität zum Herstellen einer Verbindung mit dem Speicherkonto verwendet wird.
Unterschiede bei der Persistenz im Premium- und Enterprise-Tarif
Im Tarif Premium werden Daten direkt in einem Azure Storage-Konto gespeichert, das Sie besitzen und verwalten. Persistent gespeicherte Daten werden von Azure Storage automatisch verschlüsselt. Sie können aber auch Ihre eigenen Schlüssel für die Verschlüsselung verwenden. Weitere Informationen finden Sie unter Kundenseitig verwaltete Schlüssel für die Azure Storage-Verschlüsselung.
Warnung
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 sehr hohe Speicherkosten. Weitere Informationen finden Sie unter Soll ich vorläufiges Löschen aktivieren?.
In den Tarifen Enterprise und Enterprise Flash werden Daten persistent auf einem verwalteten Datenträger gespeichert, der direkt an die Cache-Instanz angefügt ist. Der Standort ist nicht konfigurierbar und für Benutzer*innen nicht zugänglich. Die Verwendung eines verwalteten Datenträgers erhöht die Leistung der Persistenz. Der Datenträger wird standardmäßig mit von Microsoft verwalteten Schlüsseln (Microsoft Managed Keys, MMKs) verschlüsselt. Es können aber auch kundenseitig verwaltete Schlüssel (Customer Managed Keys, CMKs) verwendet werden. Weitere Informationen finden Sie unter Verwalten der Datenverschlüsselung.
Einrichten von Datenpersistenz über das Azure-Portal
Melden Sie sich zum Erstellen eines Premium-Caches beim Azure-Portal an, und wählen Sie Ressource erstellen aus. Sie können Caches im Azure-Portal erstellen. Sie können sie auch mithilfe von Resource Manager-Vorlagen, PowerShell oder der Azure CLI erstellen.
Wählen Sie auf der Seite Ressource erstellen die Option Datenbanken und dann Azure Cache for Redis aus.
Konfigurieren Sie auf der Seite Neuer Redis Cache die Einstellungen für den neuen Premium-Cache.
Einstellung Vorgeschlagener Wert BESCHREIBUNG DNS-Name Geben Sie einen global eindeutigen Namen ein. Der Cachename muss zwischen 1 und 63 Zeichen lang sein und darf nur Ziffern, Buchstaben und Bindestriche enthalten. Der Name muss mit einer Zahl oder einem Buchstaben beginnen und enden und darf keine aufeinanderfolgenden Bindestriche enthalten. Der Hostname Ihrer Cache-Instanz ist \<DNS name>.redis.cache.windows.net.Abonnement Öffnen Sie die Dropdownliste, und wählen Sie Ihr Abonnement aus. Das Abonnement, unter dem diese neue Azure Cache for Redis-Instanz erstellt wird. Ressourcengruppe Öffnen Sie die Dropdownliste, und wählen Sie eine Ressourcengruppe aus. Alternativ dazu wählen Sie Neu erstellen aus und geben einen Namen für eine neue Ressourcengruppe ein. Der Name der Ressourcengruppe, in der Ihr Cache und weitere Ressourcen erstellt werden. Wenn Sie alle Ihre App-Ressourcen in einer Ressourcengruppe zusammenfassen, können Sie sie einfacher gemeinsam verwalten oder löschen. Location Öffnen Sie die Dropdownliste, und wählen Sie einen Standort aus. Wählen Sie eine Region in der Nähe anderer Dienste aus, die Ihren Cache verwenden. Cachetyp Öffnen Sie die Dropdownliste, und wählen Sie einen Premium-Cache aus, um Premium-Features zu konfigurieren. Weitere Informationen finden Sie unter Azure Cache for Redis – Preise. Der Tarif bestimmt Größe, Leistung und verfügbare Features für den Cache. Weitere Informationen finden Sie unter What is Azure Cache for Redis (Was ist Azure Cache for Redis?). Wählen Sie die Registerkarte Netzwerk oder unten auf der Seite die Schaltfläche Netzwerk aus.
Wählen Sie auf der Registerkarte Netzwerk Ihre Konnektivitätsmethode aus. Bei Premium-Cache-Instanzen wird die Verbindung entweder öffentlich über öffentliche IP-Adressen oder über Dienstendpunkte hergestellt. Eine private Verbindung stellen Sie über einen privaten Endpunkt her.
Wählen Sie die Registerkarte Weiter: Erweitert oder unten auf der Seite die Schaltfläche Weiter: Erweitert aus.
Konfigurieren Sie auf der Registerkarte Erweitert für eine Premium-Cache-Instanz die Einstellungen für einen Nicht-TLS-Port sowie für Clustering und Datenpersistenz. Für die Datenpersistenz können Sie RDB oder AOF auswählen.
Zum Aktivieren der RDB-Persistenz wählen Sie RDB aus, und konfigurieren Sie die Einstellungen.
Einstellung Vorgeschlagener Wert BESCHREIBUNG Authentifizierungsmethode Öffnen Sie die Dropdownliste, und wählen Sie eine Authentifizierungsmethode aus. Die Auswahlmöglichkeiten sind Verwaltete Identität oder Speicherschlüssel Wählen Sie Ihre bevorzugte Authentifizierungsmethode. Mithilfe der verwalteten Identität können Sie ein Speicherkonto in einem anderen Abonnement verwenden als dem, in dem sich Ihr Cache befindet. Abonnement Öffnen Sie die Dropdownliste, und wählen Sie ein Abonnement aus. Sie können ein Speicherkonto in einem anderen Abonnement auswählen, wenn Sie „Verwaltete Identität“ als Authentifizierungsmethode verwenden. Sicherungshäufigkeit Dropdown, und wählen Sie ein Sicherungsintervall aus. Zur Auswahl stehen 15 Minuten, 30 Minuten, 60 Minuten, 6 Stunden, 12 Stunden und 24 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. Speicherkonto Öffnen Sie die Dropdownliste, und wählen Sie Ihr Speicherkonto aus. Wählen Sie ein Speicherkonto aus, das sich in derselben Region und demselben Abonnement wie der Cache befindet. Ein Storage Premium-Konto wird empfohlen, da es einen höheren Durchsatz hat. Außerdem empfiehlt es sich dringend, für das Speicherkonto das Feature für vorläufiges Löschen zu deaktivieren, da es zu erhöhten Speicherkosten führt. Weitere Informationen finden Sie unter Preise und Abrechnung. Storage Key (Speicherschlüssel) Öffnen Sie die Dropdownliste, und wählen Sie Primärer Schlüssel oder Sekundärer Schlüssel aus. Wenn der Speicherschlüssel für Ihr Persistenzkonto neu generiert wird, müssen Sie den Schlüssel über die Dropdownliste Speicherschlüssel neu konfigurieren. Die erste Sicherung wird gestartet, sobald das Intervall für die Sicherungshäufigkeit abgelaufen ist.
Hinweis
Wenn RDB-Dateien im Speicher gesichert werden, erfolgt die Speicherung in Form von Seitenblobs. Wenn Sie ein Speicherkonto mit aktiviertem HNS verwenden, schlägt Persistenz tendenziell fehl, da Seitenblobs in Speicherkonten mit aktiviertem HNS (ADLS Gen2) nicht unterstützt werden.
Zum Aktivieren der AOF-Persistenz wählen Sie AOF aus, und konfigurieren Sie die Einstellungen.
Einstellung Vorgeschlagener Wert BESCHREIBUNG Authentifizierungsmethode Öffnen Sie die Dropdownliste, und wählen Sie eine Authentifizierungsmethode aus. Die Auswahlmöglichkeiten sind Verwaltete Identität oder Speicherschlüssel Wählen Sie Ihre bevorzugte Authentifizierungsmethode. Mithilfe der verwalteten Identität können Sie ein Speicherkonto in einem anderen Abonnement verwenden als dem, in dem sich Ihr Cache befindet. Abonnement Öffnen Sie die Dropdownliste, und wählen Sie ein Abonnement aus. Sie können ein Speicherkonto in einem anderen Abonnement auswählen, wenn Sie „Verwaltete Identität“ als Authentifizierungsmethode verwenden. Erstes Speicherkonto Öffnen Sie die Dropdownliste, und wählen Sie Ihr Speicherkonto aus. Wählen Sie ein Speicherkonto aus, das sich in derselben Region und demselben Abonnement wie der Cache befindet. Ein Storage Premium-Konto wird empfohlen, da es einen höheren Durchsatz hat. Außerdem empfiehlt es sich dringend, für das Speicherkonto das Feature für vorläufiges Löschen zu deaktivieren, da es zu erhöhten Speicherkosten führt. Weitere Informationen finden Sie unter Preise und Abrechnung. Erster Speicherschlüssel Öffnen Sie die Dropdownliste, und wählen Sie Primärer Schlüssel oder Sekundärer Schlüssel aus. Wenn der Speicherschlüssel für Ihr Persistenzkonto neu generiert wird, müssen Sie den Schlüssel über die Dropdownliste Speicherschlüssel neu konfigurieren. Zweites Speicherkonto (Optional) Öffnen Sie die Dropdownliste, und wählen Sie Ihr sekundäres Speicherkonto aus. Sie können optional ein weiteres Speicherkonto konfigurieren. Wenn ein zweites Storage-Konto konfiguriert wurde, werden Schreibvorgänge im Replikatcache in dieses zweite Speicherkonto geschrieben. Zweiter Speicherschlüssel (Optional) Öffnen Sie die Dropdownliste, und wählen Sie Primärer Schlüssel oder Sekundärer Schlüssel aus. Wenn der Speicherschlüssel für Ihr Persistenzkonto neu generiert wird, müssen Sie den Schlüssel über die Dropdownliste Speicherschlüssel neu konfigurieren. Bei aktivierter AOF-Persistenz werden Schreibvorgänge in den Cache im benannten Speicherkonto gespeichert (oder in den Konten, wenn Sie ein zweites Speicherkonto konfiguriert haben). Bei einem schwerwiegenden Fehler, der zu einem Ausfall des primären und des Replikatcaches führt, wird das gespeicherte AOF-Protokoll für die Neuerstellung des Caches verwendet.
Wählen Sie die Registerkarte Weiter: Tags oder unten auf der Seite die Schaltfläche Weiter: Tags aus.
Geben Sie optional auf der Registerkarte Tags den Namen und den Wert ein, wenn Sie die Ressource kategorisieren möchten.
Klicken Sie auf Überprüfen + erstellen. Sie werden zur Registerkarte Überprüfen und erstellen weitergeleitet, auf der Azure Ihre Konfiguration überprüft.
Wenn die grüne Meldung „Validierung erfolgreich“ angezeigt wird, wählen Sie Erstellen aus.
Es dauert eine Weile, bis der Cache erstellt wird. Sie können den Fortschritt auf der Seite Übersicht von Azure Cache for Redis überwachen. Wenn Wird ausgeführt als Status angezeigt wird, ist der Cache einsatzbereit.
Einrichten von Datenpersistenz mithilfe von PowerShell und Azure CLI
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. Die Verschlüsselungsoptionen variieren je nach verwendetem Azure Cache for Redis-Tarif.
Im Premium-Tarif werden Daten direkt von der Cache-Instanz an Azure Storage gestreamt, wenn Persistenz initiiert wird. Mit Azure Storage können verschiedene Verschlüsselungsmethoden verwendet werden. Hierzu zählen von Microsoft verwaltete Schlüssel, kundenseitig verwaltete Schlüssel und vom Kunden bereitgestellte Schlüssel. Informationen zu Verschlüsselungsmethoden finden Sie unter Azure Storage-Verschlüsselung für ruhende Daten.
In den Tarifen Enterprise und Enterprise Flash werden Daten auf einem verwalteten Datenträger gespeichert, der in die Cache-Instanz eingebunden ist. 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. Eine entsprechende Anleitung finden Sie unter Konfigurieren der Datenträgerverschlüsselung für Azure Cache for Redis-Instanzen mit kundenseitig verwalteten Schlüsseln (Vorschau).
Persistenz – häufig gestellte Fragen
Die folgende Liste enthält Antworten auf häufig gestellte Fragen zur Persistenz von Azure Cache for Redis-Instanzen.
- Kann ich die Persistenz für einen bereits erstellten Cache aktivieren?
- Kann ich AOF- und RDB-Persistenz gleichzeitig aktivieren?
- Wie funktioniert Persistenz bei der Georeplikation?
- Welches Persistenzmodell sollte ich auswählen?
- 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?
- Kann ich dasselbe Speicherkonto für Persistenz in zwei verschiedenen Caches verwenden?
- Wird mir der für die Datenpersistenz verwendete Speicher in Rechnung gestellt?
- Wie häufig schreiben RDB- und AOF-Persistenz in meine Blobs, und sollte ich vorläufiges Löschen aktivieren?
- Wirken sich Firewallausnahmen für das Speicherkonto auf die Persistenz aus?
- Wie überprüfe ich, ob vorläufiges Löschen für mein Speicherkonto aktiviert ist?
RDB-Persistenz
- Kann ich die Sicherungshäufigkeit für RDB-Persistenz ändern, nachdem ich den Cache erstellt habe?
- Warum liegen mehr als 60 Minuten zwischen Sicherungen, wenn ich eine RDB-Sicherungshäufigkeit von 60 Minuten festgelegt habe?
- Was geschieht mit den alten RDB-Sicherungen, wenn eine neue Sicherung durchgeführt wird?
AOF-Persistenz
- Wann sollte ich ein zweites Speicherkonto verwenden?
- Hat AOF-Persistenz Auswirkungen auf den Durchsatz, die Wartezeit oder die Leistung meines Caches?
- Wie kann ich das zweite Speicherkonto entfernen?
- Was ist das Neuschreiben, und wie wirkt es sich auf meinen Cache aus?
- Was kann ich bei der Skalierung eines Caches mit aktivierter AOF-Persistenz erwarten?
- Wie werden meine AOF-Daten im Speicher organisiert?
- Kann ich die AOF-Persistenz aktivieren, wenn ich über mehr als ein Replikat verfüge?
Kann ich die Persistenz für einen bereits erstellten Cache aktivieren?
Ja. Persistenz kann sowohl bei der Erstellung des Caches als auch für bereits vorhandene Caches im Tarif Premium, Enterprise oder Enterprise Flash 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.
Welches Persistenzmodell sollte ich auswählen?
AOF-Persistenz speichert jeden Schreibvorgang in einem Protokoll, was erhebliche Auswirkungen auf den Durchsatz hat. Vergleicht man AOF- mit RDB-Persistenz, welche davon speichert Sicherungen auf Grundlage des konfigurierten Sicherungsintervalls 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.
- Erfahren Sie mehr über die Vorteile und Nachteile der RDB-Persistenz.
- Erfahren Sie mehr über die Vorteile und Nachteile der AOF-Persistenz.
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?
AOF-Persistenz wirkt sich auf den Durchsatz aus. AOF wird sowohl im primären Prozess als auch im Replikatprozess 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.
Solange die CPU- und Serverauslastung weniger als 90 % betragen, ist der Durchsatz zwar beeinträchtigt, aber der Cache funktioniert ansonsten normal. Bei einer CPU- und Serverauslastung von über 90 Prozent kann die Beeinträchtigung des Durchsatzes stark 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 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 eine benutzerdefinierte Einstellung für die Datenbanken verwenden, die größer ist als der Grenzwert für Datenbanken bei der neuen Größe, 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 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.
Kann ich dasselbe Speicherkonto für Persistenz in zwei verschiedenen Caches verwenden?
Nein, Sie müssen unterschiedliche Speicherkonten für verschiedene Caches verwenden. Jeder Cache muss über ein eigenes Speicherkonto verfügen, um die Persistenz zu erhalten.
Wichtig
Verwenden Sie separate Speicherkonten für Persistenz und regelmäßige Exportvorgänge in einem Cache.
Wird mir der für Datenpersistenz beanspruchte Speicherplatz in Rechnung gestellt?
- Bei Caches im Tarif Premium wird Ihnen der beanspruchte Speicherplatz gemäß dem Preismodell des verwendeten Speicherkontos in Rechnung gestellt.
- Bei Caches im Tarif Enterprise und Enterprise Flash wird Ihnen der verwaltete Datenträgerspeicher nicht in Rechnung gestellt. Es ist im Preis inbegriffen.
Wie häufig schreiben RDB- und AOF-Persistenz in meine Blobs, und sollte ich vorläufiges Löschen aktivieren?
Es wird davon abgeraten, vorläufiges Löschen für Speicherkonten zu aktivieren, die mit Azure Cache for Redis-Datenpersistenz im Premium-Tarif genutzt werden. RDB- und AOF-Persistenz können so häufig wie jede Stunde, alle paar Minuten oder jede Sekunde in Ihre Blobs schreiben. Außerdem bedeutet das Aktivieren des vorläufigen Löschens für ein Speicherkonto, dass Azure Cache for Redis die Speicherkosten nicht minimieren kann, indem die alten Sicherungsdaten gelöscht werden.
Vorläufiges Löschen wird bei den typischen Datengrößen eines Caches, der auch Schreibvorgänge im Sekundentakt ausführt, schnell teuer. 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 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. Wenn Sie den Premium-Tarif für Persistenz verwenden und vorläufiges Löschen für Ihr Speicherkonto aktiviert ist, gilt die Einstellung für vorläufiges Löschen, und bereits vorhandene Sicherungen bleiben im vorläufig gelöschten Zustand.
Wann sollte ich ein zweites Speicherkonto verwenden?
Verwenden Sie ein zweites Speicherkonto für AOF-Persistenz, wenn Sie glauben, dass im Cache mehr als die erwarteten Festlegungsvorgänge ausgeführt werden. Durch das Einrichten des sekundären Speicherkontos wird sichergestellt, dass Ihr Cache nicht die Grenzwerte für die Speicherbandbreite erreicht. Diese Option ist nur für Caches im Premium-Tarif 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. Verwenden Sie bei bereits vorhandenen Caches das Ressourcenmenü für Ihren Cache, um auf das Blatt Datenpersistenz zuzugreifen. Zum Deaktivieren der AOF-Persistenz wählen Sie Deaktiviert aus.
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 erwartet, 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?.
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. Durch Aufteilen der Daten auf mehrere Seitenblobs und zwei verschiedene Speicherkonten erhöht sich die Leistung.
Wenn die Spitzenrate der Schreibvorgänge in den Cache nicht sehr hoch ist, wird diese zusätzliche Leistung möglicherweise nicht benötigt. In diesem Fall kann die Konfiguration des sekundären Speicherkontos entfernt werden. Alle AOF-Dateien werden stattdessen nur im primären Speicherkonto gespeichert. Die folgende Tabelle zeigt die Gesamtanzahl der Seitenblobs für die einzelnen Tarife:
| Premium-Tarif | BLOBs |
|---|---|
| P1 | 8 pro Shard |
| P2 | 16 pro Shard |
| P3 | 32 pro Shard |
| P4 | 40 pro Shard |
Nach dem Aktivieren des Clusterings verfügt jeder Shard im Cache über einen eigenen Satz von Seitenblobs, wie in der Tabelle oben ersichtlich. 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. Festlegevorgänge, die während des Neuschreibens an den Cache gesendet werden, fügen an den zweiten Satz an. Eine Sicherung wird bei einem Fehler vorübergehend während des Neuschreibens gespeichert. Die Sicherung wird sofort gelöscht, nachdem ein Neuschreibvorgang abgeschlossen wurde. 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 Firewallausnahmen für das Speicherkonto auf die Persistenz aus?
Ja. Die Verwendung Firewalleinstellungen für das Speicherkonto kann verhindern, dass das Persistenzfeature funktioniert. Sie können sehen, ob Fehler beim Speichern von Daten auftreten, 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 verwaltete identitätsbasierte Authentifizierung, um eine Verbindung mit dem Speicher herzustellen. Durch die Verwendung der verwalteten Identität wird die Cache-Instanz in die Liste der vertrauenswürdigen Dienste aufgenommen, was die Ausführung von Firewallausnahmen erleichtert. Wenn Sie keine verwaltete Identität verwenden und stattdessen die Autorisierung für ein Speicherkonto mit einem Schlüssel vornehmen, führen Firewallausnahmen für das Speicherkonto dazu, dass der Persistenzprozess unterbrochen wird. Dies gilt nur für Persistenz im Premium-Tarif.
Kann ich die AOF-Persistenz aktivieren, wenn ich über mehr als ein Replikat verfüge?
Im Premium-Tarif kann AOF-Persistenz (Append-Only File) nicht mit mehreren Replikaten verwendet werden. Im Enterprise- und Enterprise Flash-Tarif ist die Replikatarchitektur komplizierter, aber AOF-Persistenz wird unterstützt, wenn Enterprise-Caches in einer zonenredundanten Bereitstellung verwendet werden.
Wie überprüfe ich, ob vorläufiges Löschen für mein Speicherkonto aktiviert ist?
Wählen Sie das Speicherkonto aus, das Ihr Cache für Ausdauer verwendet. Wählen Sie im Ressourcen-Menü die Option Datenschutz aus. Überprüfen Sie im Arbeitsbereich den Status von Aktivieren des vorläufigen Löschens für Blobs. Weitere Informationen zum vorläufigen Löschen in Azure-Speicherkonten finden Sie unter Aktivieren des vorläufigen Löschens für Blobs.
Nächste Schritte
Erfahren Sie mehr über Azure Cache for Redis-Features.