Delen via


Gegevenspersistentie in Azure Cache voor Redis

Belangrijk

Azure Cache voor Redis heeft de tijdlijn voor buitengebruikstelling aangekondigd voor alle SKU's. We raden je aan om je Azure Cache voor Redis-instances zo snel mogelijk te verplaatsen naar Azure Managed Redis.

Voor meer informatie over de buitengebruikstelling:

Als er een Azure Cache voor Redis-cachefout optreedt, is gegevensverlies mogelijk wanneer knooppunten offline zijn. Met Redis-persistentie kunt u de gegevens die zijn opgeslagen in cache-exemplaren behouden. Als er een hardwarefout optreedt, wordt het cache-exemplaar gerehydrateerd met gegevens uit het persistentiebestand wanneer het weer online komt.

In dit artikel wordt Redis-persistentie beschreven en wordt beschreven hoe u gegevenspersistentie configureert en beheert in uw Azure Redis-cacheexemplaren in de Premium- en Enterprise-laag. De functie voor gegevenspersistentie is niet beschikbaar in Basic- of Standard-lagen en is in preview in Enterprise- en Enterprise Flash-lagen.

De mogelijkheid om gegevens te behouden is een belangrijke manier om de duurzaamheid van een cache-exemplaar te verbeteren, omdat alle cachegegevens in het geheugen worden opgeslagen. Persistentie moet een belangrijk onderdeel zijn van uw strategie voor hoge beschikbaarheid en herstel na noodgevallen van Azure Redis.

Belangrijk

De functionaliteit voor gegevenspersistentie biedt tolerantie voor onverwachte Redis-knooppuntfouten. Gegevenspersistentie is geen gegevensback-up of herstelfunctie op een specifiek tijdstip. Als beschadigde gegevens naar het Redis-exemplaar worden geschreven, worden de beschadigde gegevens ook bewaard. Als u back-ups van uw Redis-exemplaar wilt maken, gebruikt u de functie Exporteren .

Belangrijk

Als u persistentie op de Premium-laag gebruikt, controleert u of voorlopig verwijderen is ingeschakeld voor uw opslagaccount voordat u de functie voor gegevenspersistentie gebruikt. Het gebruik van gegevenspersistentie met voorlopig verwijderen veroorzaakt hoge opslagkosten. Zie meer informatie in Moet ik soft delete inschakelen?

Bereik van beschikbaarheid

Laag Basis, Standaard Premiumkwaliteit Enterprise, Enterprise Flash
Beschikbaar Nee Ja Ja (preview)

Typen Redis-gegevenspersistentie

Azure Redis biedt twee typen gegevenspersistentie, de Redis-database-indeling (RDB) en de Append-only File-indeling (AOF).

  • RDB-persistentie bewaart een momentopname van uw cache in een binair formaat en slaat deze op in een Azure Storage-account. U configureert de back-upfrequentie om te bepalen hoe vaak de momentopname moet worden bewaard. Als er een onherstelbare gebeurtenis optreedt die zowel de primaire als de replicacache uitschakelt, wordt de cache automatisch gereconstrueerd met behulp van de meest recente momentopname. Zie RDB-voordelen en RDB-nadelen voor meer informatie.

  • AOF-persistentie slaat elke schrijfbewerking op in een logboek en slaat het logboek één keer per seconde op in een Azure Storage-account. Als er een onherstelbare gebeurtenis optreedt die zowel de primaire als de replicacache uitschakelt, wordt de cache automatisch gereconstrueerd met behulp van de opgeslagen schrijfbewerkingen. Zie AOF-voordelen en AOF-nadelen voor meer informatie.

