Dela via

Konfigurera datapersistence för en Azure Cache for Redis-instans

  • Artikel

Redis-beständighet gör att du kan bevara data som lagras i cacheinstansen. Om det uppstår ett maskinvarufel extraheras cacheinstansen med data från beständighetsfilen när den är online igen. Möjligheten att spara data beständigt är ett viktigt sätt att öka hållbarheten hos en cacheinstans eftersom alla cachedata lagras i minnet. Dataförlust kan inträffa om ett fel uppstår när cachenoderna ligger nere. Beständighet bör vara en viktig del av din strategi för hög tillgänglighet och haveriberedskap med Azure Cache for Redis.

Varning

Om du använder beständighet på Premium-nivån kontrollerar du om ditt lagringskonto har mjuk borttagning aktiverat innan du använder funktionen för datapersistence. Användning av datapersistens med mjuk borttagning orsakar mycket höga lagringskostnader. Mer information finns i ska jag aktivera mjuk borttagning?.

Varning

Alternativet skriv alltid för AOF-beständighet på Enterprise- och Enterprise Flash-nivåerna är inställt på att dras tillbaka den 1 april 2025. Det här alternativet har betydande prestandabegränsningar rekommenderas inte längre. Använd alternativet skriv varje sekund eller använd RDB-persistens i stället.

Tillgänglighet

Nivå Basic, Standard Premium Enterprise, Enterprise Flash
Tillgängligt Nej Ja Ja (förhandsversion)

Typer av datapersistence i Redis

Du har två alternativ för beständighet med Azure Cache for Redis: Redis-databasformatet (RDB) och AOF-formatet (Append Only File ):

  • RDB-persistens – När du använder RDB-persistens bevarar Azure Cache for Redis en ögonblicksbild av cacheminnet i binärt format. Ögonblicksbilden sparas i ett Azure Storage-konto. Den konfigurerbara säkerhetskopieringsfrekvensen avgör hur ofta ögonblicksbilden ska sparas. Om en katastrofal händelse inträffar som inaktiverar både den primära cachen och replikcachen rekonstrueras cachen automatiskt med hjälp av den senaste ögonblicksbilden. Läs mer om fördelarna och nackdelarna med RDB-beständighet.
  • AOF-persistens – När du använder AOF-beständighet sparar Azure Cache for Redis varje skrivåtgärd i en logg. Loggen sparas minst en gång per sekund i ett Azure Storage-konto. Om en oåterkallelig händelse inträffar som inaktiverar både den primära cachen och replikcachen rekonstrueras cachen automatiskt med hjälp av de lagrade skrivåtgärderna. Läs mer om fördelarna och nackdelarna med AOF-beständighet.

Azure Cache for Redis-beständighetsfunktioner är avsedda att användas för att återställa data automatiskt till samma cache efter dataförlust. RDB/AOF-lagrade datafiler kan inte importeras till en ny cache eller befintlig cache. Om du vill flytta data mellan cacheminnen kan du använda funktionen Importera och exportera. Mer information finns i Importera och exportera data i Azure Cache for Redis.

Om du vill generera säkerhetskopior av data som kan läggas till i en ny cache kan du skriva automatiserade skript med hjälp av PowerShell eller CLI som exporterar data med jämna mellanrum.

Förutsättningar och begränsningar

Beständighetsfunktioner är avsedda att användas för att återställa data till samma cacheminne efter dataförlust.

  • RDB/AOF-beständiga datafiler kan inte importeras till en ny eller befintlig cache. Använd funktionen Importera/exportera i stället.
  • Beständighet stöds inte med cacheminnen med passiv geo-replikering eller aktiv geo-replikering.
  • På Premium-nivån stöds inte AOF-persistens med flera repliker.
  • På Premium-nivån måste data sparas till ett lagringskonto i samma region som cacheinstansen.
  • På Premium-nivån kan lagringskonton i olika prenumerationer användas för att spara data om hanterad identitet används för att ansluta till lagringskontot.

Skillnader mellan beständighet på Premium- och Enterprise-nivåerna

På Premium-nivån sparas data direkt till ett Azure Storage-konto som du äger och hanterar. Azure Storage krypterar automatiskt data när de sparas, men du kan också använda dina egna nycklar för krypteringen. Mer information finns i Kundhanterade nycklar för Azure Storage-kryptering.

