Automatická migrace na místě z Azure Database for MySQL – z jednoúčelového serveru na flexibilní server

PLATÍ PRO: Jednoúčelový server Azure Database for MySQL

Místní automatická migrace z Jednoúčelového serveru Azure Database for MySQL – Jednoúčelový server na flexibilní server je místní migrace zahájená během časového období plánované údržby pro databázové úlohy jednoúčelového serveru se skladovou jednotkou Basic, Pro obecné účely nebo Optimalizováno pro paměť a bez složitých funkcí (replika čtení, virtuální síť, dvojité šifrování infra, koncový bod služby nebo pravidla virtuální sítě). Způsobilé servery jsou identifikovány službou a je jim předem zasláno oznámení s podrobnostmi o krocích k přezkoumání podrobností migrace.

Místní migrace poskytuje vysoce odolné a samoopravené prostředí offline migrace během časového období plánované údržby s méně než 5 minut výpadky pro skladovou položku pro obecné účely a optimalizováno pro paměť a až 30 minut pro skladovou položku Basic. K rychlejší migraci využívá technologii zálohování a obnovení. Tato migrace eliminuje režii ruční migrace serveru a zajišťuje, abyste mohli využívat výhody flexibilního serveru, včetně lepší ceny a výkonu, podrobné kontroly nad konfigurací databáze a časovými obdobími vlastní údržby. Tady jsou popsané klíčové fáze migrace:

• Cílový flexibilní server je nasazený a dědí všechny sady funkcí a vlastnosti (včetně parametrů serveru a pravidel brány firewall) ze zdrojového jednoúčelového serveru. Zdrojový jeden server je nastavený na jen pro čtení a zálohování ze zdrojového jednoúčelového serveru se zkopíruje do cílového flexibilního serveru.
• Přepínač DNS a přímá migrace se úspěšně provádějí v rámci časového období plánované údržby s minimálními výpadky, což umožňuje údržbu stejného připojovací řetězec po migraci. Klientské aplikace se bezproblémově připojují k cílovému flexibilnímu serveru bez jakýchkoli ručních aktualizací řízených uživatelem. Kromě podporovaných formátů připojovací řetězec (jednoúčelového i flexibilního serveru) na migrovaném flexibilním serveru se podporují i formáty uživatelského jména – username@server_name i uživatelské jméno na migrovaném flexibilním serveru.
• Migrovaný flexibilní server je online a dá se teď spravovat přes Azure Portal nebo rozhraní příkazového řádku. Zastavený jednoúčelový server se odstraní sedm dní po migraci.

Způsobilost

Pokud vlastníte úlohu s jedním serverem bez složitých funkcí (replika pro čtení, virtuální síť, dvojité šifrování infra, koncový bod služby nebo pravidla virtuální sítě), můžete se teď sami nominovat (pokud ještě není naplánovaná službou) k automatickému zmigrování odesláním podrobností o serveru prostřednictvím lístku podpory Azure.

Pokud chcete, aby byl váš oprávněný server způsobilý pro automatickou migraci, proveďte následující kroky:

• Instance jednoúčelového serveru by měla být v připraveném stavu a neměla by být v zastaveném stavu během časového období plánované údržby, aby bylo možné provést automatické migrace.
• Pokud váš zdrojový jednoúčelový server Azure Database for MySQL má verzi modulu v8.x, ujistěte se, že upgradujete verzi klientského ovladače .NET zdrojového serveru na verzi 8.0.32, abyste se vyhnuli nekompatibilitě kódování po migraci na flexibilní server.
• Pokud má váš zdrojový jednoúčelový server Azure Database for MySQL verzi modulu v8.x, ujistěte se, že upgradujete verzi TLS zdrojového serveru z verze 1.0 nebo v1.1 na TLS v1.2, protože starší verze TLS jsou pro flexibilní server zastaralé.
• Pokud má váš server repliky pro čtení, odstraňte repliky pro čtení. Repliky pro čtení můžete nakonfigurovat po automatické migraci.
• Pokud má váš server povolené koncové body služby (pravidla virtuální sítě) nebo konfiguraci virtuální sítě, zvažte jejich vyřazení nebo přesunutí do funkce Private Link na instanci jednoúčelového serveru.
• Pokud je pro váš server povolené dvojité šifrování infrastruktury, zvažte přechod na funkci klíč spravovaný zákazníkem (CMK) v instanci jednoúčelového serveru.