Vereisten en beperkingen

  • De functionaliteit voor gegevenspersistentie biedt veerkracht bij onverwachte fouten in Redis-knooppunten. Gegevenspersistentie is geen functie voor gegevensback-up of pitr. Als beschadigde gegevens naar het Redis-exemplaar worden geschreven, blijven de beschadigde gegevens ook behouden. Als u een back-up van uw Redis-exemplaar wilt maken, gebruikt u de functie Exporteren .

  • De persistentiefuncties van Azure Cache voor Redis zijn bedoeld om gegevens automatisch te herstellen naar dezelfde cache na gegevensverlies. U kunt persistente gegevensbestanden niet importeren in een nieuwe of bestaande cache.

    • Als u gegevens wilt verplaatsen tussen caches, gebruikt u de functies Gegevens importeren en exporteren .

    • Als u back-ups van gegevens wilt genereren die kunnen worden toegevoegd aan een nieuwe cache, kunt u geautomatiseerde scripts gebruiken met behulp van PowerShell of Azure CLI waarmee gegevens periodiek worden geëxporteerd.

  • Persistentie wordt niet ondersteund met caches die gebruikmaken van passieve geo-replicatie of actieve geo-replicatie.

  • In de Premium-laag worden gegevens rechtstreeks opgeslagen in een Azure Storage-account dat u bezit en beheert.

  • Het opslagaccount voor gegevenspersistentie in de Premium-laag moet zich in dezelfde regio bevinden als het cache-exemplaar. U kunt echter een opslagaccount in een ander abonnement gebruiken om gegevens vast te leggen als u beheerde identiteit gebruikt om verbinding te maken met het opslagaccount.

  • Het is het beste om de functie voor soft delete uit te schakelen op het opslagaccount dat u gebruikt voor de persistentie van gegevens in de Premium-laag. Het gebruik van gegevenspersistentie met voorlopig verwijderen veroorzaakt hoge opslagkosten. Voor meer informatie, zie Prijzen en facturering en Moet ik soft delete inschakelen?

  • Er wordt een back-up gemaakt van RDB-bestanden naar opslag in de vorm van pagina-blobs. Pagina-blobs worden niet ondersteund in opslagaccounts waarvoor HNS (Hierarchical Namespace) is ingeschakeld, zoals Azure Data Lake Storage Gen2, zodat persistentie meestal mislukt in deze opslagaccounts.

  • In de Premium-laag wordt AOF-persistentie niet ondersteund met meerdere replica's.

Gegevensversleuteling

Omdat Redis-persistentie resulteert in gegevens die in rust zijn, is het belangrijk om deze gegevens te versleutelen. Versleutelingsopties variëren op basis van de Azure Redis-laag die u gebruikt.

Voor de Premium-laag worden gegevensstromen rechtstreeks vanuit het cache-exemplaar naar Azure Storage gestreamd wanneer persistentie wordt gestart. Azure Storage versleutelt gegevens automatisch wanneer deze behouden blijven, maar u kunt verschillende versleutelingsmethoden gebruiken, waaronder door Microsoft beheerde sleutels (MMK's), door de klant beheerde sleutels (CMK's) en door de klant geleverde sleutels. Voor meer informatie, zie Azure Storage-versleuteling voor data-at-rest en door de klant beheerde sleutels voor Azure Storage-versleuteling.

Persistentie van gegevens instellen

U kunt de Azure-portal, Arm-sjablonen (Azure Resource Manager), PowerShell of Azure CLI gebruiken om gegevenspersistentie te maken en in te stellen voor Azure Redis-caches in Premium- of Enterprise-laag.

Vereiste voorwaarden

  • Als u persistentie wilt maken en toevoegen aan Azure Redis-caches, hebt u schrijftoegang en machtigingen nodig voor het maken van Premium- of Enterprise-caches in een Azure-abonnement.
  • Voor Caches in premium-lagen hebt u een Azure Storage-account in dezelfde regio nodig als uw cache om de cachegegevens op te slaan. Als u beheerde identiteit als verificatiemethode gebruikt, kunt u een opslagaccount in een ander abonnement dan uw cache gebruiken.
  • Voor de Azure PowerShell-procedures moet Azure PowerShell zijn geïnstalleerd of Azure Cloud Shell gebruiken met de PowerShell-omgeving in Azure Portal.
  • Voor de Azure CLI-procedures moet Azure CLI zijn geïnstalleerd of Azure Cloud Shell gebruiken met de Bash-omgeving in Azure Portal.

Persistentie van gegevens instellen in Azure Portal

In Azure Portal kunt u gegevenspersistentie instellen wanneer u uw Azure Redis Premium- of Enterprise-cache-exemplaar maakt.

Notitie

