Översikt över affärskontinuitet med Azure Database for MySQL – flexibel server
GÄLLER FÖR: 
Azure Database for MySQL – flexibel server
Azure Database for MySQL – flexibel server möjliggör funktioner för affärskontinuitet som skyddar dina databaser i händelse av ett planerat och oplanerat avbrott. Funktioner som automatiserade säkerhetskopieringar och hög tillgänglighet hanterar olika nivåer av felskydd med olika exponeringar för återställningstid och dataförlust. När du utformar ditt program för att skydda mot fel bör du överväga mål för återställningstid (RTO) och mål för återställningspunkter (RPO) för varje program. RTO är avbrottstoleransen och RPO är dataförlusttoleransen efter ett avbrott i databastjänsten.
I följande tabell visas de funktioner som Azure Database for MySQL – flexibel server erbjuder.
| Funktion | Beskrivning | Begränsningar |
|---|---|---|
| Säkerhetskopiering och återställning | Tjänsten utför automatiskt dagliga säkerhetskopior av dina databasfiler och säkerhetskopierar kontinuerligt transaktionsloggar. Säkerhetskopior kan behållas under en period mellan 1 och 35 dagar. Du kan återställa databasservern till valfri tidpunkt inom kvarhållningsperioden för säkerhetskopior. Återställningstiden beror på storleken på de data som ska återställas + tiden för att utföra loggåterställning. Mer information finns i Begrepp – Säkerhetskopiering och återställning. | Säkerhetskopieringsdata finns kvar i regionen |
| Lokal redundant säkerhetskopiering | Tjänstsäkerhetskopiorna lagras automatiskt och säkert i en lokal redundant lagring i en region och i samma tillgänglighetszon. De lokalt redundanta säkerhetskopiorna replikerar serverns säkerhetskopieringsdatafiler tre gånger på en enda fysisk plats i den primära regionen. Lokalt redundant säkerhetskopieringslagring ger minst 99,999999999999 % (11 nior) hållbarhet för objekt under ett visst år. Mer information finns i Begrepp – Säkerhetskopiering och återställning. | Gäller i alla regioner |
| Geo-redundant säkerhetskopiering | Tjänstsäkerhetskopiorna kan konfigureras som geo-redundanta vid skapandetillfället. Aktivering av geo-redundans replikerar serversäkerhetsdatafilerna i den primära regionens ™parkopplade region för att ge regional återhämtning. Geo-redundant lagring av säkerhetskopiering ger minst 99,9999999999999999% (16 nior) hållbarhet för objekt under ett visst år. Mer information finns i Begrepp – Säkerhetskopiering och återställning. | Tillgänglig i alla Azure-kopplade regioner |
| Zonredundant hög tillgänglighet | Tjänsten kan distribueras i hög tillgänglighetsläge, vilket distribuerar primära servrar och väntelägesservrar i två olika tillgänglighetszoner i en region. Zonredundant hög tillgänglighet skyddar mot fel på zonnivå och hjälper även till att minska programavbrott under planerade och oplanerade driftstopp. Data från den primära servern replikeras synkront till väntelägesrepliken. Vid eventuella driftstopp redundansväxlar databasservern automatiskt till väntelägesrepliken. Mer information finns i Begrepp – Hög tillgänglighet. | Stöds i generell användning och Affärskritisk beräkningsnivåer. Endast tillgängligt i regioner där flera zoner är tillgängliga. |
| Premium-filresurser | Databasfiler lagras i en mycket beständig och tillförlitlig Azure Premium-filresurser som ger dataredundans med tre kopior av repliker som lagras i en tillgänglighetszon med funktioner för automatisk dataåterställning. Mer information finns i Premium-filresurser. | Data som lagras i en tillgänglighetszon |
Planerad stilleståndstidsreducering
Här följer några scenarier för planerat underhåll som medför stilleståndstid:
När den flexibla servern konfigureras med zonredundant hög tillgänglighet utför den flexibla servern först åtgärder på väntelägesservern och sedan på den primära servern utan redundansväxling. Mer information finns i Begrepp – Hög tillgänglighet.
Åtgärder för oplanerade driftstopp
Oplanerade driftstopp kan uppstå till följd av oförutsedda fel, inklusive underliggande maskinvarufel, nätverksproblem och programvarubuggar. Om databasservern oväntat kraschar, om den konfigureras med hög tillgänglighet [HA], aktiveras väntelägesrepliken. Annars etableras en ny databasserver automatiskt. Det går inte att undvika en oplanerad stilleståndstid, men den flexibla servern minskar stilleståndstiden genom att automatiskt utföra återställningsåtgärder på både databasservern och lagringsskikten utan mänsklig inblandning.
Oplanerad stilleståndstid: felscenarier och tjänståterställning
Här följer några oplanerade felscenarier och återställningsprocessen:
| Scenario | Återställningsprocess [icke-HA] | Återställningsprocess [HA] |
|---|---|---|
| Databasserverfel | Om databasservern är nere på grund av ett underliggande maskinvarufel avbryts aktiva anslutningar och eventuella inflight-transaktioner avbryts. Azure försöker starta om databasservern. Om det lyckas utförs databasåterställningen. Om omstarten misslyckas görs ett försök att starta om databasservern på en annan fysisk nod. Återställningstiden (RTO) beror på olika faktorer, inklusive aktiviteten vid tidpunkten för felet, till exempel stora transaktioner och hur mycket återställning som ska utföras under startprocessen för databasservern. RPO är noll eftersom ingen dataförlust förväntas för de checkade transaktionerna. Program som använder MySQL-databaserna måste byggas på ett sätt som gör att de identifierar och försöker avbryta anslutningar och misslyckade transaktioner igen. När programmet försöker igen dirigeras anslutningarna till den nyligen skapade databasservern. Andra tillgängliga alternativ återställs från säkerhetskopian. Du kan använda både PITR- eller Geo-återställning från en länkad region. PITR : RTO: Varierar, RPO=0sec Geo-återställning: RTO: Varierar RPO <1 h. Du kan också använda skrivskyddade repliker som DR-lösning. Du kan stoppa replikeringen, vilket gör att skrivskyddad replik skrivs (fristående och sedan omdirigerar programtrafiken till den här databasen). RTO är i de flesta fall några minuter och RPO < 1 h. RTO och RPO kan vara mycket högre i vissa fall beroende på olika faktorer, inklusive svarstid mellan platser, mängden data som ska överföras och framför allt den primära databasskrivningsarbetsbelastningen. |
Om databasserverfel eller fel som inte kan återställas identifieras aktiveras väntelägesdatabasservern, vilket minskar stilleståndstiden. Mer information finns på sidan ha-begrepp. RTO förväntas vara 60–120 s, med RPO=0. Obs! Alternativen för återställningsprocessen [icke-HA] gäller även här. |
| Lagringsfel | Program ser ingen inverkan på lagringsrelaterade problem, till exempel ett diskfel eller en fysisk blockskada. Eftersom data lagras i tre kopior hanteras kopian av data av den kvarvarande lagringen. Blockfel korrigeras automatiskt. Om en kopia av data går förlorad skapas automatiskt en ny kopia av data. I ett sällsynt eller värsta scenario om alla kopior är skadade kan vi använda återställning från geo-återställning (länkad region). RPO skulle vara < 1 h och RTO skulle variera. Du kan också använda skrivskyddade repliker som DR-lösning enligt beskrivningen ovan. |
I det här scenariot är alternativen samma som för återställningsprocessen [icke-HA] . |
| Logiska/användarfel | Återställning från användarfel, till exempel oavsiktligt borttagna tabeller eller felaktigt uppdaterade data, innebär att du utför en återställning till tidpunkt (PITR) genom att återställa och återställa data fram till den tid som precis innan felet inträffade. Du kan återställa en borttagen flexibel serverresurs inom fem dagar från det att servern togs bort. En detaljerad guide om hur du återställer en borttagen server finns i [se dokumenterade steg] (.. /flexible-server/how-to-restore-dropped-server.md). Administratörer kan använda hanteringslås för att skydda serverresurser efter distributionen från oavsiktlig borttagning eller oväntade ändringar. |
Dessa användarfel skyddas inte med hög tillgänglighet eftersom alla användaråtgärder också replikeras till vänteläge. I det här scenariot är alternativen samma som för återställningsprocessen [icke-HA] |
| Fel i tillgänglighetszon | Även om det är en sällsynt händelse kan du utföra geo-återställning från en länkad region om du vill återställa från ett fel på zonnivå. RPO skulle vara <1 h och RTO skulle variera. Du kan också använda read replica som DR-lösning genom att skapa en replik i en annan tillgänglighetszon. RTO\RPO liknar det som beskrivs ovan. |
Om du har aktiverat Zonredundant HA utför den flexibla servern automatisk redundansväxling till väntelägesplatsen. Mer information finns i HA-begrepp. RTO förväntas vara 60–120 s, med RPO=0. Andra tillgängliga alternativ återställs från säkerhetskopian. Du kan använda både PITR- eller Geo-återställning från en länkad region. PITR: RTO: Varierar, RPO=0 sek Geo-återställning: RTO: Varierar, RPO <1 h Obs! Om du har samma zon-HA aktiverat är alternativen samma som för återställningsprocessen [icke-HA]. |
| Regionfel | Även om det är en sällsynt händelse kan du utföra databasåterställning genom att skapa en ny server med hjälp av den senaste geo-redundanta säkerhetskopian som är tillgänglig under samma prenumeration för att komma åt de senaste data om du vill återställa en ny server. En ny flexibel server distribueras till den valda regionen. Hur mycket tid det tar att återställa beror på den tidigare säkerhetskopieringen och antalet transaktionsloggar som ska återställas. RPO i de flesta fall skulle vara <1 h och RTO skulle variera. | I det här scenariot är alternativen samma som för återställningsprocessen [icke-HA] . |
Krav och begränsningar
Regiondatahemvist
Som standard flyttar eller lagrar inte Azure Database for MySQL – flexibel server kunddata från den region som den distribueras i. Kunder kan dock välja att aktivera geo-redundanta säkerhetskopieringar eller konfigurera replikering mellan regioner för lagring av data i en annan region.
Nästa steg
- Läs mer om zonredundant hög tillgänglighet
- Lär dig mer om säkerhetskopiering och återställning