Dela via

Konfigurera datapersistence för en Azure Managed Redis-instans (förhandsversion)

  • Artikel

Med Redis-beständighet kan du spara 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 är ett viktigt sätt att öka hållbarheten för en cacheinstans eftersom alla cachedata lagras i minnet. Dataförlust är möjligt om ett fel inträffar när cachenoderna är nere. Beständighet bör vara en viktig del av din strategi för hög tillgänglighet och haveriberedskap med Azure Managed Redis (förhandsversion).

Viktigt!

Datapersistence är avsett att ge motståndskraft för oväntade Redis-nodfel, men det är inte en datasäkerhetskopia eller en pitr-funktion (point in time recovery). Om skadade data skrivs till Redis-instansen sparas även dessa data. Om du vill göra säkerhetskopior av din Redis-instans använder du exportfunktionen.

Tillgänglighetsomfång

Nivå Minnesoptimerad, balanserad, beräkningsoptimerad Flash-optimerad
Tillgängligt Ja Ja

Typer av datapersistence i Redis

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

  • RDB-persistens – När du använder RDB-persistens bevarar Azure Managed Redis en ögonblicksbild av cacheminnet i binärt format. Ögonblicksbilden sparas på en hanterad disk monterad på Redis-instansen. 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 och repliken 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 Managed Redis varje skrivåtgärd i en logg. Loggen sparas en gång per sekund på en hanterad disk monterad på Redis-instansen. Om en oåterkallelig 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. Läs mer om fördelarna och nackdelarna med AOF-persistens.

Viktigt!

Azure Managed 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 varken nås av användare eller importeras till en ny eller befintlig cache. Om du vill flytta data mellan cacheminnen använder du funktionen Importera och exportera . Mer information finns i Importera och exportera data i Azure Managed 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 Azure CLI som exporterar data regelbundet.

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-lagrade datafiler kan inte importeras till en ny cache eller befintlig cache. Använd funktionen Importera/exportera i stället.
  • Beständighet stöds inte med cacheminnen med aktiv geo-replikering.
  • Lagrade datafiler för hanterade diskar krypteras som standard med Hjälp av Microsofts hanterade nycklar (MMK), men kundhanterade nycklar (CMK) kan också användas. Mer information finns i Hantera datakryptering.

Konfigurera datapersistence med hjälp av Azure Portal

  1. Logga in på Azure Portal och börja följa anvisningarna i snabbstartsguiden för Azure Managed Redis.

  2. När du kommer till fliken Avancerat väljer du antingen RDB - eller AOF-alternativ i avsnittet Datapersistence .

    Skärmbild som visar fliken Avancerat på Företagsnivå och Datapersistens är markerad med en röd ruta.

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

    Inställning Föreslaget värde beskrivning
    Säkerhetskopieringsfrekvens Använd listrutan och välj ett säkerhetskopieringsintervall. Alternativen är 60 minuter, 6 timmar och 12 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.

  4. Om du vill aktivera AOF-persistence väljer du AOF. Endast ett alternativ för säkerhetskopieringsfrekvens är tillgängligt.

  5. Slutför skapandet av cachen genom att följa resten av anvisningarna i snabbstartsguiden för Azure Managed Redis.

Kommentar

Du kan lägga till beständighet i en tidigare skapad Azure Managed Redis-instans när som helst genom att navigera till avancerade inställningar på resursmenyn.

Konfigurera datapersistence med hjälp av PowerShell och Azure CLI

Med hjälp av PowerShell

Kommandot New-AzRedisEnterpriseCache kan användas för att skapa en ny Azure Managed Redis-instans med hjälp av datapersistence. Använd parametrarna RdbPersistenceEnabled, RdbPersistenceFrequency, AofPersistenceEnabledoch AofPersistenceFrequency för att konfigurera beständighetskonfigurationen. Det här exemplet skapar en ny balanserad B10-instans med RDB-beständighet med en timmes frekvens:

New-AzRedisEnterpriseCache -Name "MyCache" -ResourceGroupName "MyGroup" -Location "West US" -Sku "Balanced_B10" -RdbPersistenceEnabled -RdbPersistenceFrequency "1h"