U kunt ook persistentie toevoegen aan een eerder gemaakte cache door te navigeren naar Gegevenspersistentie onder Instellingen in het linkernavigatiemenu voor uw cache.

  1. Als u een Premium-cache wilt maken in Azure Portal, volgt u de instructies in de quickstart: Een opensource Redis-cache maken en Premium voor de Cache-SKU selecteren op het tabblad Basisbeginselen .

    Schermopname van een formulier voor het maken van een Azure Cache voor Redis resource.

  2. Wanneer u het tabblad Geavanceerd invult, selecteert u RDB of AOF-persistentie voor het back-upbestand onder Gegevenspersistentie en configureert u de relevante instellingen.

    Schermopname van de instellingen voor RDB-gegevenspersistentie.

    • Configureer deze instellingen voor RDB:

      Instelling Waarde Beschrijving
      Verificatiemethode Beheerde identiteit of opslagsleutel selecteren Met beheerde identiteit kunt u een opslagaccount in een ander abonnement gebruiken dan uw cache.
      Abonnement Selecteer het abonnement dat uw beheerde identiteit bevat. Dit item wordt alleen weergegeven als u beheerde identiteitverificatie hebt gekozen.
      Backupfrequentie Selecteer een back-upinterval: 15 minuten, 30 minuten, 60 minuten, 6 uur, 12 uur of 24 uur. Dit interval begint af te tellen nadat de vorige back-upbewerking is voltooid. Wanneer het interval is verstreken, wordt een nieuwe back-up gestart.
      Opslagaccount Selecteer uw opslagaccount. Het opslagaccount moet zich in dezelfde regio bevinden als de cache. Een Premium-opslagaccount wordt aanbevolen omdat het een hogere doorvoer heeft.
      Opslagsleutel Selecteer de primaire sleutel of de secundaire sleutel die u wilt gebruiken. Dit item wordt alleen weergegeven als u verificatie van de opslagsleutel hebt gekozen. Als de opslagsleutel voor uw persistentieopslagaccount opnieuw wordt gegenereerd, moet u de sleutel opnieuw configureren vanuit de vervolgkeuzelijst Opslagsleutel .
    • Configureer deze instellingen voor AOF:

      Instelling Waarde Beschrijving
      Verificatiemethode Beheerde identiteit of opslagsleutel selecteren Met beheerde identiteit kunt u een opslagaccount in een ander abonnement gebruiken dan uw cache.
      Abonnement Selecteer het abonnement dat uw beheerde identiteit bevat. Dit item wordt alleen weergegeven als u beheerde identiteitverificatie hebt gekozen.
      Eerste opslagaccount Selecteer uw opslagaccount. Het opslagaccount moet zich in dezelfde regio bevinden als de cache. Een Premium-opslagaccount wordt aanbevolen omdat het een hogere doorvoer heeft.
      Eerste opslagsleutel Selecteer de primaire sleutel of secundaire sleutel die u wilt gebruiken. Dit item wordt alleen weergegeven als u verificatie van de opslagsleutel hebt gekozen. Als de opslagsleutel opnieuw wordt gegenereerd, moet u de sleutel opnieuw configureren vanuit de vervolgkeuzelijst Opslagsleutel .
      Tweede opslagaccount Selecteer eventueel een secundair opslagaccount. Als u een secundair opslagaccount configureert, worden de schrijfbewerkingen naar de replicacache bewaard naar dit tweede opslagaccount.
      Tweede opslagsleutel Kies de primaire sleutel of secundaire sleutel die u wilt gebruiken. Dit item wordt alleen weergegeven als u verificatie van de opslagsleutel hebt gekozen. Als de opslagsleutel opnieuw wordt gegenereerd, moet u de sleutel opnieuw configureren.
  3. Voltooi alle tabbladen en voltooi het maken van de cache door de rest van de instructies in quickstart te volgen: Een opensource Redis-cache maken.

Met RDB-persistentie begint de eerste back-up zodra de frequentieperiode voor de back-up is verstreken.

Met AOF-persistentie worden schrijfbewerkingen naar de cache opgeslagen in het benoemde opslagaccount of -accounts. Als er een onherstelbare fout optreedt die zowel de primaire als de replicacaches uitvalt, wordt het opgeslagen AOF-logboek gebruikt om de cache opnieuw te bouwen.

Persistentie van gegevens instellen met behulp van Azure PowerShell

U kunt Azure PowerShell gebruiken om persistentie van gegevens in te stellen wanneer u een Azure Redis Premium- of Enterprise-laag-cache maakt, of om persistentie toe te voegen aan een eerder gemaakte cache.

U kunt de opdracht New-AzRedisCache gebruiken om een nieuwe Azure Redis Premium-laag-cache te maken die gebruikmaakt van gegevenspersistentie.

Als u bestaande caches wilt bijwerken om gegevenspersistentie te gebruiken, voert u de opdracht Set-AzRedisCache uit. Zie Persistentie toevoegen aan een bestaande cache voor instructies.

Persistentie van gegevens instellen met behulp van Azure CLI