Varning

Om du använder beständighet på Premium-nivån kontrollerar du om ditt lagringskonto har mjuk borttagning aktiverat innan du använder funktionen för datapersistence. Användning av datapersistens med mjuk borttagning orsakar mycket höga lagringskostnader. Mer information finns i ska jag aktivera mjuk borttagning?.

På Enterprise- och Enterprise Flash-nivåerna sparas data till en hanterad disk som är ansluten direkt till cacheinstansen. Platsen är inte konfigurerbar eller tillgänglig för användaren. Om du använder en hanterad disk ökar beständighetens prestanda. Disken krypteras med microsofts hanterade nycklar (MMK) som standard, men kundhanterade nycklar (CMK) kan också användas. Mer information finns i Hantera datakryptering.

Konfigurera datapersistence med hjälp av Azure Portal

  1. Om du vill skapa en Premium-cache loggar du in på Azure Portal och väljer Skapa en resurs. Du kan skapa cacheminnen i Azure Portal. Du kan också skapa dem med Hjälp av Resource Manager-mallar, PowerShell eller Azure CLI.

    Skärmbild som visar ett formulär för att skapa en Azure Cache for Redis-resurs.

  2. På sidan Skapa en resurs väljer du Databaser och sedan Azure Cache for Redis.

    Skärmbild som visar Azure Cache for Redis vald som en ny databastyp.

  3. På sidan Ny Redis Cache konfigurerar du inställningarna för din nya Premium-cache.

    Inställning Föreslaget värde beskrivning
    DNS-namn Ange ett globalt unikt namn. Cachenamnet måste vara en sträng mellan 1 och 63 tecken som endast innehåller siffror, bokstäver eller bindestreck. Namnet måste börja och sluta med ett tal eller en bokstav och får inte innehålla bindestreck i följd. Värdnamnet för cacheinstansen är \<DNS name>.redis.cache.windows.net.
    Abonnemang Listrutan och välj din prenumeration. Prenumerationen som den nya Azure Cache for Redis-instansen ska skapas under.
    Resursgrupp Listrutan och välj en resursgrupp, eller välj Skapa ny och ange ett nytt resursgruppsnamn. Namn på den resursgrupp där cacheminnet och andra resurser ska skapas. Genom att placera alla dina appresurser i en resursgrupp kan du enkelt hantera eller ta bort dem tillsammans.
    Plats Listrutan och välj en plats. Välj en region nära andra tjänster som använder din cache.
    Cachetyp Listrutan och välj en Premium-cache för att konfigurera Premium-funktioner. Mer information finns i Priser för Azure Cache for Redis. Prisnivån avgör storlek, prestanda och funktioner som är tillgängliga för cacheminnet. Mer information finns i Översikt över Azure Cache for Redis.

  4. Välj fliken Nätverk eller välj knappen Nätverk längst ned på sidan.

  5. På fliken Nätverk väljer du din anslutningsmetod. För Premium Cache-instanser ansluter du antingen offentligt, via offentliga IP-adresser eller tjänstslutpunkter. Du ansluter privat med en privat slutpunkt.

  6. Välj fliken Nästa: Avancerat eller välj knappen Nästa: Avancerat längst ned på sidan.

  7. På fliken Avancerat för en Premium Cache-instans konfigurerar du inställningarna för icke-TLS-port, klustring och datapersistence. För datapersistence kan du välja RDB- eller AOF-beständighet.

  8. Om du vill aktivera RDB-persistens väljer du RDB och konfigurerar inställningarna.

    Inställning Föreslaget värde beskrivning
    Autentiseringsmetod Listrutan och välj en autentiseringsmetod. Alternativen är Hanterad identitet eller lagringsnyckel Välj önskad autentiseringsmetod. Med hanterad identitet kan du använda ett lagringskonto i en annan prenumeration än den där cachen finns.
    Abonnemang Listrutan och välj en prenumeration. Du kan välja ett lagringskonto i en annan prenumeration om du använder hanterad identitet som autentiseringsmetod.
    Säkerhetskopieringsfrekvens Listrutan och välj ett säkerhetskopieringsintervall. Alternativen omfattar 15 minuter, 30 minuter, 60 minuter, 6 timmar, 12 timmar och 24 timmar. Det här intervallet börjar räknas ned när den tidigare säkerhetskopieringen har slutförts. När den förflutit startar en ny säkerhetskopia.
    Lagringskonto Listrutan och välj ditt lagringskonto. Välj ett lagringskonto i samma region och prenumeration som cacheminnet. Ett Premium Storage-konto rekommenderas eftersom det har högre dataflöde. Vi rekommenderar också starkt att du inaktiverar funktionen för mjuk borttagning på lagringskontot eftersom det leder till ökade lagringskostnader. Mer information finns i Priser och fakturering.
    Lagringsnyckel Listrutan och välj antingen primärnyckeln eller sekundärnyckeln som ska användas. Om lagringsnyckeln för ditt beständighetskonto återskapas måste du konfigurera om nyckeln från listrutan Lagringsnyckel .

    Den första säkerhetskopieringen startar när intervallet för säkerhetskopieringsfrekvens förflutit.

    Kommentar

    När RDB-filer säkerhetskopieras till lagring lagras de i form av sidblobar. Om du använder ett lagringskonto med HNS aktiverat tenderar beständighet att misslyckas eftersom sidblobar inte stöds i lagringskonton med HNS aktiverat (ADLS Gen2).

  9. Om du vill aktivera AOF-persistence väljer du AOF och konfigurerar inställningarna.

    Inställning Föreslaget värde beskrivning
    Autentiseringsmetod Listrutan och välj en autentiseringsmetod. Alternativen är Hanterad identitet eller lagringsnyckel Välj önskad autentiseringsmetod. Med hanterad identitet kan du använda ett lagringskonto i en annan prenumeration än den där cachen finns.
    Abonnemang Listrutan och välj en prenumeration. Du kan välja ett lagringskonto i en annan prenumeration om du använder hanterad identitet som autentiseringsmetod.
    Första lagringskontot Listrutan och välj ditt lagringskonto. Välj ett lagringskonto i samma region och prenumeration som cacheminnet. Ett Premium Storage-konto rekommenderas eftersom det har högre dataflöde. Vi rekommenderar också starkt att du inaktiverar funktionen för mjuk borttagning på lagringskontot eftersom det leder till ökade lagringskostnader. Mer information finns i Priser och fakturering.
    Första lagringsnyckeln Listrutan och välj antingen primärnyckeln eller sekundärnyckeln som ska användas. Om lagringsnyckeln för ditt beständighetskonto återskapas måste du konfigurera om nyckeln från listrutan Lagringsnyckel .
    Second Storage-konto (Valfritt) Listrutan och välj ditt sekundära lagringskonto. Du kan också konfigurera ett annat lagringskonto. Om ett andra lagringskonto har konfigurerats skrivs skrivningar till replikcachen till det andra lagringskontot.
    Second Storage Key (Valfritt) Listrutan och välj antingen primärnyckeln eller sekundärnyckeln som ska användas. Om lagringsnyckeln för ditt beständighetskonto återskapas måste du konfigurera om nyckeln från listrutan Lagringsnyckel .

    När AOF-beständighet är aktiverat sparas skrivåtgärder till cacheminnet till det namngivna lagringskontot (eller konton om du har konfigurerat ett andra lagringskonto). Om det uppstår ett oåterkalleligt fel som tar bort både den primära cachen och replikcachen används den lagrade AOF-loggen för att återskapa cachen.

  10. Välj fliken Nästa: Taggar eller välj knappen Nästa: Taggar längst ned på sidan.

  11. Du kan också ange namn och värde på fliken Taggar om du vill kategorisera resursen.

  12. Välj Granska + skapa. Du kommer till fliken Granska + skapa där Azure verifierar din konfiguration.

  13. När det gröna verifieringsmeddelandet har skickats väljer du Skapa.

