Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
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 .
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.
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.
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.
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.
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.
Veelgestelde vragen over persistentie
Deze sectie bevat antwoorden op veelgestelde vragen over persistentie van Azure Redis Cache.
- Kan ik persistentie inschakelen voor een bestaande cache?
- Kan ik zowel AOF- als RDB-persistentie inschakelen?
- Werkt persistentie met geo-replicatie?
- Welk persistentiemodel moet ik kiezen?
- Wat gebeurt er als ik naar een andere grootte schaal en een back-up van vóór de schaalbewerking wordt hersteld?
- Kan ik hetzelfde opslagaccount gebruiken voor persistentie in twee verschillende caches?
- Worden er kosten in rekening gebracht voor het gebruik van opslaggegevenspersistentie?
- Hoe vaak schrijven RDB- en AOF-persistentiemethoden naar het opslagmedium? Moet ik zacht verwijderen inschakelen?
- Zijn firewall-uitzonderingen op het opslagaccount van invloed op persistentie?
- Hoe kan ik controleren of voorlopig verwijderen is ingeschakeld voor mijn opslagaccount?
- Kan ik een opslagaccount in een ander abonnement gebruiken dan het account waar mijn cache zich bevindt?
RDB-persistentie
- Kan ik de frequentie van de RDB-back-up wijzigen nadat ik de cache heb gemaakt?
- Waarom zijn er meer dan 60 minuten tussen back-ups wanneer ik een RDB-back-upfrequentie van 60 minuten heb?
- Wat gebeurt er met de oude RDB-back-ups wanneer er een nieuwe back-up wordt gemaakt?
AOF-persistentie
- Wanneer moet ik een tweede opslagaccount gebruiken?
- Heeft AOF-persistentie invloed op cachedoorvoer, latentie of prestaties?
- Hoe kan ik het tweede opslagaccount verwijderen?
- Wat is een herschrijfwijze en hoe heeft dit invloed op mijn cache?
- Wat moet ik verwachten bij het schalen van een cache met AOF ingeschakeld?
- Hoe worden mijn AOF-gegevens geordend in de opslag?
- Kan ik AOF-persistentie inschakelen als ik meer dan één replica heb?
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.
Verwante inhoud
Meer informatie over Azure Cache voor Redis functies.