U kunt Azure CLI gebruiken om gegevenspersistentie in te stellen wanneer u een Azure Redis Premium- of Enterprise-laag-cache maakt, of om persistentie toe te voegen aan een eerder gemaakte cache.

U kunt de opdracht az redis create gebruiken om een nieuwe Premium-tier-cache te maken die gebruikmaakt van gegevenspersistentie. Voorbeeld:

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

Als u een bestaande cache wilt bijwerken, gebruikt u de opdracht az redis update . Voorbeeld:

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"

Veelgestelde vragen over persistentie

Deze sectie bevat antwoorden op veelgestelde vragen over persistentie van Azure Redis Cache.

RDB-persistentie

AOF-persistentie

Kan ik persistentie inschakelen voor een eerder gemaakte cache?

Ja, u kunt persistentie configureren bij het maken van de cache en op bestaande Premium-, Enterprise- of Enterprise Flash-caches.

Kan ik tegelijkertijd AOF- en RDB-persistentie inschakelen?

Nee, u kunt RDB of AOF inschakelen, maar niet beide tegelijk.

Hoe werkt persistentie met geo-replicatie?

Gegevenspersistentie werkt niet met geo-replicatie ingeschakeld.

Welk persistentiemodel moet ik kiezen?

AOF-persistentie schrijft één keer per seconde naar een logboek, terwijl RDB-persistentie back-ups opslaat op basis van het geconfigureerde back-upinterval. RDB-persistentie heeft minder invloed op doorvoer en prestaties dan AOF-persistentie.

Kies AOF-persistentie als uw primaire doel is om gegevensverlies te minimaliseren en u kunt een lagere doorvoer voor uw cache afhandelen. Kies RDB-persistentie als u optimale doorvoer in uw cache wilt behouden, maar toch een mechanisme voor gegevensherstel wilt.

Zie RDB-voordelen, RDB-nadelen, AOF-voordelen en AOF-nadelen voor meer informatie.

Heeft AOF-persistentie invloed op doorvoer, latentie of prestaties van mijn cache?

AOF-persistentie is van invloed op doorvoer. Omdat AOF wordt uitgevoerd op zowel het primaire als het replicaproces, ziet u hogere CPU- en serverbelasting voor een cache met AOF-persistentie dan op een identieke cache zonder AOF-persistentie. AOF biedt de beste consistentie met de gegevens in het geheugen, omdat elke schrijf- en verwijderbewerking met slechts een paar seconden vertraging behouden blijft. Het nadeel is dat AOF rekenintensief is.

Zolang CPU- en serverbelasting beide minder dan 90%zijn, is er een prestatievermindering voor de doorvoer, maar de cache werkt normaal. Boven de 90% CPU- en serverbelasting kan de doorvoerstraf hoger worden en neemt de latentie van alle opdrachten die door de cache worden verwerkt toe. Latentie neemt toe omdat AOF-persistentie wordt uitgevoerd op zowel het primaire proces als het replicaproces, waardoor de belasting van het knooppunt in gebruik wordt verhoogd en persistentie wordt geplaatst op het kritieke pad van gegevens.

Wat gebeurt er als ik naar een andere grootte schaal en er een back-up wordt hersteld die vóór de schaalaanpassing is gemaakt?

  • Als u naar een groter formaat hebt geschaald, is er geen effect.
  • Als u schaalt naar een kleiner formaat en u een aangepaste databaseinstelling hebt die groter is dan de limiet voor databases voor uw nieuwe grootte, worden gegevens in deze databases niet hersteld. Voor meer informatie, zie Wordt de instelling van mijn aangepaste databases beïnvloed tijdens het schalen?
  • Als u naar een kleiner formaat hebt geschaald en er onvoldoende ruimte is in de kleinere grootte om alle gegevens uit de laatste back-up op te bewaren, worden sleutels verwijderd tijdens het herstelproces. Sleutels worden meestal verwijderd met behulp van het allkeys-lru-verwijderingsbeleid.

Kan ik hetzelfde opslagaccount gebruiken voor persistentie in twee verschillende caches?

Nee, u moet verschillende opslagaccounts gebruiken. Elke cache moet een eigen opslagaccount hebben om voor persistentie in te stellen.

Belangrijk

Gebruik ook afzonderlijke opslagaccounts voor persistentie en het uitvoeren van periodieke exportbewerkingen op een cache.