Det tar en stund innan cacheminnet skapas. Du kan övervaka förloppet på översiktssidan för Azure Cache for Redis. När Status visas som Körs är cachen redo att användas.

Konfigurera datapersistence med hjälp av PowerShell och Azure CLI

Kommandot New-AzRedisCache kan användas för att skapa en ny Cache på Premium-nivå med hjälp av datapersistence. Se exempel på RDB-persistence och AOF-beständighet

Befintliga cacheminnen kan uppdateras med kommandot Set-AzRedisCache . Se exempel på hur du lägger till beständighet i en befintlig cache.

Kommandot az redis create kan användas för att skapa en ny Cache på Premium-nivå med hjälp av datapersistence. Till exempel:

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

Befintliga cacheminnen kan uppdateras med kommandot az redis update . Till exempel:

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"

Hantera datakryptering

Eftersom Redis persistence skapar vilande data är kryptering av dessa data ett viktigt problem för många användare. Krypteringsalternativen varierar beroende på vilken nivå av Azure Cache for Redis som används.

Med Premium-nivån strömmas data direkt från cacheinstansen till Azure Storage när beständighet initieras. Olika krypteringsmetoder kan användas med Azure Storage, inklusive Microsoft-hanterade nycklar, kundhanterade nycklar och kundspecifika nycklar. Information om krypteringsmetoder finns i Azure Storage-kryptering för vilande data.