Befintliga cacheminnen kan uppdateras med kommandot Update-AzRedisEnterpriseCacheDatabase . Det här exemplet lägger till RDB-persistence med 12 timmars frekvens till en befintlig instans:

Update-AzRedisEnterpriseCacheDatabase -Name "MyCache" -ResourceGroupName "MyGroup" -RdbPersistenceEnabled -RdbPersistenceFrequency "12h"

Med hjälp av Azure CLI

Kommandot az redisenterprise create kan användas för att skapa en ny Azure Managed Redis-instans med hjälp av datapersistence. Använd parametrarna rdb-enabled, rdb-frequency, aof-enabledoch aof-frequency för att konfigurera beständighetskonfigurationen. Det här exemplet skapar en ny balanserad B10-instans med RDB-beständighet med en timmes frekvens:

az redisenterprise create --cluster-name "cache1" --resource-group "rg1" --location "East US" --sku "Balanced_B10" --persistence rdb-enabled=true rdb-frequency="1h"

Befintliga cacheminnen kan uppdateras med kommandot az redisenterprise database update . Det här exemplet lägger till RDB-beständighet med 12 timmars frekvens till en befintlig cacheinstans:

az redisenterprise database update --cluster-name "cache1" --resource-group "rg1" --persistence rdb-enabled=true rdb-frequency="12h"

Hantera datakryptering

Eftersom Redis persistence skapar vilande data är kryptering av dessa data ett viktigt problem för många användare. På Azure Managed Redis 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å Azure Managed Redis .

Vanliga frågor och svar om beständighet

Följande lista innehåller svar på vanliga frågor om Azure Managed 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 Azure Managed Redis-instanser.

Kan jag aktivera AOF- och RDB-persistens samtidigt?

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

Hur fungerar beständighet med geo-replikering?

Om du aktiverar datapersistence kan geo-replikering inte aktiveras för cacheminnet. Det beror på att aktiv geo-replikering ger bättre återhämtning än datapersistence i händelse av ett regionalt avbrott. Om du behöver exportera en kopia av dina data som en säkerhetskopia använder du exportfunktionen i stället.

Vilken beständighetsmodell ska jag välja?

AOF-beständighet sparar varje skrivning till en logg, vilket kan ha en betydande effekt på dataflödet. RDB persistence sparar säkerhetskopior baserat på det konfigurerade säkerhetskopieringsintervallet med minimal effekt på prestanda. 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 din cache. 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 om prestanda när du använder AOF-persistens finns i Påverkar AOF-beständighet dataflödet, svarstiden eller prestandan för min cache?

Påverkar AOF-persistens dataflöde, svarstid eller prestanda för min cache?

Användning av AOF-persistens påverkar dataflödet. AOF körs på alla primära processer, därför ser du högre CPU- och serverbelastning för en cache med AOF-beständighet än en identisk cache utan AOF-beständighet. AOF ger den bästa konsekvensen 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.

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ör både RDB- och AOF-persistens:

  • Om du har skalat till en större storlek finns det ingen effekt.
  • 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 principen allkeys-lru-borttagning .

Debiteras jag för den hanterade disk som används i datapersistence?

Du debiteras inte för det hanterade disklagringsutrymmet. Det ingår i priset.

Kan jag ändra RDB-säkerhetskopieringsfrekvensen när jag har skapat cacheminnet?

Ja, du kan ändra säkerhetskopieringsfrekvensen för RDB-beständighet med hjälp av Azure Portal, CLI eller PowerShell.

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

Intervall för säkerhetskopiering av RDB-beständighet startar inte förrän den tidigare säkerhetskopieringsprocessen har slutförts. Om säkerhetskopieringsfrekvensen är 60 minuter och det tar 15 minuter att slutföra säkerhetskopieringen startar inte nästa säkerhetskopia 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 en ny säkerhetskopia görs?

Alla säkerhetskopieringar av RDB-beständighet, förutom de senaste, tas bort automatiskt. Den här borttagningen kanske inte sker omedelbart, men äldre säkerhetskopior sparas inte på obestämd tid.

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

När AOF-filen blir tillräckligt stor placeras en omskrivning automatiskt i cacheminnet. Omskrivningen ändrar storlek på AOF-filen 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å prestandabegränsningar tidigare, 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 den 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 normalt 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?

Nästa steg