Konfigurace upozornění migrace

Servery, které mají nárok na místní automatické migrace, se službou odešlou předem oznámení.

Níže jsou popsány způsoby, jak zkontrolovat a nakonfigurovat oznámení automatického migrace:

• Vlastníci předplatného pro jednoúčelové servery naplánované pro automatické migrace dostanou e-mailové oznámení.
• Pomocí následujícího postupu nakonfigurujte upozornění služby Service Health tak, aby dostávala místní plán migrace a oznámení o průběhu prostřednictvím e-mailu nebo SMS.
• Podle těchto kroků si projděte místní oznámení o migraci na webu Azure Portal.

Kontrola a konfigurace plánu a podrobností migrace

Níže jsou popsány způsoby kontroly plánu migrace, jakmile obdržíte místní oznámení o automatickém migraci:

• Na stránce přehledu jednoúčelového serveru pro vaši instanci se zobrazí banner portálu s informacemi o plánu migrace.

• U jednoúčelových serverů naplánovaných pro automatické migrace se na portálu zobrazí nové okno Migrace. Plán migrace můžete zkontrolovat tak, že přejdete do okna Migrace instance jednoúčelového serveru.

• Pokud chcete migraci odložit, můžete migraci odložit o měsíc najednou tak, že přejdete do okna Migrace instance jednoho serveru na webu Azure Portal a znovu naplánujete migraci výběrem jiného okna migrace do jednoho měsíce.

• Pokud má jednoúčelový server skladovou položku pro obecné účely, máte při kontrole plánu migrace druhou možnost povolit vysokou dostupnost . Vzhledem k tomu, že vysokou dostupnost je možné povolit pouze během vytváření flexibilního serveru MySQL, důrazně doporučujeme tuto funkci povolit při kontrole plánu migrace.

