Události
SQL ve společnosti FabCon Vegas
31. 3. 23 - 2. 4. 23
Konečná událost vedoucí komunitou SQL, Power BI, Fabric a AI. 31. března – 2. dubna. Použijte kód MSCUST pro slevu ve výši 150 USD.
Zaregistrovat se ještě dnesTento prohlížeč se už nepodporuje.
Upgradujte na Microsoft Edge, abyste mohli využívat nejnovější funkce, aktualizace zabezpečení a technickou podporu.
Flexibilní server Azure Database for MySQL umožňuje konfigurovat vysokou dostupnost pomocí automatického převzetí služeb při selhání. Řešení vysoké dostupnosti je navržené tak, aby se zajistilo, že potvrzená data se nikdy neztratí z důvodu selhání a že databáze nebude v rámci softwarové architektury kritický prvek způsobující selhání. Pokud je nakonfigurovaná vysoká dostupnost, flexibilní server automaticky zřídí a spravuje pohotovostní repliku. Za zřízené výpočetní prostředky a úložiště se vám účtuje jak primární, tak sekundární replika. K dispozici jsou dva modely architektury pro vysokou dostupnost:
Zónově redundantní vysoká dostupnost. Tato možnost je upřednostňovaná pro úplnou izolaci a redundanci infrastruktury napříč několika zónami dostupnosti. Poskytuje nejvyšší úroveň dostupnosti, ale vyžaduje, abyste nakonfigurovali redundanci aplikace napříč zónami. Zónově redundantní vysoká dostupnost je upřednostňovaná, pokud chcete dosáhnout nejvyšší úrovně dostupnosti proti selhání infrastruktury v zóně dostupnosti a kdy je latence napříč zónou dostupnosti přijatelná. Je možné ho povolit pouze při vytváření serveru. Zónově redundantní vysoká dostupnost je dostupná v podmnožině oblastí Azure, kde tato oblast podporuje více zón dostupnosti a zónově redundantní sdílené složky Premium jsou k dispozici.
Stejná zóna ha. Tato možnost je upřednostňovaná pro redundanci infrastruktury s nižší latencí sítě, protože primární a pohotovostní servery budou ve stejné zóně dostupnosti. Poskytuje vysokou dostupnost bez nutnosti konfigurovat redundanci aplikací napříč zónami. Vysoká dostupnost se stejnou zónou se upřednostňuje, pokud chcete dosáhnout nejvyšší úrovně dostupnosti v rámci jedné zóny dostupnosti s nejnižší latencí sítě. Vysoká dostupnost se stejnou zónou je dostupná ve všech oblastech Azure, kde můžete použít flexibilní server Azure Database for MySQL.
Když nasadíte server se zónově redundantní vysokou dostupností, vytvoří se dva servery:
Můžete zvolit zónu dostupnosti pro primární a pohotovostní repliku. Umístění pohotovostních databázových serverů a pohotovostních aplikací do stejné zóny snižuje latenci. Umožňuje také lépe připravit se na situace zotavení po havárii a scénáře "zón mimo provoz".
Data a soubory protokolů jsou hostované v zónově redundantním úložišti (ZRS). Pohotovostní server čte a přehrává soubory protokolu nepřetržitě z účtu úložiště primárního serveru, který je chráněný replikací na úrovni úložiště.
Pokud dojde k převzetí služeb při selhání:
Protokoly v ZRS jsou přístupné i v případě, že primární server není k dispozici. Tato dostupnost pomáhá zajistit, aby nedošlo ke ztrátě dat. Po aktivaci pohotovostní repliky a použití binárních protokolů převezme aktuální pohotovostní server repliky roli primárního serveru. DNS se aktualizuje, aby se připojení klientů při opětovném připojení klienta směrovala na novou primární. Převzetí služeb při selhání je plně transparentní z klientské aplikace a nevyžaduje od vás žádnou akci. Řešení vysoké dostupnosti pak vrátí starý primární server, pokud je to možné, a umístí ho jako pohotovostní server.
Název databázového serveru slouží k připojení aplikací k primárnímu serveru. Informace o pohotovostní replice nejsou přístupné pro přímý přístup. Potvrzení a zápisy se potvrdí po vyprázdnění souborů protokolu na ZRS primárního serveru. Vzhledem k technologii replikace synchronizace používané v úložišti ZRS můžete očekávat 5 až 10procentní zvýšenou latenci pro zápisy a potvrzení aplikací.
Automatické zálohování, snímky i zálohy protokolů, se provádí v zónově redundantním úložišti z primárního databázového serveru.
Když nasadíte server se stejnou zónou ha, vytvoří se ve stejné zóně dva servery:
Pohotovostní server nabízí redundanci infrastruktury pomocí samostatného virtuálního počítače (výpočetních prostředků). Tato redundance snižuje dobu převzetí služeb při selhání a latenci sítě mezi aplikací a databázovým serverem kvůli kolokaci.
Data a soubory protokolů jsou hostované v místně redundantním úložišti (LRS). Pohotovostní server čte a přehrává soubory protokolu nepřetržitě z účtu úložiště primárního serveru, který je chráněný replikací na úrovni úložiště.
Pokud dojde k převzetí služeb při selhání:
Protokoly v LRS jsou přístupné i v případě, že primární server není dostupný. Tato dostupnost pomáhá zajistit, aby nedošlo ke ztrátě dat. Po aktivaci pohotovostní repliky a použití binárních protokolů převezme aktuální pohotovostní replika roli primárního serveru. Dns se aktualizuje tak, aby při opětovném připojení klienta přesměrovává připojení k nové primární síti. Převzetí služeb při selhání je plně transparentní z klientské aplikace a nevyžaduje od vás žádnou akci. Řešení vysoké dostupnosti pak vrátí starý primární server, pokud je to možné, a umístí ho jako pohotovostní server.
Název databázového serveru slouží k připojení aplikací k primárnímu serveru. Informace o pohotovostní replice nejsou přístupné pro přímý přístup. Potvrzení a zápisy se potvrdí po vyprázdnění souborů protokolu na LRS primárního serveru. Protože primární a pohotovostní replika jsou ve stejné zóně, je mezi aplikačním serverem a databázovým serverem menší prodleva replikace a nižší latence. Nastavení stejné zóny neposkytuje vysokou dostupnost, pokud jsou závislé infrastruktury pro konkrétní zónu dostupnosti mimo provoz. Dojde k výpadkům, dokud nebudou všechny závislé služby pro danou zónu dostupnosti zase online.
Automatické zálohování, snímky i zálohy protokolů, se provádí na místně redundantním úložišti z primárního databázového serveru.
Poznámka
Pro zónově redundantní i stejnou zónu ha:
Během procesu převzetí služeb při selhání ve službě Azure Database for MySQL se systém automaticky přepne z primárního serveru na pohotovostní repliku, aby se zajistila kontinuita a minimalizovala výpadky. Při zjištění selhání se pohotovostní replika zvýší na nový primární server. Binární soubory protokolu z původního primárního serveru se použijí na pohotovostní repliku, aby se synchronizovaly s poslední potvrzenou transakcí, čímž se zajistí žádná ztráta dat. Tento bezproblémový přechod pomáhá udržovat vysokou dostupnost a spolehlivost databázové služby.
Flexibilní server Azure Database for MySQL s vynuceným převzetím služeb při selhání umožňuje ruční vynucení převzetí služeb při selhání. Tato funkce vám umožní otestovat funkčnost ve scénářích aplikace a pomůže vám připravit se na výpadky.
Vynucené převzetí služeb při selhání aktivuje převzetí služeb při selhání, které aktivuje záložní repliku, aby se stala primárním serverem se stejným názvem databázového serveru, a to aktualizací záznamu DNS. Původní primární server se restartuje a přepne do záložní repliky. Klientská připojení jsou odpojena a pro obnovení jejich provozu je potřeba je znovu připojit.
Celková doba převzetí služeb při selhání závisí na aktuální úloze a posledním kontrolním bodě. Obecně se očekává, že bude trvat 60 až 120 sekund.
Poznámka
Událost služby Azure Resource Health se generuje v případě plánovaného převzetí služeb při selhání představující dobu převzetí služeb při selhání, během které server nebyl k dispozici. Aktivované události se dají zobrazit, když v levém podokně vyberete Resource Health. Uživatelem zahájené/ Ruční převzetí služeb při selhání je reprezentováno stavem Nedostupné a označeno jako Plánované. Příklad : Operace převzetí služeb při selhání aktivovala autorizovaný uživatel (plánované). Pokud váš prostředek zůstane v tomto stavu po delší dobu, otevřete lístek podpory a my vám pomůžeme.
Neplánované výpadky služby můžou být způsobené chybami softwaru nebo infrastruktury, jako jsou chyby výpočetních prostředků, sítě nebo úložiště nebo výpadky napájení, které ovlivňují dostupnost databáze. Pokud databáze přestane být dostupná, replikace na pohotovostní repliku se přeruší a pohotovostní replika se aktivuje jako primární databáze. Dns se aktualizuje a klienti se znovu připojí k databázovému serveru a obnoví jejich operace.
Celková doba převzetí služeb při selhání se očekává v rozmezí 60 až 120 sekund. V závislosti na aktivitě primárního databázového serveru v době převzetí služeb při selhání (jako jsou velké transakce a doba obnovení) ale může převzetí služeb při selhání trvat déle.
Poznámka
Událost služby Azure Resource Health se generuje v případě neplánovaného převzetí služeb při selhání, což představuje dobu převzetí služeb při selhání, během které byl server nedostupný. Aktivované události se dají zobrazit, když v levém podokně vyberete Resource Health. Automatické převzetí služeb při selhání je reprezentováno stavem Nedostupné a označeno jako Neplánované. Příklad – Nedostupné: Automaticky se aktivovala operace převzetí služeb při selhání (neplánovaná). Pokud váš prostředek zůstane v tomto stavu po delší dobu, otevřete lístek podpory a my vám pomůžeme.
Primární server a sekundární server mají dva koncové body sítě.
Komponenta monitorování stavu nepřetržitě provádí následující kontroly.
Poznámka
Pokud mezi aplikací a koncovým bodem sítě zákazníka (privátním nebo veřejným přístupem) dojde k nějakému problému se sítí, a to buď v síťové cestě, v koncovém bodu nebo v případě problémů s DNS na straně klienta, kontrola stavu tento scénář nemonitoruje. Pokud používáte privátní přístup, ujistěte se, že pravidla skupiny zabezpečení sítě pro virtuální síť neblokují komunikaci s koncovým bodem sítě zákazníka instance na portu 3306. Pro veřejný přístup se ujistěte, že jsou nastavená pravidla brány firewall a že je síťový provoz povolený na portu 3306 (pokud síťová cesta obsahuje jiné brány firewall). Musí se také postarat o překlad DNS ze strany klientské aplikace.
Stav vysoké dostupnosti umístěný v podokně Vysoká dostupnost serveru na portálu se dá použít k určení stavu konfigurace vysoké dostupnosti serveru.
Stav | Popis |
---|---|
NotEnabled | Vysoká dostupnost není povolená. |
Replikace dat | Pohotovostní server probíhá při synchronizaci s primárním serverem v době zřizování serveru vysoké dostupnosti nebo při povolení možnosti vysoké dostupnosti. |
Převzetí služeb při selhání | Databázový server probíhá v procesu převzetí služeb při selhání z primárního do pohotovostního režimu. |
Zdravý | Je povolená možnost ha. |
Odebránístandby | Když je možnost ha zakázaná a proces odstranění probíhá. |
K monitorování stavu serveru vysoké dostupnosti můžete použít také následující metriky.
Zobrazovaný název metriky | Metrika | Unit | Popis |
---|---|---|---|
Stav vstupně-výstupních operací vysoké dostupnosti | ha_io_running | State | Stav vstupně-výstupních operací vysoké dostupnosti označuje stav replikace vysoké dostupnosti. Hodnota metriky je 1, pokud je spuštěné vstupně-výstupní vlákno a 0, pokud ne. |
Stav SQL vysoké dostupnosti | ha_sql_running | State | Stav HA SQL označuje stav replikace vysoké dostupnosti. Hodnota metriky je 1, pokud je vlákno SQL spuštěné a 0, pokud ne. |
Prodleva replikace vysoké dostupnosti | replication_lag | Sekundy | Prodleva replikace je počet sekund, po které je pohotovostní režim za sebou při přehrání transakcí přijatých na primárním serveru. |
Tady je několik aspektů, které je potřeba vzít v úvahu při použití vysoké dostupnosti:
Poznámka
Pokud po vytvoření serveru povolíte stejnou zónu vysoké dostupnosti, musíte před povolením vysoké dostupnosti zajistit, aby parametry serveru enforce_gtid_consistency a gtid_mode byly nastaveny na ZAPNUTO.
Poznámka
Automatické zvětšování úložiště je ve výchozím nastavení povolené pro server s vysokou dostupností a nedá se zakázat.
Při konfiguraci vysoké dostupnosti (HA) pro Azure Database for MySQL hrají kontroly stavu zásadní roli při zachování spolehlivosti a výkonu vaší databáze. Tyto kontroly nepřetržitě monitorují stav a stav primárních i pohotovostních replik a zajišťují, aby se všechny problémy zjistily okamžitě. Sledováním různých metrik, jako je odezva serveru, prodleva replikace a využití prostředků, pomáhají kontroly stavu zajistit, aby se procesy převzetí služeb při selhání mohly bez problémů spouštět, minimalizovat výpadky a bránit ztrátě dat. Správně nakonfigurované kontroly stavu jsou nezbytné pro dosažení požadované úrovně dostupnosti a odolnosti v nastavení databáze.
Uživatelé můžou monitorovat stav nastavení vysoké dostupnosti prostřednictvím webu Azure Portal. Mezi klíčové metriky, které se mají sledovat, patří:
Jaké jsou smlouvy SLA pro flexibilní server se stejnou zónou a zónově redundantní vysokou dostupností?
Informace o sla pro flexibilní server Azure Database for MySQL najdete ve sla pro Azure Database for MySQL.
Jak se mi účtují servery s vysokou dostupností (HA)? Servery s podporou vysoké dostupnosti mají primární a sekundární repliku. Sekundární replika může být ve stejné zóně nebo zóně redundantní. Za zřízené výpočetní prostředky a úložiště se vám účtuje jak primární, tak sekundární replika. Pokud máte například primární se 4 virtuálními jádry pro výpočetní prostředky a 512 GB zřízeného úložiště, bude mít sekundární replika také 4 virtuální jádra a 512 GB zřízeného úložiště. Za zónově redundantní server s vysokou dostupností se bude účtovat 8 virtuálních jader a 1 024 GB úložiště. V závislosti na svazku úložiště záloh se vám také může účtovat úložiště zálohování.
Můžu pro operace čtení nebo zápisu použít pohotovostní repliku?
Pohotovostní server není k dispozici pro operace čtení nebo zápisu. Jedná se o pasivní pohotovostní režim, který umožňuje rychlé převzetí služeb při selhání.
Dojde ke ztrátě dat, když dojde k převzetí služeb při selhání?
Protokoly v ZRS jsou přístupné i v případě, že primární server není k dispozici. Tato dostupnost pomáhá zajistit, aby nedošlo ke ztrátě dat. Po aktivaci pohotovostní repliky a použití binárních protokolů převezme roli primárního serveru.
Musím po převzetí služeb při selhání provést nějakou akci?
Převzetí služeb při selhání je plně transparentní z klientské aplikace. Nemusíte nic dělat. Aplikace by pro svá připojení měly používat logiku opakování.
Co se stane, když pro svoji pohotovostní repliku nevyberem konkrétní zónu? Můžu zónu později změnit?
Pokud nevyberete zónu, vybere se náhodně. Bude to ten, který se použije pro primární server. Pokud chcete zónu později změnit, můžete nastavit vysokou dostupnost na Zakázáno v podokně Vysoká dostupnost a pak ji nastavit zpět na Zónově redundantní a zvolit zónu.
Je replikace mezi primární a pohotovostní replikou synchronní?
Replikace mezi primárním a pohotovostním režimem je podobná polosynchronnímu režimu v MySQL. Když je transakce potvrzena, nemusí se nutně potvrdit do pohotovostního režimu. Pokud ale primární server není dostupný, pohotovostní režim replikuje všechny změny dat z primárního serveru, aby se zajistilo, že nedojde ke ztrátě dat.
Existuje převzetí služeb při selhání pohotovostní repliky pro všechna neplánovaná selhání?
Pokud dojde k selhání databáze nebo uzlu, virtuální počítač flexibilního serveru se restartuje na stejném uzlu. Zároveň se aktivuje automatické převzetí služeb při selhání. Pokud je restartování virtuálního počítače s flexibilním serverem úspěšné před dokončením převzetí služeb při selhání, operace převzetí služeb při selhání se zruší. Určení serveru, který se má použít jako primární replika, závisí na procesu, který se dokončí jako první.
Má při použití vysoké dostupnosti vliv na výkon?
V případě zónově redundantní vysoké dostupnosti sice nemá žádný velký dopad na výkon úloh čtení napříč zónami dostupnosti, ale může docházet až ke 40procentnímu poklesu latence dotazů na zápis. Zvýšení latence zápisu je způsobené synchronní replikací napříč zónou dostupnosti. Dopad latence zápisu je obecně dvakrát v zónově redundantní vysoké dostupnosti ve srovnání se stejnou zónou HA. Pro stejnou zónu ha, protože primární a pohotovostní replika je ve stejné zóně, latence replikace a následně synchronní latence zápisu je nižší. Pokud je latence zápisu pro vás v porovnání s dostupností důležitější, můžete zvolit vysokou dostupnost se stejnou zónou, ale pokud je dostupnost a odolnost vašich dat důležitější, musíte zvolit zónově redundantní vysokou dostupnost. Pokud chcete změřit přesný dopad poklesu latence v nastavení vysoké dostupnosti, doporučujeme provést testování výkonu pro vaši úlohu a přijmout informované rozhodnutí.
Jak dochází k údržbě serveru vysoké dostupnosti?
Plánované události, jako je škálování výpočetních prostředků a upgradů podverze, probíhají nejprve v původní pohotovostní instanci a následně aktivují plánovanou operaci převzetí služeb při selhání a potom pracují s původní primární instancí. Časové období plánované údržby pro servery s vysokou dostupností můžete nastavit stejně jako u flexibilních serverů. Velikost výpadku bude stejná jako výpadek instance flexibilního serveru Azure Database for MySQL, když je zakázaná vysoká dostupnost.
Můžu provést obnovení k určitému bodu v čase (PITR) serveru s vysokou dostupností?
Pro instanci flexibilního serveru Azure Database for MySQL s podporou vysoké dostupnosti můžete provést obnovení k určitému bodu obnovení do nové instance flexibilního serveru Azure Database for MySQL, která má zakázanou vysokou dostupnost. Pokud byl zdrojový server vytvořen s zónově redundantní vysokou dostupností, můžete na obnoveném serveru později povolit zónově redundantní vysokou dostupnost nebo stejnou zónu HA. Pokud byl zdrojový server vytvořen se stejnou zónou HA, můžete na obnoveném serveru povolit pouze vysokou dostupnost se stejnou zónou.
Můžu povolit vysokou dostupnost na serveru po vytvoření serveru?
Při vytváření serveru je potřeba povolit zónově redundantní vysokou dostupnost. Vysokou dostupnost se stejnou zónou můžete povolit po vytvoření serveru. Před povolením stejné zóny se ujistěte, že jsou parametry serveru enforce_gtid_consistency a gtid_mode nastaveny na zapnuto.
Můžu vysokou dostupnost serveru po vytvoření zakázat?
Vysokou dostupnost na serveru můžete po vytvoření zakázat. Fakturace se okamžitě zastaví.
Jak můžu zmírnit výpadky?
Musíte být schopni zmírnit výpadky aplikace i v případě, že nepoužíváte vysokou dostupnost. Výpadek služby, jako jsou plánované opravy, upgrady podverze nebo operace iniciované zákazníkem, jako je škálování výpočetních prostředků, je možné provádět během plánovaných časových období údržby. Pokud chcete zmírnit dopad aplikace na úlohy údržby iniciované platformou Azure, můžete je naplánovat na den v týdnu a čas, který minimalizuje dopad na aplikaci.
Můžu pro server s podporou vysoké dostupnosti použít repliku pro čtení?
Ano, repliky pro čtení jsou podporované pro servery s vysokou dostupností.
Můžu pro servery s vysokou dostupností použít replikaci příchozích dat?
Podpora replikace příchozích dat pro server s podporou vysoké dostupnosti je dostupná pouze prostřednictvím replikace založené na GTID.
Uložená procedura pro replikaci pomocí GTID je k dispozici na všech serverech s podporou vysoké dostupnosti podle názvu mysql.az_replication_with_gtid
.
Pokud chcete snížit výpadky, můžu převzít služby při selhání na pohotovostní server během restartování serveru nebo při vertikálním navýšení nebo snížení kapacity?
Flexibilní server Azure Database for MySQL v současné době má nastavené plánované převzetí služeb při selhání, aby se přihlásil k operacím vysoké dostupnosti, včetně vertikálního navýšení/snížení kapacity, a plánované údržby, aby se snížil výpadek.
Když se tyto operace spustily, nejprve by fungovaly v původní pohotovostní instanci, následně aktivovaly plánovanou operaci převzetí služeb při selhání a potom fungovaly s původní primární instancí.
Můžeme změnit režim dostupnosti (zónově redundantní vysoká dostupnost nebo stejná zóna) serveru
, pokud vytvoříte server s povoleným režimem zónově redundantní vysoké dostupnosti, pak můžete změnit zónově redundantní vysokou dostupnost na stejnou zónu a naopak. Pokud chcete změnit režim dostupnosti, můžete nastavit vysokou dostupnost na Zakázáno v podokně Vysoká dostupnost a pak ho nastavit zpět na Zónově redundantní nebo stejnou zónu a zvolit Režim vysoké dostupnosti.
Události
SQL ve společnosti FabCon Vegas
31. 3. 23 - 2. 4. 23
Konečná událost vedoucí komunitou SQL, Power BI, Fabric a AI. 31. března – 2. dubna. Použijte kód MSCUST pro slevu ve výši 150 USD.
Zaregistrovat se ještě dnesŠkolení
Modul
Nasazení vysoce dostupných řešení pomocí Azure SQL - Training
V tomto modulu se dozvíte, jak nasadit vysoce dostupná řešení pomocí Azure SQL. Také poznáte architektury jejich vliv na dostupnost.
Certifikace
Microsoft Certified: Přidružení správce služby Azure Database - Certifications
Správa infrastruktury databáze SQL Serveru pro cloudové, místní a hybridní relační databáze pomocí nabídek relačních databází Microsoft PaaS.