Dela via

Datapersistens i Azure Cache för Redis

  • Gäller för: ✅ Azure Cache for Redis

Viktigt!

Azure Cache for Redis meddelade sin tidslinje för pensionering för alla SKU:er. Vi rekommenderar att du flyttar dina befintliga Azure Cache for Redis-instanser till Azure Managed Redis så snart du kan.

Mer information om pensionering:

Om ett Azure Cache for Redis-cachefel inträffar är dataförlust möjlig när noderna är nere. Med Redis-beständighet kan du spara data som lagras i cacheinstanser. Om det uppstår ett maskinvarufel återskapas cacheinstansen med data från beständighetsfilen när den kommer tillbaka online.

Den här artikeln beskriver Redis persistence och hur du konfigurerar och hanterar datapersistence i dina Azure Redis-cacheinstanser på Premium- och Enterprise-nivå. Funktionen för datapersistence är inte tillgänglig på Basic- eller Standard-nivåer och är i förhandsversion på Enterprise- och Enterprise Flash-nivåer.

Möjligheten att spara data är ett viktigt sätt att öka hållbarheten för en cacheinstans eftersom den lagrar alla cachedata i minnet. Beständighet bör vara en viktig del av din strategi för hög tillgänglighet och haveriberedskap i Azure Redis.

Viktigt!

Funktionen för datapersistence ger motståndskraft för oväntade Redis-nodfel. Datapersistens är inte en funktion för datasäkerhetskopiering eller återställning vid en specifik tidpunkt (PITR). Om skadade data skrivs till Redis-instansen sparas även skadade data. Om du vill göra säkerhetskopior av din Redis-instans använder du funktionen Exportera .

Viktigt!

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 datapersistence med mjuk borttagning orsakar höga lagringskostnader. Mer information finns i Ska jag aktivera mjuk borttagning?

Tillgänglighetens omfattning

Nivå Grundläggande, Standard Förstklassig Enterprise, Enterprise Flash
Tillgängligt Nej Ja Ja (förhandsversion)

Typer av Redis-datapersistence

Azure Redis erbjuder två typer av datapersistence, Redis-databasformatet (RDB) och AOF-formatet (Append-only File ).

  • RDB-persistens bevarar en ögonblicksbild av cacheminnet i binärt format och sparar den i ett Azure Storage-konto. Du konfigurerar säkerhetskopieringsfrekvensen för att avgöra 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. Mer information finns i RDB-fördelar och RDB-nackdelar.

  • AOF persistence sparar varje skrivåtgärd i en logg och sparar loggen en gång per sekund på ett Azure Storage-konto. Om en katastrofal händelse inträffar som inaktiverar både den primära cachen och replikcacheminnet rekonstrueras cachen automatiskt med hjälp av de lagrade skrivåtgärderna. Mer information finns i AOF-fördelar och AOF-nackdelar.

Krav och begränsningar

  • Funktioner för datapersistence ger motståndskraft för oväntade Redis-nodfel. Datapersistence är inte en datasäkerhetskopia eller PITR-funktion. Om skadade data skrivs till Redis-instansen bevaras även skadade data. Om du vill säkerhetskopiera Din Redis-instans använder du funktionen Exportera .

  • Azure Cache for Redis-beständighetsfunktioner är avsedda att återställa data automatiskt till samma cache efter dataförlust. Du kan inte importera lagrade datafiler till en ny eller befintlig cache.

    • Om du vill flytta data mellan cacheminnen använder du funktionerna Importera och exportera data .

    • Om du vill generera säkerhetskopior av data som kan läggas till i en ny cache kan du använda automatiserade skript med hjälp av PowerShell eller Azure CLI som exporterar data regelbundet.

  • Beständighet stöds inte med cacheminnen som använder passiv geo-replikering eller aktiv geo-replikering.

  • På Premium-nivån sparas data direkt till ett Azure Storage-konto som du äger och hanterar.

  • Lagringskontot för datapersistence på Premium-nivå måste finnas i samma region som cacheinstansen. Du kan dock använda ett lagringskonto i en annan prenumeration för att spara data om du använder hanterad identitet för att ansluta till lagringskontot.

  • Det är bäst att inaktivera funktionen för mjuk borttagning på lagringskontot som du använder för datapersistence på Premium-nivå. Användning av datapersistence med mjuk borttagning orsakar höga lagringskostnader. Mer information finns i Priser och fakturering och Ska jag aktivera mjuk borttagning?

  • RDB-filer säkerhetskopieras till lagring i form av sidblobar. Sidblobar stöds inte i lagringskonton med hierarkisk namnrymd (HNS) aktiverat, till exempel Azure Data Lake Storage Gen2, så beständighet tenderar att misslyckas i dessa lagringskonton.

  • På Premium-nivån stöds inte AOF-persistens med flera repliker.