• Pokud má vaše instance jednoúčelového serveru jednu nebo více služeb Private Link, klíč spravovaný zákazníkem (CMK) a správce Microsoft Entra, místní automatická migrace vyžaduje povinné vstupy pro migraci privátních koncových bodů, CMK a Microsoft Entra Admin z instance jednoúčelového serveru do cílové instance flexibilního serveru. Uživatelské vstupy musí být poskytnuty 2 dny před plánovaným oknem migrace. Pokud se před uzamčením podrobností migrace nezadají vstupy uživatelů, bude migrace znovu naplánována na pozdější bod v čase. Po zadání všech vstupů nezapomeňte konfiguraci uložit v průvodci automatickou migrací. Postup zadání uživatelského vstupu:

  • Přejděte do okna Migrace instance jednoúčelového serveru a vyberte upravit naplánovanou migraci.
  • V části Podrobnosti o automatické migraci klikněte na tlačítko Ověřit a ověřte a uložte připojení rozhraní ARM API pro migraci serveru.
  • Pokud je váš server nakonfigurovaný správcem Microsoft Entra, můžete zadat vstupy v části Správce Microsoft Entra v průvodci automatickou migrací:
    • Migrace správce Microsoft Entra pro cílový server vyžaduje přidání identity do flexibilního serveru Azure Database for MySQL. Identita vyžaduje následující oprávnění – Uživatel.Read.All, GroupMember.Read.All a Application.Read.All mají být udělena. Vyberte příslušnou spravovanou identitu přiřazenou uživatelem a podle následujících kroků udělte správná oprávnění.
  • Pokud má váš server nakonfigurovaný klíč spravovaný zákazníkem, můžete zadat vstupy v části Šifrování dat v průvodci automatickou migrací:
    • Migrace šifrování klíčů spravovaných zákazníkem vyžaduje přidání identity na flexibilní server Azure Database for MySQL. Vyberte příslušnou spravovanou identitu přiřazenou uživatelem. Uvedený identifikátor klíče nebo klíč by se migroval ze zdroje na cílový server a měl by mít udělená následující oprávnění – Získat, Zabalit klíč, Rozbalit klíč , aby bylo možné získat přístup k trezoru klíčů.
  • Pokud má jeden server privátní koncové body, proveďte při kontrole plánu migrace alespoň 2 dny před naplánovanou migrací následující povinné kroky:
    • Zkontrolujte privátní koncové body, které se mají migrovat. Ujistěte se, že jsou označené jako Připraveno k migraci. Pokud jsou označené jako způsobilé, vyberte příslušné předplatné a privátní zónu DNS.
      • Automatická migrace nepodporuje vlastní zónu Privátní DNS. Zóna Privátní DNS musí být privatelink.mysql.database.azure.com.
      • Metoda schválení připojení privátních koncových bodů by měla být nastavená jako automatická schválení, a ne jako ruční schválení. Automatická migrace nepodporuje privátní koncové body ručního schvalování.
    • Ujistěte se, že máte přístup k roli Přispěvatel na úrovni předplatného nebo skupiny prostředků, abyste se vyhnuli problémům s oprávněními při ověřování.
    • Po provedení uvedených kontrol požadavků pro migraci privátních koncových bodů zaškrtněte políčko potvrzení.

  Poznámka:

  Pokud povinné vstupy pro migraci nejsou k dispozici nejméně 2 dny před naplánovanou migrací, migrace se přeplánuje na pozdější datum.

  Poznámka:

  Pro instanci jednoúčelového serveru s privátními koncovými body odstraňte po ověření migrace zdrojovou instanci jednoúčelového serveru. Pokud se neprovádí žádná operace odstranění serveru, zdrojová instance se udržuje až do 14 dnů po jejím odstranění službou.

Kontroly předpokladů pro místní automatické migrace

Projděte si následující požadavky, abyste zajistili úspěšnou místní automatickou migraci:

• Instance jednoúčelového serveru by měla být v připraveném stavu a neměla by být v zastaveném stavu během časového období plánované údržby, aby bylo možné provést automatické migrace.
• Parametry serveru, nastavení, konfigurace a pravidla brány firewall instance jednoúčelového serveru by se neměly aktualizovat během dvoudenního intervalu před plánovaným automatickým migracem.
• Pro instanci s jedním serverem s povoleným protokolem SSL se ujistěte, že máte všechny tři certifikáty (BaltimoreCyberTrustRoot, DigiCertGlobalRootG2 Kořenová certifikační autorita a DigiCertGlobalRootCA) dostupné v důvěryhodném kořenovém úložišti. Navíc pokud máte certifikát připnutý k připojovací řetězec vytvořit kombinovaný certifikát certifikační autority se všemi třemi certifikáty před plánovaným automatickým migrací, abyste zajistili kontinuitu podnikových procesů po migraci.
• Modul MySQL nezaručuje žádné pořadí řazení, pokud v dotazech neexistuje žádná klauzule SORT. Po odeslání místního automatického migrace můžete sledovat změnu v pořadí řazení. Pokud je zachování pořadí řazení zásadní, ujistěte se, že se vaše dotazy aktualizují tak, aby zahrnovaly klauzuli SORT před naplánovanou místní automatickougrací.
• Pokud váš zdrojový jednoúčelový server Azure Database for MySQL má verzi modulu v8.x, ujistěte se, že upgradujete verzi klientského ovladače .NET zdrojového serveru na verzi 8.0.32, abyste se vyhnuli nekompatibilitě kódování po migraci na flexibilní server.
• Pokud má váš zdrojový jednoúčelový server Azure Database for MySQL verzi modulu v8.x, ujistěte se, že upgradujete verzi TLS zdrojového serveru z verze 1.0 nebo v1.1 na TLS v1.2, protože starší verze TLS jsou pro flexibilní server zastaralé.
• Pokud váš zdrojový jednoúčelový server Azure Database for MySQL obsahuje názvy pravidel brány firewall větší než 80 znaků, přejmenujte je, aby délka názvu byla menší než 80 znaků. (Délka názvu pravidla brány firewall podporovaná na flexibilním serveru je 80 znaků, zatímco na jednoúčelovém serveru je povolená délka 12 8 znaků.)
• Pokud váš zdrojový jednoúčelový server Azure Database for MySQL využívá nedefaultní porty, jako jsou například 3308 3309 a 3310, změňte port připojení na 3306, protože výše uvedené nedefault porty nejsou na flexibilním serveru podporované.