Worden er kosten in rekening gebracht voor de opslag die wordt gebruikt in gegevenspersistentie?

  • Voor Premium-caches worden kosten in rekening gebracht voor de opslag die wordt gebruikt volgens het prijsmodel van het opslagaccount.
  • Voor Enterprise- en Enterprise Flash-caches is de opslag van beheerde schijven inbegrepen in de prijs en worden er geen extra kosten in rekening gebracht.

Hoe vaak schrijven RDB en AOF-persistentie naar mijn blobs, en moet ik soft delete inschakelen?

RDB en AOF-persistentie kunnen net zo vaak als elk uur, om de paar minuten of elke seconde naar uw opslagblobs schrijven. Zacht verwijderen wordt snel duur met de typische gegevensgrootten van een cache die ook elke seconde schrijfbewerkingen uitvoert. Als u voorlopig verwijderen inschakelt voor een opslagaccount, betekent dit ook dat Azure Redis de opslagkosten niet kan minimaliseren door de oude back-upgegevens te verwijderen.

Het is raadzaam om voorlopig verwijderen niet in te schakelen voor opslagaccounts die u gebruikt voor de gegevenspersistentie in de Premium-laag van Azure Redis. Zie Prijzen en facturering voor meer informatie over de kosten van zachte verwijdering.

Kan ik de frequentie van de RDB-back-up wijzigen nadat ik de cache heb gemaakt?

Ja, u kunt de back-upfrequentie voor RDB-persistentie wijzigen met behulp van Azure Portal, Azure CLI of Azure PowerShell.

Waarom zit er meer dan 60 minuten tussen back-ups wanneer ik een RDB-back-upfrequentie van 60 minuten heb?

Het frequentieinterval van de RDB-persistentieback-up start pas wanneer het vorige back-upproces succesvol is voltooid. Als de back-upfrequentie 60 minuten is en het 15 minuten duurt voordat het back-upproces is voltooid, wordt de volgende back-up pas 75 minuten na de begintijd van de vorige back-up gestart.

Wat gebeurt er met de oude RDB-back-ups wanneer er een nieuwe back-up wordt gemaakt?

Alle RDB-persistentieback-ups, met uitzondering van de meest recente back-ups, worden automatisch verwijderd. Deze verwijdering wordt mogelijk niet onmiddellijk uitgevoerd, maar oudere back-ups blijven niet voor onbepaalde tijd behouden. Als u de Premium-laag gebruikt voor persistentie en voorlopig verwijderen is ingeschakeld voor uw opslagaccount, blijven de bestaande back-ups zich in de status Voorlopig verwijderen bevinden.

Wanneer moet ik een tweede opslagaccount gebruiken?

Gebruik een tweede opslagaccount voor AOF-persistentie wanneer u verwacht dat deze hoger is dan gebruikelijke SET-bewerkingen in de cache. Door het secundaire opslagaccount te gebruiken, zorgt u ervoor dat uw cache geen limieten voor de opslagbandbreedte bereikt. Deze optie is alleen beschikbaar voor Caches in de Premium-laag.

Hoe kan ik het tweede opslagaccount verwijderen?

U kunt het secundaire AOF-opslagaccount verwijderen door het tweede opslagaccount in te stellen op hetzelfde als het eerste opslagaccount. Als u de instellingen voor bestaande caches wilt wijzigen, selecteert u Gegevenspersistentie onder Instellingen in het linkernavigatiemenu van uw cachepagina. Als u persistentie volledig wilt uitschakelen, selecteert u Uitgeschakeld op de pagina Gegevenspersistentie .

Wat is een herschrijfwijze en hoe heeft dit invloed op mijn cache?

Wanneer een AOF-bestand groot genoeg wordt, wordt automatisch een hergeschreven bestand in de wachtrij in de cache geplaatst. Het herschrijven wijzigt de grootte van het AOF-bestand met de minimale set bewerkingen die nodig zijn om de huidige gegevensset te maken.

Tijdens het herschrijven kunt u verwachten dat u sneller prestatielimieten bereikt, met name bij het omgaan met grote gegevenssets. Herschrijven vindt minder vaak plaats omdat het AOF-bestand groter wordt, maar het duurt veel tijd wanneer ze plaatsvinden.

Wat moet ik verwachten bij het schalen van een cache met AOF ingeschakeld?

Als het AOF-bestand op het moment van schalen groot is, verwacht u dat de schaalbewerking langer duurt dan normaal, omdat het bestand opnieuw wordt geladen nadat het schalen is voltooid. Zie ook Wat gebeurt er als ik naar een andere grootte schaal en een back-up wordt hersteld die vóór de schaalbewerking is gemaakt?