Datakryptering

Eftersom Redis persistence skapar vilande data är det viktigt att kryptera dessa data. Krypteringsalternativen varierar beroende på vilken Azure Redis-nivå du använder.

För Premium-nivån strömmar data direkt från cacheinstansen till Azure Storage när beständighet initieras. Azure Storage krypterar automatiskt data när de bevaras, men du kan använda flera krypteringsmetoder, inklusive Microsoft-hanterade nycklar (MMK: er), kundhanterade nycklar (CMK:er) och kundspecifika nycklar. Mer information finns i Azure Storage-kryptering för vilande data och Kundhanterade nycklar för Azure Storage-kryptering.

Konfigurera datalagring

Du kan använda Azure-portalen, Arm-mallar (Azure Resource Manager), PowerShell eller Azure CLI för att skapa och konfigurera datapersistence för Azure Redis-cacheminnen på Premium- eller Enterprise-nivå.

Förutsättningar

  • Om du vill skapa och lägga till beständighet i Azure Redis-cacheminnen behöver du skrivåtkomst och behörigheter för att skapa Premium- eller Enterprise-cacheminnen i en Azure-prenumeration.
  • För Premium-nivåcacheminnen behöver du ett Azure Storage-konto i samma region som cachen för att lagra cachedata. Om du använder hanterad identitet som autentiseringsmetod kan du använda ett lagringskonto i en annan prenumeration än din cache.
  • För Azure PowerShell-procedurerna behöver du Azure PowerShell installerat eller använda Azure Cloud Shell med PowerShell-miljön i Azure-portalen.
  • För Azure CLI-procedurerna behöver du Azure CLI installerat eller använda Azure Cloud Shell med Bash-miljön i Azure-portalen.

Konfigurera datapersistence i Azure-portalen

I Azure-portalen kan du konfigurera datapersistence när du skapar din Azure Redis Premium- eller cacheinstans på företagsnivå.

Anteckning

Du kan också lägga till beständighet i en tidigare skapad cache genom att gå till Datapersistence under Inställningar i den vänstra navigeringsmenyn för cacheminnet.

  1. Om du vill skapa en Premium-cache i Azure-portalen följer du anvisningarna i Snabbstart: Skapa en Redis-cache med öppen källkod och välj Premium för cache-SKU :n på fliken Grundläggande .

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

  2. När du fyller i fliken Avancerat väljer du antingen RDB - eller AOF-beständighet för säkerhetskopieringsfil under Datapersistence och konfigurerar relevanta inställningar.

    Skärmbild som visar inställningarna för RDB-datapersistence.

    • Konfigurera följande inställningar för RDB:

      Inställning Värde beskrivning
      Autentiseringsmetod Välj Hanterad identitet eller lagringsnyckel Med hanterad identitet kan du använda ett lagringskonto i en annan prenumeration än din cache.
      Abonnemang Välj den prenumeration som innehåller din hanterade identitet. Det här objektet visas bara om du väljer Hanterad identitetsautentisering .
      Säkerhetskopieringsfrekvens Välj ett säkerhetskopieringsintervall: 15 minuter, 30 minuter, 60 minuter, 6 timmar, 12 timmar eller 24 timmar. Det här intervallet börjar räknas ned när den tidigare säkerhetskopieringen har slutförts. När intervallet förflutit startar en ny säkerhetskopia.
      Lagringskonto Välj ditt lagringskonto. Lagringskontot måste finnas i samma region som cacheminnet. Ett Premium-lagringskonto rekommenderas eftersom det har högre dataflöde.
      Lagringsnyckel Välj antingen primärnyckeln eller den sekundära nyckel som ska användas. Det här objektet visas bara om du väljer autentisering med lagringsnyckel . Om lagringsnyckeln för ditt beständighetslagringskonto återskapas måste du konfigurera om nyckeln från listrutan Lagringsnyckel .

    • För AOF konfigurerar du följande inställningar:

      Inställning Värde beskrivning
      Autentiseringsmetod Välj Hanterad identitet eller lagringsnyckel Med hanterad identitet kan du använda ett lagringskonto i en annan prenumeration än din cache.
      Abonnemang Välj den prenumeration som innehåller din hanterade identitet. Det här objektet visas bara om du väljer Hanterad identitetsautentisering .
      Första lagringskontot Välj ditt lagringskonto. Lagringskontot måste finnas i samma region som cacheminnet. Ett Premium-lagringskonto rekommenderas eftersom det har högre dataflöde.
      Första lagringsnyckeln Välj antingen primärnyckeln eller sekundärnyckeln som ska användas. Det här objektet visas bara om du väljer autentisering med lagringsnyckel . Om lagringsnyckeln återskapas måste du konfigurera om nyckeln från listrutan Lagringsnyckel .
      Second Storage-konto Du kan också välja ett sekundärt lagringskonto. Om du konfigurerar ett sekundärt lagringskonto sparas skrivningar till replikcachen till det andra lagringskontot.
      Second Storage Key Välj antingen primärnyckeln eller sekundärnyckeln som ska användas. Det här objektet visas bara om du väljer autentisering med lagringsnyckel . Om lagringsnyckeln återskapas måste du konfigurera om nyckeln.

  3. Slutför alla flikar och slutför skapandet av cachen genom att följa resten av anvisningarna i Snabbstart: Skapa en Redis-cache med öppen källkod.