Jak je cílový flexibilní server MySQL automaticky zřízený?

Úroveň výpočetních prostředků a skladová položka cílového flexibilního serveru se zřídí na základě cenové úrovně zdrojového jednoúčelového serveru a virtuálních jader na základě podrobností v následující tabulce.

• Verze, oblast, *velikost úložiště, předplatné a skupina prostředků cílového flexibilního serveru je stejná jako u zdrojového jednoúčelového serveru.
• U jednoúčelových serverů s úložištěm nižším než 20 GiB je velikost úložiště nastavená na 20 GiB, protože se jedná o minimální limit úložiště na flexibilním serveru Azure Database for MySQL.
• Oba formáty uživatelského jména – username@server_name (jednoúčelový server) i uživatelské jméno (flexibilní server) se podporují na migrovaném flexibilním serveru.
• Oba formáty připojovací řetězec – jednoúčelový i flexibilní server se podporují na migrovaném flexibilním serveru.
• U instance jednoúčelového serveru s povoleným úložištěm dotazů je parametr serveru slow_query_log v cílové instanci nastavený na HODNOTU ON, aby se zajistila parita funkcí při migraci na flexibilní server. U některých úloh to může mít vliv na výkon a pokud zaznamenáte snížení výkonu, nastavte tento parametr serveru na hodnotu OFF v instanci flexibilního serveru.

Kroky po migraci

Tady jsou informace, které potřebujete znát po místní migraci:

• Zkopírujte následující vlastnosti ze zdrojového jednoúčelového serveru do cílového flexibilního serveru po dokončení místní operace migrace:
  • Nastavení stránky monitorování (upozornění, metriky a nastavení diagnostiky) a nastavení zámků
  • Všechny skripty Terraformu nebo rozhraní příkazového řádku, které hostujete pro správu instance jednoúčelového serveru, by se měly aktualizovat odkazy na flexibilní server.
• U instance jednoúčelového serveru s povoleným úložištěm dotazů je parametr serveru slow_query_log v cílové instanci nastavený na HODNOTU ON, aby se zajistila parita funkcí při migraci na flexibilní server. Upozorňujeme, že u některých úloh to může mít vliv na výkon a pokud zaznamenáte snížení výkonu, nastavte tento parametr serveru na hodnotu OFF v instanci flexibilního serveru.
• Pro instanci jednoúčelového serveru s privátními koncovými body odstraňte po ověření migrace zdrojovou instanci jednoúčelového serveru. Pokud se neprovádí žádná operace odstranění serveru, zdrojová instance se udržuje až do 14 dnů po jejím odstranění službou.
• Pro instanci s jedním serverem s povoleným Programem Microsoft Defender pro cloud se migruje stav povolení. Pokud chcete dosáhnout parity na flexibilním serveru po automatickém migrace vlastností, které můžete nakonfigurovat na jednoúčelovém serveru, zvažte podrobnosti v následující tabulce:

Nejčastější dotazy (FAQ)

Otázka: Proč se migruje automaticky?

A. Vaše instance Azure Database for MySQL – Jednoúčelový server má nárok na místní migraci na naši vlajkovou nabídku Azure Database for MySQL – flexibilní server. Tato migrace na místě odstraní režijní náklady na ruční migraci serveru a zajistí, že budete moci využívat výhody flexibilního serveru, včetně lepší ceny & výkonu, granulární kontroly nad konfigurací databáze a vlastních oken údržby.