Med Enterprise- och Enterprise Flash-nivåerna lagras data på en hanterad disk som monterats på cacheinstansen. Som standard krypteras disken som innehåller beständighetsdata och OS-disken med hjälp av Microsoft-hanterade nycklar. En kundhanterad nyckel (CMK) kan också användas för att styra datakryptering. Anvisningar finns i Kryptering på Enterprise-nivåcacheminnen .

Vanliga frågor och svar om beständighet

Följande lista innehåller svar på vanliga frågor om Azure Cache for Redis-beständighet.

RDB-beständighet

AOF-beständighet

Kan jag aktivera beständighet i en tidigare skapad cache?

Ja, beständighet kan konfigureras både när cacheminnet skapas och på befintliga Premium-, Enterprise- eller Enterprise Flash-cacheminnen.

Kan jag aktivera AOF- och RDB-beständighet samtidigt?

Nej, du kan aktivera RDB eller AOF, men inte båda samtidigt.

Hur fungerar beständighet med geo-replikering?

Om du aktiverar databeständighet är det inte möjligt att aktivera geo-replikering för din cache.

Vilken beständighetsmodell ska jag välja?

AOF-persistence sparar varje skrivning till en logg, vilket har en betydande effekt på dataflödet. Jämfört AOF med RDB-persistens, vilket sparar säkerhetskopieringar baserat på det konfigurerade säkerhetskopieringsintervallet med minimal effekt på prestanda. Välj AOF-beständighet om ditt primära mål är att minimera dataförlusten och du kan hantera ett lägre dataflöde för din cache. Välj RDB-beständighet om du vill behålla optimalt dataflöde i cachen men ändå vill ha en mekanism för dataåterställning.

Mer information om prestanda när du använder AOF-beständighet finns i Påverkar AOF-beständighet dataflöde, latens eller prestanda för min cache?.

Påverkar AOF-beständighet dataflöde, latens eller prestanda för min cache?

AOF-persistence påverkar dataflödet. AOF körs på både den primära processen och replikprocessen. Därför ser du högre PROCESSOR- och serverbelastning för en cache med AOF-beständighet än en identisk cache utan AOF-beständighet. AOF ger den bästa enhetligheten med data i minnet, eftersom varje skrivning och borttagning sparas med bara några sekunders fördröjning. Nackdelen är att AOF är mer beräkningsintensivt.

Så länge cpu- och serverbelastningen båda är mindre än 90 %, finns det en straffavgift för dataflödet, men cachen fungerar normalt, annars. Över 90 % cpu- och serverbelastning kan dataflödesstraffet bli mycket högre och svarstiden för alla kommandon som bearbetas av cachen ökar. Svarstiden ökar eftersom AOF-persistence körs på både den primära processen och replikprocessen, vilket ökar belastningen på den nod som används och lägger beständighet på den kritiska datasökvägen.

Vad händer om jag har skalat till en annan storlek och en säkerhetskopia återställs som gjordes före skalningsåtgärden?

