Migrace dat MySQL do Služby Azure Database for MySQL – Konzistentní snímek MySQL
MySQL Consistent Snapshot je nová funkce, která uživatelům umožňuje pořizovat konzistentní snímek serveru MySQL bez ztráty integrity dat ve zdroji kvůli probíhajícím operacím CRUD (vytvoření, čtení, aktualizace a odstranění). Transakční konzistence se dosahuje bez nutnosti nastavit zdrojový server na režim jen pro čtení prostřednictvím této funkce. Kromě toho se uživateli zobrazuje více možností konzistence dat – umožňuje konzistentní snímek se zámkem čtení (GA), povolit konzistentní snímek bez zámků (Preview), Nastavit zdrojový server jen pro čtení a Žádný. Pokud vyberete možnost None (Žádná), nebudou přijata žádná další opatření, aby byla zajištěna konzistence dat. Obě možnosti – povolení konzistentního snímku se zámkem čtení (GA), povolení konzistentního snímku bez zámků podporuje provádění online migrace. Důrazně doporučujeme vybrat možnost Povolit konzistentní snímek bez zámků, abyste zachovali konzistenci transakcí.
Povolení konzistentního snímku bez zámků (Preview)
Když tuto možnost povolíte, fáze odsouhlasení proběhne po počátečním načtení. Tím zajistíte, aby data zapsaná do vašeho cíle byla transakční konzistentně se zdrojovým serverem z konkrétní pozice v binárním protokolu.
Díky této funkci nezachytáme zámek čtení na serveru. Místo toho čteme tabulky v jiném časovém okamžiku a přitom sledujeme různé pozice binlogu jednotlivých tabulek. To pomáhá sladit tabulky směrem ke konci počátečního zatížení provedením replikace v režimu catchup, aby se získal konzistentní snímek.
Klíčové funkce konzistentního snímku bez zámků:
- Schopnost podporovat servery nebo servery s velkým zatížením s dlouhotrvajícími transakcemi bez nutnosti zámků čtení.
- Odolné při dokončování migrací i v případě selhání způsobených přechodnými tečkami sítě nebo serveru, které vedou ke ztrátě všech předem vytvořených připojení.
Povolení konzistentního snímku se zámkem čtení (GA)
Když tuto možnost povolíte, služba vyprázdní všechny tabulky na zdrojovém serveru zámkem pro čtení , aby získala snímek k určitému bodu v čase. Toto vyprázdnění se provádí, protože globální zámek je spolehlivější než pokus o uzamčení jednotlivých databází nebo tabulek. To znamená, že i když nemigrujete všechny databáze na serveru, jsou v rámci nastavení procesu migrace zamknuté. Služba migrace zahájí opakovatelný čtení a kombinuje aktuální stav tabulky s obsahem protokolu vrácení zpět pro snímek. Snímek se vygeneruje po získání širokého zámku serveru po dobu několika sekund a vytvoření několika připojení pro migraci. Po vytvoření všech připojení používaných k migraci se uvolní zámky v tabulce.
Opakovatelné čtení umožňují zachovat protokoly zpět přístupné během migrace, což zvyšuje úložiště požadované ve zdroji kvůli dlouhotrvajícím připojením. Dlouhotrvající migrace s několika změnami tabulek vede k rozsáhlé historii protokolů vrácení zpět, kterou je potřeba přehrát, a může také zvýšit požadavky na výpočetní prostředky a načíst na zdrojový server.
Nastavení zdrojového serveru jen pro čtení
Výběrem této možnosti zachováte integritu dat cílové databáze při migraci zdroje tím, že během migrace zabráníte operacím zápisu nebo odstranění na zdrojovém serveru. Když zdrojový server nastavíte jako součást procesu migrace jen pro čtení, výběr se vztahuje na všechny databáze zdrojového serveru bez ohledu na to, jestli jsou vybrané pro migraci.
Nastavení zdrojového serveru jen pro čtení zabrání uživatelům v úpravách dat a vykreslení databáze není k dispozici pro všechny operace aktualizace. Pokud ale tato možnost není povolená, může během migrace dojít k aktualizacím dat. V důsledku toho by migrovaná data mohla být nekonzistentní, protože snímky databáze by se načítaly v různých bodech v čase.
Předpoklady pro povolení konzistentního snímku se zámkem čtení
Úspěšné dokončení migrace pomocí konzistentního snímku s povoleným zámkem čtení:
Ujistěte se, že uživatel, který se pokouší vyprázdnit tabulky pomocí zámku pro čtení, má oprávnění RELOAD nebo FLUSH.
Pomocí klientského nástroje mysql určete, jestli je na zdrojovém serveru povolená log_bin. Protokol přihrádek není ve výchozím nastavení vždycky zapnutý a před zahájením migrace by se měl zkontrolovat, jestli je povolený. Klientský nástroj mysql slouží k určení, jestli je ve zdroji povolená log_bin spuštěním příkazu: SHOW VARIABLES LIKE 'log_bin';
Poznámka:
U jednoúčelového serveru Azure Database for MySQL, který podporuje až 4 TB, není tato možnost ve výchozím nastavení povolená. Pokud ale zvýšíte úroveň repliky pro čtení zdrojového serveru a pak odstraníte repliku pro čtení, parametr je nastavený na ZAPNUTO.
- Nakonfigurujte parametr binlog_expire_logs_seconds na zdrojovém serveru, aby se zajistilo, že soubory binlogu nebudou před potvrzením změn vyprázdněny. Po úspěšném přímé najetí je možné hodnotu resetovat.
Známé problémy a omezení povolení konzistentního snímku bez zámků
- Tabulky s cizími klíči, které mají kaskádovou nebo nastavenou hodnotu Null pro klauzuli delete/on update, se nepodporují.
- Během počátečního načtení by neměly nastat žádné změny DDL.
Známé problémy a omezení povolení konzistentního snímku se zámkem čtení
Známé problémy a omezení související s konzistentním zálohováním spadají do dvou kategorií: zámky a opakování.
Poznámka:
Služba migrace spustí dotaz START TRANSACTION WITH CONSISTENT SNAPSHOT pro všechna pracovní vlákna pro získání snímku serveru. To ale podporuje jenom InnoDB. Další informace najdete tady.
Zámky
Obvykle se jedná o jednoduchý proces získání zámku, který by měl trvat několik sekund až několik minut. V několika scénářích ale může dojít k selhání pokusů o získání zámku na zdrojovém serveru.
Přítomnost dlouhotrvajících dotazů může vést k zbytečným výpadkům, protože DMS může uzamknout podmnožinu tabulek a pak časový limit vyprší, než bude několik posledních dostupných. Před zahájením migrace zkontrolujte všechny dlouhotrvající operace spuštěním příkazu SHOW PROCESSLIST .
Pokud u zdrojového serveru dochází v době vyžádání zámku k mnoha aktualizacím zápisu, zámek se nedá snadno získat a po vypršení časového limitu čekání na uzamčení může selhat. K tomu dochází v případě úloh dávkového zpracování v tabulkách, které v průběhu můžou vést k odepření požadavku na zámek. Jak už bylo zmíněno dříve, požadovaný zámek je jeden globální zámek pro celý server, takže i když se zpracovává jedna tabulka nebo databáze, požadavek na uzamčení bude muset počkat na dokončení probíhající úlohy.
Další omezení souvisí s migrací ze zdrojového serveru AWS RDS. RdS nepodporuje vyprázdnění tabulek se zámkem čtení a dotaz LOCK TABLE se spouští na vybraných tabulkách pod kapotou. Vzhledem k tomu, že jsou tabulky uzamčené jednotlivě, proces uzamykání může být méně spolehlivý a získání zámků může trvat déle.
Opakování
Migrace zpracovává přechodné problémy s připojením a další připojení se pro tento účel obvykle zřizují předem. Podíváme se na nastavení migrace, zejména na počet paralelních operací čtení ve zdroji, a použijeme faktor (obvykle ~1,5) a vytvoříme tolik připojení předem. Služba tak zajistí, že můžeme operace běžet paralelně. Pokud dojde ke ztrátě připojení nebo služba nemůže získat zámek, služba použije nadbytečná připojení zřízená k opakování migrace. Pokud jsou všechna zřízená připojení vyčerpána, dojde ke ztrátě synchronizace k určitému bodu v čase, je potřeba migraci restartovat od začátku. V případě úspěchu i selhání provádí tato služba offline migrace všechny akce čištění a uživatel nemusí provádět žádné explicitní akce čištění.