Not
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Hög tillgänglighet är en viktig funktion i Azure Database for MySQL, utformad för att minimera stilleståndstid och se till att dina program förblir tillgängliga även under planerat underhåll eller oväntade avbrott. Den här artikeln tar upp vanliga frågor om alternativ för hög tillgänglighet (HA), fakturering, redundansprocesser, prestandapåverkan och metodtips som hjälper dig att fatta välgrundade beslut för dina MySQL-arbetsbelastningar i Azure.
Vilka är serviceavtalen för lokala redundanta eller zonredundanta HA-aktiverade flexibla servrar?
SLA-information för Azure Database for MySQL – flexibel server finns i SLA för Azure Database for MySQL.
Hur debiteras jag för högtillgängliga servrar (HA) ?
Servrar som är aktiverade med HA har en primär och sekundär replik. Sekundär replik kan vara i samma zon eller zonredundant. Du debiteras för den etablerade beräkningen och lagringen för både den primära och sekundära repliken. Om du till exempel har en primär med 4 virtuella kärnor av beräkning och 512 GB etablerad lagring har den sekundära repliken 4 virtuella kärnor och 512 GB etablerad lagring.
Din zonredundanta HA-server debiteras för 8 virtuella kärnor och 1 024 GB lagringsutrymme. Beroende på din lagringsvolym för säkerhetskopiering kan du också debiteras för lagring av säkerhetskopior.
Kan jag använda väntelägesrepliken för läs- eller skrivåtgärder?
Väntelägesservern är inte tillgänglig för läs- eller skrivåtgärder. Det är ett passivt vänteläge för att aktivera snabb redundans.
Kommer jag att förlora data när redundansväxling sker?
Loggar i ZRS är tillgängliga även när den primära servern inte är tillgänglig. Den här tillgängligheten hjälper till att säkerställa att data inte går förlorade. När väntelägesrepliken har aktiverats och binära loggar har tillämpats tar den rollen som primär server.
Behöver jag vidta några åtgärder efter en redundansväxling?
Avbrottsförebyggande åtgärder är helt transparenta för klientapplikationen. Du behöver inte vidta några åtgärder. Program bör bara använda logiken för återförsök för sina anslutningar.
Vad händer när jag inte väljer en specifik zon för min standby-replik? Kan jag ändra zonen senare?
Om du inte väljer en zon väljs en slumpmässigt. Det är den som används för den primära servern. Om du vill ändra zonen senare kan du ange Hög tillgänglighet till Inaktiverad i fönstret Hög tillgänglighet och sedan ställa in den på Zonredundant och välja en zon.
Är replikeringen mellan de primära replikerna och väntelägesreplikerna synkrona?
Replikeringen mellan det primära och vänteläget liknar semisynkront läge i MySQL. När en transaktion har checkats in checkas den inte nödvändigtvis in i vänteläget. Men när den primära är otillgänglig replikerar vänteläget alla dataändringar från den primära för att se till att inga data går förlorade.
Finns det en redundansväxling till väntelägesrepliken för alla oplanerade fel?
Om det uppstår ett databaskrasch- eller nodfel startas den virtuella datorn för flexibel server om på samma nod. Samtidigt utlöses en automatisk redundansväxling. Om omstarten av Flexible Server VM lyckas innan failover är klar, avbryts failoveroperationen. Vilken server som ska användas som primär replik beror på vilken process som slutförs först.
Finns det en prestandapåverkan när jag använder HA?
För zonredundant HA, medan det inte finns någon större prestandapåverkan för läsbelastningar i tillgänglighetszoner, kan latensen för skrivförfrågningar öka med upp till 40 procent. Ökningen av skrivfördröjning beror på synkron replikering i tillgänglighetszonen. Skrivlatensens påverkan är två gånger så stor i HA med zonredundans jämfört med HA inom samma zon. För Lokalt redundant HA, eftersom den primära repliken och väntelägesrepliken finns i samma zon, är replikeringsfördröjningen och därmed den synkrona skrivfördröjningen lägre.
Sammanfattningsvis, om skrivfördröjning är mer kritisk för dig jämfört med tillgänglighet, kanske du vill välja lokalt redundant HA, men om tillgänglighet och motståndskraft hos dina data är mer kritisk för dig på bekostnad av försämring av skrivfördröjningen, måste du välja zonredundant HA. För att mäta den korrekta effekten av svarstidsminskningen i HA-konfigurationen rekommenderar vi att du utför prestandatestning för din arbetsbelastning för att fatta ett välgrundat beslut.
Hur sker underhållet av min HA-server?
Planerade händelser som skalning av beräknings- och delversionsuppgraderingar sker först på den ursprungliga väntelägesinstansen, och därefter utlöses en planerad redundansåtgärd och körs sedan på den ursprungliga primära instansen. Du kan ange det schemalagda underhållsfönstret för HA-servrar precis som för flexibla servrar. Stilleståndstiden är samma som stilleståndstiden för Azure Database for MySQL – flexibel serverinstans när HA är inaktiverat.
Kan jag göra en återställning till tidpunkt (PITR) för min HA-server?
Du kan göra en PITR för en HA-aktiverad Azure Database for MySQL Flexible Server-instans till en ny Azure Database for MySQL Flexible Server-instans som har HA inaktiverat. Om källservern skapades med zonredundant HA kan du aktivera zonredundant HA eller lokal redundant HA på den återställda servern senare. Om källservern skapades med lokalt redundant ha kan du endast aktivera lokalt redundant HA på den återställda servern.
Kan jag aktivera HA på en server när jag har skapat servern?
Zonredundant HA måste aktiveras när servern skapas. Du kan aktivera lokalt redundant ha när servern har skapats, men se till att serverparametrarna enforce_gtid_consistency och gtid_mode är inställda på ON innan du fortsätter.
Kan jag inaktivera HA för en server när jag har skapat den?
Du kan inaktivera HA på en server när du har skapat den. Faktureringen stoppas omedelbart.
Hur kan jag minska stilleståndstiden?
Du måste kunna minska stilleståndstiden för ditt program även när du inte använder HA. Tjänstavbrott, till exempel schemalagda korrigeringar, delversionsuppgraderingar eller kundinitierade åtgärder som skalning av beräkning, kan utföras under schemalagda underhållsperioder. För att minska programpåverkan för Azure-initierade underhållsaktiviteter kan du schemalägga dem en dag i veckan och tid som minimerar effekten på programmet.
Kan jag använda en läsreplik för en HA-aktiverad server?
Ja, läsrepliker stöds för HA-servrar.
Kan jag använda datareplikering för HA-servrar?
Stöd för datareplikering för hög tillgänglighet (HA) aktiverad server är endast tillgängligt via GTID-baserad replikering.
Den lagrade proceduren för replikering med GTID är tillgänglig på alla HA-aktiverade servrar med namnet mysql.az_replication_with_gtid.
Kan jag växla över till väntelägesservern när servern startas om eller vid upp- eller nedskalning för att minska stilleståndstiden?
För närvarande har Azure Database for MySQL – flexibel server använt planerad redundans för att optimera HA-åtgärderna, inklusive upp-/nedskalning och planerat underhåll för att minska stilleståndstiden.
När sådana åtgärder startades skulle den fungera på den ursprungliga väntelägesinstansen först, följt av att utlösa en planerad redundansåtgärd och sedan köras på den ursprungliga primära instansen.
Kan vi ändra tillgänglighetsläget (zonredundant HA/Lokalt redundant) för servern**
Om du skapar servern med zonredundant HA-läge aktiverat kan du ändra från Zonredundant HA till Lokalt redundant och vice versa.
Om du vill ändra tillgänglighetsläget kan du ange Hög tillgänglighet till Inaktiverad i fönstret Hög tillgänglighet och sedan ställa in den på Zonredundant eller Lokalt redundant och välja Läge för hög tillgänglighet.