Följande gäller både RDB- och AOF-beständighet:

  • Om du har skalat till en större storlek blir det ingen effekt.
  • Om du har skalat till en mindre storlek och du har en inställning för anpassade databaser som är större än databasgränsen för din nya storlek återställs inte data i dessa databaser. Mer information finns i Påverkas inställningen för mina anpassade databaser under skalningen?
  • Om du har skalat till en mindre storlek och det inte finns tillräckligt med utrymme för att lagra alla data från den senaste säkerhetskopieringen, avlägsnas nycklarna under återställningsprocessen. Vanligtvis avlägsnas nycklar med hjälp av avlägsningsprincipen allkeys-lru.

Kan jag använda samma lagringskonto för beständighet i två olika cacheminnen?

Nej, du måste använda olika lagringskonton för olika cacheminnen. Varje cache måste ha ett eget lagringskonto för att kunna konfigureras för beständighet.

Viktigt!

Använd separata lagringskonton för beständighet och utföra periodiska exportåtgärder i en cache.

Debiteras jag för lagringen som används i datapersistence?

  • För Premium-cacheminnen debiteras du för lagringen som används enligt prismodellen för det lagringskonto som används.
  • För Enterprise - och Enterprise Flash-cacheminnen debiteras du inte för den hanterade disklagringen. Det ingår i priset.

Hur ofta skrivs RDB- och AOF-beständighet till mina blobar och ska jag aktivera mjuk borttagning?

Vi rekommenderar att du undviker att aktivera mjuk borttagning på lagringskonton när de används med Azure Cache for Redis-datapersistence med Premium-nivån. RDB- och AOF-beständighet kan skriva till dina blobar så ofta som varje timme, med några minuters mellanrum eller varje sekund. Att aktivera mjuk borttagning på ett lagringskonto innebär också att Azure Cache for Redis inte kan minimera lagringskostnaderna genom att ta bort gamla säkerhetskopieringsdata.

Mjuk borttagning blir snabbt dyrt med de typiska datastorlekarna för ett cacheminne som också utför skrivåtgärder varje sekund. Mer information om kostnader för mjuk borttagning finns i Priser och fakturering.

Kan jag ändra RDB-säkerhetskopieringsfrekvensen efter att jag har skapat cachen?

Ja, du kan ändra säkerhetskopieringsfrekvensen för RDB-beständighet via Azure-portalen, CLI eller PowerShell.

Varför går det mer än 60 minuter mellan säkerhetskopieringar när jag har en RDB-säkerhetskopieringsfrekvens på 60 minuter?

Säkerhetskopieringsfrekvensen vid RDB-beständighet startar inte förrän föregående säkerhetskopieringsprocess har slutförts. Om säkerhetskopieringsfrekvensen är 60 minuter och det tar 15 minuter att slutföra säkerhetskopieringen, startar inte nästa säkerhetskopiering förrän 75 minuter efter starttiden för föregående säkerhetskopiering.

Vad händer med de gamla RDB-säkerhetskopiorna när det görs en ny säkerhetskopia?

Alla säkerhetskopieringar vid RDB-beständighet, utom de senaste, tas bort automatiskt. Denna borttagning kanske inte sker omedelbart, men äldre säkerhetskopior sparas inte beständigt under obestämd tid. Om du använder Premium-nivån för beständighet och mjuk borttagning är aktiverad för ditt lagringskonto gäller inställningen för mjuk borttagning och befintliga säkerhetskopior fortsätter att finnas i läget för mjuk borttagning.

När ska jag använda ett andra lagringskonto?

Använd ett andra lagringskonto för AOF-persistens när du tror att du har högre uppsättningsåtgärder än förväntat i cacheminnet. Genom att konfigurera det sekundära lagringskontot ser du till att cacheminnet inte når gränsen för lagringsbandbredd. Det här alternativet är endast tillgängligt för Premium-nivåcacheminnen.

Hur tar jag bort det andra lagringskontot?

Du kan ta bort det sekundära lagringskontot för AOF-beständighet genom att ange att det andra lagringskontot ska vara samma som det första lagringskontot. För befintliga cacheminnen får du åtkomst till Datapersistence från resursmenyn för din cache. Om du vill inaktivera AOF-beständighet väljer du Inaktiverad.

Vad är en omskrivning och hur påverkar den min cache?