Med RDB-persistens startar den första säkerhetskopieringen när intervallet för säkerhetskopieringsfrekvens förflutit.

Med AOF-beständighet kan du skriva åtgärder till cachen och spara till det namngivna lagringskontot eller kontona. Om det uppstår ett oåterkalleligt fel som tar bort både de primära cacheminnena och replikcachen används den lagrade AOF-loggen för att återskapa cacheminnet.

Konfigurera datapersistence med Azure PowerShell

Du kan använda Azure PowerShell för att konfigurera datapersistence när du skapar en Azure Redis Premium- eller Enterprise-nivåcache, eller för att lägga till beständighet i en tidigare skapad cache.

Du kan använda kommandot New-AzRedisCache för att skapa en ny Azure Redis Premium-nivåcache som använder datapersistence.

Om du vill uppdatera befintliga cacheminnen för att använda datapersistence kör du kommandot Set-AzRedisCache . Anvisningar finns i Lägga till beständighet i en befintlig cache.

Konfigurera databeständighet med hjälp av Azure CLI

Du kan använda Azure CLI för att konfigurera datapersistence när du skapar en Azure Redis Premium- eller Enterprise-nivåcache, eller för att lägga till beständighet i en tidigare skapad cache.

Du kan använda kommandot az redis create för att skapa en ny cache på Premium-nivå som använder datapersistence. Till exempel:

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

Om du vill uppdatera en befintlig cache använder du 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"

Vanliga frågor och svar om beständighet

Det här avsnittet innehåller svar på vanliga frågor om Azure Redis cachepersistence.

RDB-persistence

AOF-persistens

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

Ja, du kan konfigurera beständighet vid skapande av cacheminnen 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?

Datapersistence fungerar inte med geo-replikering aktiverat.

Vilken beständighetsmodell ska jag välja?

AOF persistence skriver till en logg en gång per sekund, medan RDB persistence sparar säkerhetskopior baserat på det konfigurerade säkerhetskopieringsintervallet. RDB-persistens har mindre effekt på dataflöde och prestanda än AOF-beständighet.

Välj AOF-persistence om ditt primära mål är att minimera dataförlusten och du kan hantera ett lägre dataflöde för cacheminnet. Välj RDB-persistens om du vill behålla optimalt dataflöde i cacheminnet men ändå vill ha en mekanism för dataåterställning.

Mer information finns i RDB-fördelar, RDB-nackdelar, AOF-fördelar och AOF-nackdelar.

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

AOF-persistens påverkar dataflödet. Eftersom AOF körs på både den primära processen och replikprocessen ser du högre PROCESSOR- och serverbelastning för en cache med AOF-beständighet än på 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. Kompromissen är att AOF är mer beräkningsintensivt.

Så länge processor- och serverbelastningen båda är mindre än 90%, finns det en straffavgift för dataflödet, men cachen fungerar normalt. Över 90 % cpu- och serverbelastning kan dataflödesstraffet bli högre och svarstiden för alla kommandon som bearbetas av cachen ökar. Latencyn ökar eftersom AOF-beständigheten körs på både den primära processen och replikprocessen, vilket ökar belastningen på den nod som är i bruk och placerar beständigheten på den kritiska banan för data.

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

  • Om du har skalat till en större storlek finns det ingen effekt.
  • Om du har skalat till en mindre storlek och du har en anpassad databasinställning 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 i den mindre storleken 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. Varje cache måste ha ett eget lagringskonto för att kunna konfigureras för beständighet.

Viktigt!

Använd även separata lagringskonton för beständighet och 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 lagringskontot.
  • För Enterprise- och Enterprise Flash-cacheminnen ingår den hanterade disklagringen i priset och medför inga extra avgifter.

