Dela via

Konfigurera databeständighet för en Azure Managed Redis-instans (förhandsversion)

  • 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 Managed Redis (förhandsversion).

Viktigt!

Databeständighet är avsett att ge motståndskraft vid oväntade Redis-nodfel, men är inte en funktion för datasäkerhetskopiering eller PITR (återställning till tidpunkt). Om skadade data skrivs till Redis-instansen sparas även dessa data. Om du vill säkerhetskopiera din Redis-instans kan du använda exportfunktionen.

Tillgänglighet

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-beständighet – När du använder AOF-beständighet sparar Azure Managed Redis varje skrivning 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 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.

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-beständiga datafiler kan varken nås av användare eller importeras till en ny 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 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-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 aktiv geo-replikering.
  • Den hanterade disk som innehåller lagrade datafiler krypteras som standard med 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 beständighet i Azure Managed Redis.

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 cachen skapas och på befintliga Azure Managed Redis-instanser.

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. Anledningen är att aktiv geo-replikering ger bättre återhämtning än databeständighet i händelse av ett regionalt avbrott. Om du behöver exportera en kopia av dina data som en säkerhetskopia kan du använda exportfunktionen i stället.

Vilken beständighetsmodell ska jag välja?

AOF-beständighet sparar varje skrivåtgärd i en logg, vilket kan ha en betydande effekt på dataflödet. RDB-beständighet sparar säkerhetskopior enligt den inställda säkerhetskopieringsfrekvensen, med minimal effekt på prestandan. 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?

Användning av AOF-beständighet påverkar dataflödet. Eftersom AOF körs på alla primära processer 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 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.

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 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.

Debiteras jag för den hanterade disk som används vid databeständighet?

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

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.

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 är stor vid skalningstillfälle kan du förvänta dig att skalningsåtgärden tar längre tid än normalt, eftersom filen läses igen efter att 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