När AOF-filen blir tillräckligt stor placeras en omskrivning automatiskt i kö i cacheminnet. Omskrivningen ändrar AOF-filens storlek med den minimala uppsättning åtgärder som krävs för att skapa den aktuella datauppsättningen. Under omskrivningar kan du förvänta dig att nå maximal prestanda snabbare, särskilt när du hanterar stora datamängder. Omskrivningar sker mer sällan i takt med att AOF-filen ökar i storlek, men tar lång tid när de inträffar.

Vad bör jag förvänta mig när jag skalar en cache med AOF aktiverat?

Om AOF-filen vid tidpunkten för skalningen är stor förväntar du dig att skalningsåtgärden tar längre tid än förväntat eftersom den läser in filen igen när skalningen har slutförts.

Mer information om skalning finns i Vad händer om jag har skalat till en annan storlek och en säkerhetskopia återställs som gjordes före skalningsåtgärden?.

Hur organiseras mina AOF-data i lagringen?

När du använder Premium-nivån delas data som lagras i AOF-filer upp i flera sidblobar per shard. Som standard sparas hälften av blobarna i det primära lagringskontot och hälften sparas i det sekundära lagringskontot. Att dela upp data mellan flera sidblobar och två olika lagringskonton ökar prestandan.

Om den högsta frekvensen för skrivningar till cacheminnet inte är särskilt hög kanske den här extra prestandan inte behövs. I så fall kan konfigurationen av det sekundära lagringskontot tas bort. Alla AOF-filer lagras i stället på bara det primära lagringskontot. I följande tabell visas hur många totala sidblobar som används för varje prisnivå:

Premiumnivå Blobar
P1 8 per fragment
P2 16 per shard
P3 32 per shard
P4 40 per shard

När klustring är aktiverat har varje shard i cacheminnet en egen uppsättning sidblobar, som anges i föregående tabell. Till exempel distribuerar en P2-cache med tre shards sin AOF-fil över 48 sidblobar: sexton blobar per shard, med tre shards.

Efter en omskrivning finns det två uppsättningar AOF-filer i lagringen. Omskrivningar sker i bakgrunden och läggs till i den första uppsättningen filer. Ange åtgärder som skickas till cachen under omskrivningen och lägg till i den andra uppsättningen. En säkerhetskopia lagras tillfälligt under omskrivningar om det uppstår ett fel. Säkerhetskopieringen tas omedelbart bort när en omskrivning har slutförts. Om mjuk borttagning är aktiverat för ditt lagringskonto gäller inställningen för mjuk borttagning och befintliga säkerhetskopior fortsätter att vara i läget för mjuk borttagning.

Påverkar brandväggsundanstag på lagringskontot beständigheten?

Ja. Om du använder brandväggsinställningar på lagringskontot kan du förhindra att beständighetsfunktionen fungerar. Du kan se om det finns fel i att bevara data genom att visa måttet Fel. Det här måttet anger om cachen inte kan spara data på grund av brandväggsbegränsningar för lagringskontot eller andra problem.

Om du vill använda datapersistence med ett lagringskonto som har en brandvägg konfigurerad använder du hanterad identitetsbaserad autentisering för att ansluta till lagring. Med hanterad identitet läggs cacheinstansen till i listan över betrodda tjänster, vilket gör brandväggsfel enklare att utföra. Om du inte använder hanterad identitet och i stället auktoriserar till ett lagringskonto med hjälp av en nyckel, tenderar brandväggsundantag på lagringskontot att bryta beständighetsprocessen. Detta gäller endast för beständighet på Premium-nivån.

Kan jag aktivera AOF-beständighet om jag har fler än en replik?

Med Premium-nivån kan du inte använda tilläggsfilpersistence (AOF) med flera repliker. På Enterprise- och Enterprise Flash-nivåerna är replikarkitekturen mer komplicerad, men AOF-persistens stöds när Enterprise-cacheminnen används i zonredundant distribution.

Hur gör jag för att kontrollera om mjuk borttagning är aktiverat på mitt lagringskonto?

Välj det lagringskonto som din cache använder för beständighet. Välj Dataskydd på resursmenyn. I arbetsfönstret kontrollerar du tillståndet Aktivera mjuk borttagning för blobar. Mer information om mjuk borttagning i Azure Storage-konton finns i Aktivera mjuk borttagning för blobar.

Nästa steg

Läs mer om Azure Cache for Redis-funktioner.