Hoe worden mijn AOF-gegevens geordend in de opslag?

Wanneer u de Premium-laag gebruikt, worden gegevens die zijn opgeslagen in AOF-bestanden onderverdeeld in meerdere pagina-blobs per shard. Standaard worden de helft van de blobs opgeslagen in het primaire opslagaccount en worden de helft opgeslagen in het secundaire opslagaccount. Het splitsen van de gegevens over meerdere pagina-blobs en twee verschillende opslagaccounts verbetert de prestaties.

Als de pieksnelheid van schrijfbewerkingen naar de cache niet hoog is, zijn deze extra prestaties mogelijk niet nodig. In dat geval kan de configuratie van het secundaire opslagaccount worden verwijderd, en kunnen alle AOF-bestanden in het ene primaire opslagaccount worden opgeslagen. In de volgende tabel ziet u hoeveel pagina-blobs elke prijscategorie gebruikt.

Premium-laag Blobsen
P1 8 per fragment
P2 16 per deel
Blz. 3 32 per onderdeel
P4 40 per schijf

Wanneer clustering is ingeschakeld, heeft elke shard in de cache een eigen set pagina-blobs, volgens de voorgaande tabel. Een P2-cache met drie shards verdeelt het AOF-bestand bijvoorbeeld over 48 pagina-blobs: Zestien blobs per shard, met drie shards.

Na het herschrijven bestaan er twee sets AOF-bestanden in de opslag. Herschrijven vindt plaats op de achtergrond en wordt toegevoegd aan de eerste set bestanden. SET-bewerkingen die tijdens het herschrijven naar de cache worden verzonden, worden toegevoegd aan de tweede set bestanden.

Als er een fout optreedt tijdens het herschrijven, wordt een back-up tijdelijk opgeslagen. De back-up wordt onmiddellijk verwijderd nadat het herschrijven is voltooid. Als voorlopig verwijderen is ingeschakeld voor uw opslagaccount, is de instelling voor voorlopig verwijderen van toepassing en blijven bestaande back-ups de status Voorlopig verwijderen behouden.

Hebben firewall-uitzonderingen op het opslagaccount invloed op persistentie?

Ja. Voor persistentie in de Premium-laag kan het gebruik van firewallinstellingen in het opslagaccount verhinderen dat de persistentiefunctie werkt.

U kunt controleren op fouten in persistente gegevens door de metriek Fouten weer te geven. Deze metrische waarde geeft aan of de cache geen gegevens kan persistent maken vanwege firewallbeperkingen voor het opslagaccount of andere problemen.

Als u gegevenspersistentie wilt gebruiken met een opslagaccount dat een firewall heeft ingesteld, gebruikt u verificatie op basis van beheerde identiteit om verbinding te maken met opslag. Met beheerde identiteit wordt het cache-exemplaar toegevoegd aan de lijst met vertrouwde services, waardoor firewall-uitzonderingen eenvoudiger kunnen worden toegepast. Als u het opslagaccount autoriseert met behulp van een sleutel in plaats van een beheerde identiteit, wordt het persistentieproces meestal verbroken door firewall-uitzonderingen op het opslagaccount.

Kan ik AOF-persistentie inschakelen als ik meer dan één replica heb?

Met de Premium-laag kunt u AOF-persistentie niet gebruiken met meerdere replica's. In de Enterprise- en Enterprise Flash-lagen is de replicaarchitectuur ingewikkelder, maar AOF-persistentie wordt ondersteund wanneer Enterprise-caches worden gebruikt in zone-redundante implementaties.

Hoe kan ik controleren of voorlopig verwijderen is ingeschakeld voor mijn opslagaccount?

Selecteer in Azure Portal het opslagaccount dat uw cache gebruikt voor persistentie en selecteer gegevensbeveiliging onder Gegevensbeheer in het linkernavigatiemenu. Controleer op de pagina Gegevensbeveiliging of Voorlopig verwijderen inschakelen voor blobs is ingeschakeld. Zie Voorlopig verwijderen inschakelen voor blobs voor meer informatie over voorlopig verwijderen in Azure-opslagaccounts.

Kan ik een opslagaccount in een ander abonnement gebruiken dan het account waar mijn cache zich bevindt?

U kunt alleen een opslagaccount in een ander abonnement kiezen als u beheerde identiteit als verificatiemethode voor het opslagaccount gebruikt.

Meer informatie over Azure Cache voor Redis functies.