Gegevenspersistentie configureren voor een Azure Managed Redis (preview)-exemplaar
Redis-persistentie waarmee u in het cache-exemplaar opgeslagen gegevens persistent kunt maken. Als er een hardwarefout optreedt, wordt het cache-exemplaar gerehydrateerd met gegevens uit het persistentiebestand wanneer het weer online komt. 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. Gegevensverlies is mogelijk als er een fout optreedt wanneer cacheknooppunten niet beschikbaar zijn. Persistentie moet een belangrijk onderdeel zijn van uw strategie voor hoge beschikbaarheid en herstel na noodgevallen met Azure Managed Redis (preview).
Belangrijk
Gegevenspersistentie is bedoeld om tolerantie te bieden voor onverwachte Redis-knooppuntfouten, maar het is geen functie voor gegevensback-up of herstel naar een bepaald tijdstip. Als beschadigde gegevens naar het Redis-exemplaar worden geschreven, worden deze gegevens ook bewaard. Als u back-ups van uw Redis-exemplaar wilt maken, gebruikt u de exportfunctie.
Bereik van beschikbaarheid
| Laag | Geoptimaliseerd voor geheugen, evenwichtig, met geoptimaliseerde rekenkracht | Flash geoptimaliseerd |
|---|---|---|
| Beschikbaar | Ja | Ja |
Typen gegevenspersistentie in Redis
U hebt twee opties voor persistentie met Azure Managed Redis: de indeling Redis-database (RDB) en de AOF-indeling (Append only File ):
- RDB-persistentie : wanneer u RDB-persistentie gebruikt, behoudt Azure Managed Redis een momentopname van uw cache in een binaire indeling. De momentopname wordt opgeslagen op een beheerde schijf die is gekoppeld aan het Redis-exemplaar. De configureerbare back-upfrequentie bepaalt hoe vaak de momentopname moet worden bewaard. Als er een onherstelbare gebeurtenis optreedt die zowel de primaire als de replica uitschakelt, wordt de cache automatisch gereconstrueerd met behulp van de meest recente momentopname. Meer informatie over de voordelen en nadelen van RDB-persistentie.
- AOF-persistentie: wanneer u AOF-persistentie gebruikt, slaat Azure Managed Redis elke schrijfbewerking op in een logboek. Het logboek wordt eenmaal per seconde opgeslagen op een beheerde schijf die is gekoppeld aan het Redis-exemplaar. 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. Meer informatie over de voordelen en nadelen van AOF-persistentie.
Belangrijk
Azure Managed Redis-persistentiefuncties zijn bedoeld om gegevens automatisch te herstellen naar dezelfde cache na gegevensverlies. De persistente RDB/AOF-gegevensbestanden kunnen niet worden geopend door gebruikers of worden geïmporteerd in een nieuwe of bestaande cache. Gebruik de functie Importeren en exporteren om gegevens over caches te verplaatsen. Zie Gegevens importeren en exporteren in Azure Managed Redis voor meer informatie.
Als u back-ups van gegevens wilt genereren die kunnen worden toegevoegd aan een nieuwe cache, kunt u geautomatiseerde scripts schrijven met behulp van PowerShell of Azure CLI waarmee gegevens periodiek worden geëxporteerd.
Vereisten en beperkingen
Persistentiefuncties zijn bedoeld om gegevens na gegevensverlies te herstellen naar dezelfde cache.
- Persistente RDB/AOF-gegevensbestanden kunnen niet worden geïmporteerd in een nieuwe cache of de bestaande cache. Gebruik in plaats daarvan de functie Importeren/exporteren.
- Persistentie wordt niet ondersteund met caches met actieve geo-replicatie.
- De beheerde schijf met persistente gegevensbestanden wordt standaard versleuteld met Microsoft beheerde sleutels (MMK), maar door de klant beheerde sleutels (CMK) kunnen ook worden gebruikt. Zie Gegevensversleuteling beheren voor meer informatie.
Gegevenspersistentie instellen met behulp van Azure Portal
Meld u aan bij Azure Portal en volg de instructies in de snelstartgids voor Azure Managed Redis.
Wanneer u het tabblad Geavanceerd bereikt, selecteert u RDB - of AOF-opties in de sectie Gegevenspersistentie .
Als u RDB-persistentie wilt inschakelen, selecteert u RDB en configureert u de instellingen.
Instelling Voorgestelde waarde Beschrijving Back-upfrequentie Gebruik de vervolgkeuzelijst en selecteer een back-upinterval. U kunt kiezen uit 60 minuten, 6 uur en 12 uur. Dit interval begint af te tellen nadat de vorige back-upbewerking is voltooid. Wanneer deze is verstreken, wordt een nieuwe back-up gestart. Als u AOF-persistentie wilt inschakelen, selecteert u AOF. Er is slechts één optie voor back-upfrequentie beschikbaar.
Voltooi het maken van de cache door de rest van de instructies in de snelstartgids voor Azure Managed Redis te volgen.
Notitie
U kunt persistentie op elk gewenst moment toevoegen aan een eerder gemaakt Azure Managed Redis-exemplaar door te navigeren naar de geavanceerde instellingen in het menu Resource.
Gegevenspersistentie instellen met Behulp van PowerShell en Azure CLI
PowerShell gebruiken
De opdracht New-AzRedisEnterpriseCache kan worden gebruikt om een nieuw Azure Managed Redis-exemplaar te maken met behulp van gegevenspersistentie. Gebruik de RdbPersistenceEnabledparameters , RdbPersistenceFrequencyen AofPersistenceEnabledAofPersistenceFrequency parameters om de persistentie-installatie te configureren. In dit voorbeeld wordt een nieuw exemplaar van Balanced B10 gemaakt met behulp van RDB-persistentie met een frequentie van één uur:
New-AzRedisEnterpriseCache -Name "MyCache" -ResourceGroupName "MyGroup" -Location "West US" -Sku "Balanced_B10" -RdbPersistenceEnabled -RdbPersistenceFrequency "1h"
Bestaande caches kunnen worden bijgewerkt met behulp van de opdracht Update-AzRedisEnterpriseCacheDatabase . In dit voorbeeld wordt RDB-persistentie met een frequentie van 12 uur toegevoegd aan een bestaand exemplaar:
Update-AzRedisEnterpriseCacheDatabase -Name "MyCache" -ResourceGroupName "MyGroup" -RdbPersistenceEnabled -RdbPersistenceFrequency "12h"
Azure CLI gebruiken
De opdracht az redisenterprise create kan worden gebruikt om een nieuw Azure Managed Redis-exemplaar te maken met behulp van gegevenspersistentie. Gebruik de rdb-enabledparameters , rdb-frequencyen aof-enabledaof-frequency parameters om de persistentie-installatie te configureren. In dit voorbeeld wordt een nieuw exemplaar van Balanced B10 gemaakt met behulp van RDB-persistentie met een frequentie van één uur:
az redisenterprise create --cluster-name "cache1" --resource-group "rg1" --location "East US" --sku "Balanced_B10" --persistence rdb-enabled=true rdb-frequency="1h"
Bestaande caches kunnen worden bijgewerkt met behulp van de opdracht az redisenterprise database update . In dit voorbeeld wordt RDB-persistentie met een frequentie van 12 uur toegevoegd aan een bestaand cache-exemplaar:
az redisenterprise database update --cluster-name "cache1" --resource-group "rg1" --persistence rdb-enabled=true rdb-frequency="12h"
Gegevensversleuteling beheren
Omdat Redis persistentie data-at-rest maakt, is het versleutelen van deze gegevens een belangrijke zorg voor veel gebruikers. In Azure Managed Redis worden gegevens opgeslagen op een beheerde schijf die is gekoppeld aan het cache-exemplaar. De schijf met de persistentiegegevens en de besturingssysteemschijf worden standaard versleuteld met door Microsoft beheerde sleutels. Een door de klant beheerde sleutel (CMK) kan ook worden gebruikt om gegevensversleuteling te beheren. Zie Versleuteling in Azure Managed Redis voor instructies.
Veelgestelde vragen over persistentie
De volgende lijst bevat antwoorden op veelgestelde vragen over het schalen van Azure Managed Redis-persistentie.
- Kan ik persistentie inschakelen voor een eerder gemaakte cache?
- Kan ik tegelijkertijd AOF- en RDB-persistentie inschakelen?
- Hoe werkt persistentie met geo-replicatie?
- Welk persistentiemodel moet ik kiezen?
- Wat gebeurt er als ik naar een andere grootte heb geschaald en er een back-up wordt hersteld die is gemaakt vóór de schaalbewerking?
- Worden er kosten in rekening gebracht voor de beheerde schijf die wordt gebruikt in Gegevenspersistentie
RDB-persistentie
- Kan ik de frequentie van de RDB-back-up wijzigen nadat ik de cache heb gemaakt?
- Waarom zit 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
- Heeft AOF-persistentie invloed op doorvoer, latentie of prestaties van mijn cache?
- 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?
Kan ik persistentie inschakelen voor een eerder gemaakte cache?
Ja, persistentie kan worden geconfigureerd bij het maken van de cache en bij bestaande Azure Managed Redis-exemplaren.
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?
Als u gegevenspersistentie inschakelt, kan geo-replicatie niet worden ingeschakeld voor uw cache. Dit komt doordat actieve geo-replicatie een betere tolerantie biedt dan gegevenspersistentie in het geval van een regionale storing. Als u een kopie van uw gegevens als back-up wilt exporteren, gebruikt u in plaats daarvan de exportfunctie.
Welk persistentiemodel moet ik kiezen?
AOF-persistentie slaat elke schrijfbewerking op in een logboek, wat een aanzienlijk effect kan hebben op de doorvoer. RDB-persistentie slaat back-ups op op basis van het geconfigureerde back-upinterval met minimale gevolgen voor prestaties. Kies AOF-persistentie als uw primaire doel is om gegevensverlies te minimaliseren en een lagere doorvoer voor uw cache geen probleem is. Kies RDB-persistentie als u optimale doorvoer in uw cache wilt behouden, maar toch een mechanisme voor gegevensherstel wilt.
- Meer informatie over de voordelen en nadelen van RDB-persistentie.
- Meer informatie over de voordelen en nadelen van AOF-persistentie.
Zie voor meer informatie over prestaties bij het gebruik van AOF-persistentie Heeft AOF-persistentie invloed op doorvoer, latentie of prestaties van mijn cache?
Heeft AOF-persistentie invloed op doorvoer, latentie of prestaties van mijn cache?
Het gebruik van AOF-persistentie heeft invloed op de doorvoer. AOF wordt uitgevoerd op alle primaire processen. Daarom ziet u een hogere CPU- en serverbelasting voor een cache met AOF-persistentie dan 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. De afweging is dat AOF rekenintensief is.
Wat gebeurt er als ik naar een andere grootte heb geschaald en er een back-up wordt hersteld die is gemaakt vóór de schaalbewerking?
Voor zowel RDB- als AOF-persistentie:
- Als u naar een groter formaat hebt geschaald, is er geen effect.
- 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 te bewaren, worden sleutels verwijderd tijdens het herstelproces. Sleutels worden meestal verwijderd met behulp van het allkeys-lru-verwijderingsbeleid.
Worden er kosten in rekening gebracht voor de beheerde schijf die wordt gebruikt in gevenspersistentie?
Er worden geen kosten in rekening gebracht voor de opslag van beheerde schijven. Het is inbegrepen in de prijs.
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, CLI of PowerShell.
Waarom zit er meer dan 60 minuten tussen back-ups wanneer ik een RDB-back-upfrequentie van 60 minuten heb?
Het interval voor de frequentie van de RDB-persistentieback-up wordt pas gestart nadat het vorige back-upproces 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.
Wat is een herschrijfwijze en hoe heeft dit invloed op mijn cache?
Wanneer het AOF-bestand groot genoeg wordt, wordt automatisch een herschrijving in de wachtrij op 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 dit gebeurt.
Wat moet ik verwachten bij het schalen van een cache met AOF ingeschakeld?
Als het AOF-bestand op het moment van schalen groot is, kunt u verwachten dat de schaalbewerking langer duurt dan normaal, omdat het bestand opnieuw wordt geladen nadat het schalen is voltooid.
Zie voor meer informatie over schalen Wat gebeurt er als ik naar een andere grootte heb geschaald en een back-up wordt hersteld die is gemaakt vóór de schaalbewerking?