Otázka: Jak probíhá automatická migrace? Co všechno migruje?

A. Flexibilní server je nastaven tak, aby odpovídal virtuálním jádrům a úložišti jako váš jednoúčelový server. Poté se zdrojový jednoúčelový server uvede do zastaveného stavu, pořídí se snímek datového souboru a zkopíruje se na cílový flexibilní server. Přepnutím DNS se všechna stávající připojení přesměrují na cíl a cílový flexibilní server je uveden do režimu online. Automatická migrace migruje kromě parametrů serveru i datové soubory celého serveru (včetně schématu, dat, přihlášení) (všechny upravené parametry serveru ve zdroji se zkopírují do cíle, neupravené parametry serveru zabírají výchozí hodnotu definovanou flexibilním serverem) a pravidla brány firewall. Jedná se o offline migraci, při které vidíte výpadek až 5 minut nebo méně.

Otázka: Jak můžu nastavit nebo zobrazit místní upozornění na migraci?

A. Upozornění můžete nastavit takto:

• Pomocí následujícího postupu nakonfigurujte upozornění služby Service Health tak, aby dostávala místní plán migrace a oznámení o průběhu prostřednictvím e-mailu nebo SMS.
• Podle těchto kroků si projděte místní oznámení o migraci na webu Azure Portal.

Otázka: Jak můžu plánovanou migraci odložit?

A. Plán migrace můžete zkontrolovat tak, že přejdete do okna Migrace instance jednoúčelového serveru. Pokud chcete migraci odložit, můžete migraci odložit maximálně o měsíc tak, že přejdete do okna Migrace instance jednoho serveru na webu Azure Portal a znovu naplánujete migraci výběrem jiného okna migrace do jednoho měsíce. Podrobnosti o migraci jsou uzamčeny sedm dní před naplánovaným oknem migrace, po kterém nemůžete přeplánovat. Tuto místní migraci je možné odložit měsíčně do 16. září 2024.

Otázka: Jaké uživatelské jméno a připojovací řetězec budou podporovány pro migrovaný flexibilní server? ​​

A. Oba formáty uživatelského jména – username@server_name (formát jednoúčelového serveru) a uživatelské jméno (formát flexibilního serveru) jsou podporované pro migrovaný flexibilní server, a proto je nemusíte aktualizovat, aby se zachovala kontinuita aplikací po migraci. Migrovaný flexibilní server podporuje také formáty připojovací řetězec (formát jednoúčelového i flexibilního serveru).

Otázka: Jak povolit vysokou dostupnost (vysoká dostupnost) pro můj automaticky migrovaný server??

A. Ve výchozím nastavení automatická migrace nastaví migraci na instanci bez vysoké dostupnosti. Vzhledem k tomu, že vysokou dostupnost je možné povolit pouze při vytváření serveru, měli byste vysokou dostupnost povolit před plánovanou automatickou migrací pomocí možnosti úpravy plánu automatické migrace na portálu. Vysokou dostupnost je možné povolit pouze pro skladové položky pro obecné účely\Skladové položky optimalizované pro paměť na cílovém flexibilním serveru, protože migrace skladové položky basic-to Burstable nepodporuje konfiguraci vysoké dostupnosti.

Otázka: Na flexibilním serveru MySQL Basic se mi zobrazuje cenový rozdíl?

A. Několik serverů může po migraci vidět malý nárůst ceny (odhadované náklady se dají zobrazit výběrem možnosti pro úpravy plánu automatické migrace na portálu), protože minimální limit úložiště obou nabídek se liší (5 GiB na jednoúčelovém serveru, 20 GiB na flexibilním serveru) a náklady na úložiště (0,1$ na jednoúčelovém serveru; 0,115$ na flexibilním serveru) pro flexibilní server je mírně vyšší než jeden server. U ovlivněných serverů poskytuje toto zvýšení ceny flexibilního serveru lepší propustnost a výkon v porovnání s jedním serverem.

Související obsah

• Správa flexibilního serveru Azure Database for MySQL pomocí webu Azure Portal