Jämför alternativ för affärskontinuitet och haveriberedskap

  • 10 minuter

Azure Database for MySQL – Flexibel server tillhandahåller funktioner för affärskontinuitet för att skydda databasen vid planerade eller oplanerade avbrott. För att åtgärda olika typer av avbrott kan du använda olika nivåer av felskydd med olika återställningstider eller risk för dataförlust.

Exempel på stilleståndstid

Några exempelscenarier för både planerad och oplanerad stilleståndstid följer.

Scenarier med planerad stilleståndstid

De två vanligaste scenarierna för planerad stilleståndstid är beräkningsskalning som initieras av användaren och schemalagt underhåll som utförs av Azure.

När du utför en beräkningsskalningsåtgärd etablerar Azure en ny flexibel MySQL-server med den begärda beräkningskonfigurationen. Den befintliga servern tillåter att aktiva kontrollpunkter slutförs, tömmer befintliga anslutningar, avbryter ogenomförda transaktioner och sedan stängs den befintliga servern av. Nu kopplar Azure den befintliga serverns lagring till den nya servern och startar databasen. Databasen utför sedan den återställning som krävs innan den fortsätter att acceptera klientanslutningar.

Nya funktioner och felkorrigeringar sker automatiskt som en del av tjänstens planerade underhåll. Delversionsuppgraderingskorrigeringar tillämpas också under planerat underhåll, vilket medför några sekunders stilleståndstid. Du kan schemalägga dessa aktiviteter enligt beskrivningen i följande avsnitt, "Schemalagd stilleståndstid och underhållsperioder".

Oplanerat stillestånd

Databasen kan gå ner oväntat av flera orsaker, till exempel:

  • Maskinvarufel för databasen.
  • Fel på lagringsenhet.
  • Program- eller användarfel (t.ex. oavsiktligt borttagna tabeller).
  • Fel i tillgänglighetszon och region.

Om hög tillgänglighet (HA) inte är aktiverat försöker Azure återställa, till exempel kopiera förlorade data, starta om servern eller till och med starta servern på en annan fysisk nod. Om du aktiverar ha kan du minska eller till och med eliminera den här typen av stilleståndstid, enligt beskrivningen i följande avsnitt.

Hög tillgänglighet

Azure Database for MySQL – Flexibel server tillhandahåller ha med automatisk redundans, vilket ger en lösning som är utformad för att aldrig förlora incheckade data och för att förhindra att databasen är en enda felpunkt. När du har konfigurerat HA etablerar och hanterar den flexibla MySQL-servern automatiskt en standby-replik.

Det finns två typer av hög tillgänglighet med olika feltolerans och svarstidsavvägningar: zonredundant och samma zon.

Zonredundant HA

Zonredundant HA ger redundans i flera tillgänglighetszoner, vilket ger den högsta tillgänglighetsnivån med möjlighet att återställa även om en hel zon slutar fungera. Med hjälp av en zonredundant HA-konfiguration införs ytterligare svarstider, så se till att avgöra om detta är acceptabelt för ditt program. Dessutom kräver användning av en zonredundant HA-konfiguration att databasklientprogram är zonredundanta för att säkerställa att de övergripande åtgärderna fortsätter.

Ha i samma zon

I en ha-konfiguration i samma zon finns de primära servrarna och väntelägesservrarna i samma tillgänglighetszon, vilket minimerar svarstiden. Även om låg svarstid kan krävas i vissa användningsfall, med en ha-konfiguration i samma zon, blir den resulterande stilleståndstiden längre när den flexibla MySQL-servern återställs om tillgänglighetszonen går ned.

Till skillnad från zonredundant HA är ha i samma zon tillgängligt i alla regioner som stöder Azure Database for MySQL – flexibel server.

Säkerhetskopiering och återställning

Serversäkerhetskopior är en viktig komponent i alla strategier för affärskontinuitet. Azure Database for MySQL – Flexibel server skapar automatiskt säkerhetskopior som lagras säkert i lokalt redundant lagring i den region som är värd för databasen. Du kan använda dessa säkerhetskopior för att återställa databasen till en viss tidpunkt, i händelse av fel eller skadade data (t.ex. ett programfel eller utvecklingsfel).

Det finns två typer av säkerhetskopior. Med automatiserade säkerhetskopieringar tar den flexibla MySQL-servern ögonblicksbilder av databasdatafiler samt associerade transaktionsloggar. Automatiserade säkerhetskopieringar av ögonblicksbilder sker en gång om dagen och säkerhetskopieringar av transaktionsloggar sker var femte minut. Om en säkerhetskopiering misslyckas försöker servern igen var 20:e minut tills säkerhetskopieringen lyckas.

Med säkerhetskopieringar på begäran kan du skapa en databassäkerhetskopia när som helst. Med båda typerna av säkerhetskopior behålls säkerhetskopieringsfiler i sju dagar som standard. Men baserat på dina affärsbehov kan du konfigurera värdet för kvarhållningsperioden från en till 35 dagar.