Hur ofta skrivs RDB- och AOF-persistens till mina blobar, och bör jag aktivera mjuk borttagning?

RDB- och AOF-beständighet kan skriva till dina lagringsblobar så ofta som varje timme, med några minuters mellanrum eller varje sekund. Mjuk borttagning blir snabbt dyrt med de typiska datastorlekarna för ett cacheminne som också utför skrivåtgärder varje sekund. Om du aktiverar mjuk borttagning på ett lagringskonto innebär det också att Azure Redis inte kan minimera lagringskostnaderna genom att ta bort gamla säkerhetskopieringsdata.

Det är bäst att undvika att aktivera mjuk borttagning på lagringskonton som du använder för Datapersistence på Azure Redis Premium-nivå. 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 med hjälp av Azure-portalen, Azure CLI eller Azure PowerShell.

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

Intervall för säkerhetskopieringsfrekvens av RDB-persistens startar inte förrän den tidigare säkerhetskopieringsprocessen har slutförts framgångsrikt. 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 den föregående säkerhetskopieringen.

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 fortsätter de befintliga säkerhetskopiorna 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-beständighet när du förväntar dig att ha högre SET-åtgärder än vanligt i cacheminnet. Med det sekundära lagringskontot ser du till att cacheminnet inte når lagringsbandbreddsgränserna. Det här alternativet är endast tillgängligt för cacheminnen på Premium-nivå.

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. Om du vill ändra inställningarna för befintliga cacheminnen väljer du Datapersistence under Inställningar på den vänstra navigeringsmenyn på cachesidan. Om du vill inaktivera beständighet helt väljer du Inaktiverad på sidan Datapersistence .

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

När en AOF-fil blir tillräckligt stor placeras en omskrivning automatiskt 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 mindre ofta när AOF-filen blir större, men det 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 vanligt eftersom den läser in filen igen när skalningen har slutförts. Se också Vad händer om jag skalar 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 förbättrar prestandan.

Om den högsta skrivhastigheten för skrivningar till cacheminnet inte är hög kanske den här extra prestandan inte behövs. I så fall kan den sekundära lagringskontokonfigurationen tas bort och alla AOF-filer lagras i det primära lagringskontot. I följande tabell visas hur många totala sidblobbar som varje prisnivå använder.

Premiumnivå Klumpar
P1 8 per fragment
P2 16 per shard
P3 32 per skärva
P4 40 per shard

När klustring är aktiverat har varje shard i cacheminnet sin egen uppsättning sidblobar enligt föregående tabell. Till exempel distribuerar en P2-cache med tre delar sin AOF-fil över 48 sidspecifika blobbar: Sexton blobbar per del med tre delar.

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. SET-åtgärder som skickas till cachen under omskrivningen läggs till i den andra uppsättningen filer.

Om det uppstår ett fel under en omskrivning lagras en säkerhetskopia tillfälligt. Säkerhetskopieringen tas bort omedelbart när omskrivningen 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. För beständighet på Premium-nivån kan brandväggsinställningar på lagringskontot förhindra att beständighetsfunktionen fungerar.

Du kan kontrollera fel i lagrade data genom att visa Fel-metriken. Det här måttet anger om cachen inte kan spara data på grund av brandväggsbegränsningar för lagringskontot eller andra problem.

För att använda databeständighet med ett lagringskonto som har en brandvägg konfigurerad använder du hanterad identitetsbaserad autentisering för att ansluta till lagringskontot. Med hanterad identitet läggs cacheinstansen till i listan över betrodda tjänster, vilket gör det enklare att tillämpa brandväggsundantag. Om du auktoriserar till lagringskontot med hjälp av en nyckel i stället för hanterad identitet, tenderar brandväggsundantag på lagringskontot att bryta beständighetsprocessen.

Kan jag aktivera AOF-persistens om jag har fler än en kopia?

Med Premium-nivån kan du inte använda AOF-beständighet 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 zonredundanta distributioner.

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

I Azure-portalen väljer du det lagringskonto som din cache använder för beständighet och väljer Dataskydd under Datahantering i den vänstra navigeringsmenyn. På sidan Dataskydd kontrollerar du om Aktivera mjuk borttagning för blobar är aktiverat. Mer information om mjuk borttagning i Azure Storage-konton finns i Aktivera mjuk borttagning för blobar.

Kan jag använda ett lagringskonto i en annan prenumeration än den där min cache finns?

Du kan bara välja ett lagringskonto i en annan prenumeration om du använder hanterad identitet som autentiseringsmetod för lagringskontot.

Relaterat innehåll

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