Du kan behålla säkerhetskopior i upp till 10 år med hjälp av funktionen för långsiktig kvarhållning, som för närvarande finns i offentlig förhandsversion. Den långsiktiga säkerhetskopieringslösningen kan användas separat från eller utöver de automatiserade Säkerhetskopieringarna av Azure Database for MySQL. Långsiktiga säkerhetskopieringar kan göras enligt ett kundkontrollerat schema eller på begäran. Säkerhetskopior lagras i hanterade Azure Backup-lagringskonton i separata säkerhets- och feldomäner.

Förutom att säkerhetskopiera databasen kan du exportera säkerhetskopieringsfiler till Azure Blob Storage, som du sedan kan använda för migreringar, dataåterställning eller arkivering. Exporter på begäran finns för närvarande i offentlig förhandsversion och är endast tillgängliga i offentliga molnregioner.

Om du vill lagra säkerhetskopieringsfilerna kan du välja bland flera lagringsalternativ:

  • Med lokalt redundant lagring (samma datacenter, samma zon) lagras säkerhetskopieringsfiler i samma datacenter som databasen. Det här alternativet ger elva nioor (99,99999999999%) av hållbarheten för säkerhetskopieringsobjekt under ett år. Som standard använder servrar utan HA eller med samma zon ha lokalt redundant lagring.

  • Med zonredundant lagring av säkerhetskopiering (annan zon, samma region) lagras säkerhetskopieringsfiler i serverns tillgänglighetszon och replikeras till en annan tillgänglighetszon i samma region. Det här alternativet ger tolv nior (99,999999999999%) av hållbarhet under ett visst år. Zonredundant lagring är viktigt för zonredundant ha och krävs om data måste finnas kvar i en enda region.

  • Med geo-redundant lagring av säkerhetskopior (olika regioner) lagras säkerhetskopieringsfiler i serverns region och replikeras sedan till en annan geo-länkad region. Det här alternativet ger sexton nior (99,9999999999999999%) hållbarhet under ett visst år. Geo-redundant lagring stöds endast i azure-kopplade regioner.

Obs! Med Azure Database for MySQL – flexibel server är säkerhetskopieringsutrymme upp till 100 % av det etablerade lagringsutrymmet tillgängligt utan extra kostnad. Ytterligare lagringsutrymme debiteras i GB per månad. Mer information finns i prisdokumentationen.

När du har en säkerhetskopia kan du återställa säkerhetskopian till en ny flexibel MySQL-server. Du kan välja säkerhetskopieringen på tre sätt: Välj en fullständig säkerhetskopia manuellt, välj automatiskt den senaste återställningspunkten eller välj automatiskt den snabbaste återställningspunkten. Om du har geo-redundanta säkerhetskopior kan du också återställa till den kopplade regionen (mellan regioner).

Schemalagda stilleståndstider och underhållsperioder

Periodiskt underhåll krävs för att hålla den hanterade servern stabil, säker och uppdaterad. Under underhållsperioder får tjänsten distributioner av nya funktioner, uppdateringar och korrigeringar. Normalt är underhållsperioder schemalagda att ske minst var 30:e dag, men kritiska säkerhetskorrigeringar tillämpas ibland inom sju dagar eller mindre.

Du kan välja ett systemhanterat schema eller definiera ett anpassat schema för varje flexibel MySQL-server i din Azure-prenumeration.

Du kan få meddelanden om schemalagt underhåll på ett av flera sätt. Meddelanden kan vara:

  • Skickas via e-post till en specifik adress eller Azure Resource Manager-roll.
  • Skickas via SMS.
  • Push-överfört som ett Azure-appmeddelande.
  • Levereras via röstmeddelande.

Anpassade underhållsfönster

Med ett systemhanterat schema väljer systemet som standard ett entimmesfönster mellan kl. 23.00 och 07.00 i tidszonen för mySQL-flexibel server. Med ett anpassat schema kan du ange underhållsfönstret för servern genom att välja veckodag och en timmes tid.

Nästan noll driftstopp för HA-servrar (offentlig förhandsversion)

HA-aktiverade servrar drar nytta av underhållsstopp nära noll, en ny funktion som avsevärt minskar underhållsavbrott. Den förväntade stilleståndstiden är mellan 40 och 60 sekunder. Underhåll av nästan noll driftstopp är avgörande för program med mycket höga tillgänglighetskrav, vilket kräver minimala avbrott i databasanslutningen.

Schemalägg om underhåll (offentlig förhandsversion)

Du kan schemalägga om underhåll när du använder tjänstnivåerna Generell användning eller Affärskritisk. I underhållsavsnittet i Azure Portal kan du schemalägga om nästa schemalagda underhåll till ett annat datum och tid. Du kan också initiera underhåll på begäran genom att välja Schemalägg om till Nu.