MySQL–Azure Database for MySQL-adatmigrálás – MySQL-konzisztens pillanatkép
A MySQL Konzisztens pillanatkép egy új funkció, amely lehetővé teszi a felhasználók számára, hogy konzisztens pillanatképet készítsenek a MySQL-kiszolgálóról anélkül, hogy a folyamatos CRUD-műveletek (létrehozás, olvasás, frissítés és törlés) miatt elveszne az adatintegritás a forrásnál. A tranzakciós konzisztencia anélkül érhető el, hogy a forráskiszolgálót írásvédett módra kellene állítania ezzel a funkcióval. Emellett több adatkonzisztencia-beállítás is elérhető a felhasználó számára : konzisztens pillanatkép engedélyezése olvasási zárolással (GA), konzisztens pillanatkép engedélyezése zárolások nélkül (előzetes verzió), Forráskiszolgáló írásvédetté tétele és Nincs. A "Nincs" lehetőség kiválasztása nem jár további intézkedésekkel az adatkonzisztenciának biztosítása érdekében. Javasoljuk, hogy válassza a "Konzisztens pillanatkép engedélyezése zárolások nélkül" lehetőséget a tranzakciós konzisztencia fenntartása érdekében.
Konzisztens pillanatkép engedélyezése zárolások nélkül (előzetes verzió)
Ha engedélyezi ezt a beállítást, a kezdeti betöltés után egyeztetési fázis következik be. Ennek célja, hogy a célnak írt adatok tranzakciós szempontból konzisztensek legyenek a forráskiszolgálóval a bináris napló egy adott pozíciójából.
Ezzel a funkcióval nem zárunk le olvasási zárolást a kiszolgálón. Ehelyett táblázatokat olvasunk különböző időpontokban, miközben nyomon követjük az egyes táblák különböző binlog pozícióit. Ez segít összeegyeztetni a táblákat a kezdeti terhelés vége felé a replikáció felzárkózási módban történő végrehajtásával, hogy konzisztens pillanatképet kapjon.
A konzisztens pillanatkép kulcsfunkciói zárolás nélkül:
- A nagy számítási feladatok kiszolgálóinak vagy kiszolgálóinak támogatása hosszú ideig futó tranzakciók esetén olvasási zárolások nélkül.
- A migrálások elvégzése akkor is rugalmas, ha átmeneti hálózati/kiszolgálói három pontra van szükség, ami az összes előre létrehozott kapcsolat elvesztését eredményezi.
Konzisztens pillanatkép engedélyezése olvasási zárolással (GA)
Ha engedélyezi ezt a beállítást, a szolgáltatás olvasási zárral kiüríti a forráskiszolgáló összes tábláját az időponthoz kötött pillanatkép beszerzéséhez. Ez a kiürítés azért történik, mert a globális zárolás megbízhatóbb, mint az egyes adatbázisok vagy táblák zárolásának megkísérlése. Ennek eredményeképpen még ha nem is migrálja az összes adatbázist egy kiszolgálón, azok a migrálási folyamat beállításának részeként zárolva vannak. A migrálási szolgáltatás ismétlődő olvasást kezdeményez, és egyesíti az aktuális táblaállapotot a pillanatkép visszavonási naplójának tartalmával. A pillanatkép a kiszolgálószintű zárolás beszerzése és a migráláshoz szükséges több kapcsolat létrehozása után jön létre. Az áttelepítéshez használt összes kapcsolat létrehozása után a rendszer feloldja a táblán lévő zárolásokat.
Az ismétlődő olvasások lehetővé teszik a visszavonási naplók akadálymentesítését a migrálás során, ami növeli a forráson a hosszú ideig futó kapcsolatok miatt szükséges tárterületet. A több táblamódosítással rendelkező, hosszú ideig futó migrálás kiterjedt visszavonási naplóelőzményeket eredményez, amelyeket újra kell játszani, és növelheti a számítási követelményeket és a forráskiszolgáló terhelését.
A forráskiszolgáló írásvédetté tétele
Ha ezt a beállítást választja, a forrás áttelepítése során a céladatbázis adatintegritása megmarad azzal, hogy megakadályozza a forráskiszolgáló írási/törlési műveleteit a migrálás során. Ha a forráskiszolgálót csak az áttelepítési folyamat részeként olvassa be, a kijelölés a forráskiszolgáló összes adatbázisára vonatkozik, függetlenül attól, hogy az áttelepítéshez vannak-e kiválasztva.
A forráskiszolgáló írásvédetté tétele megakadályozza, hogy a felhasználók módosítsák az adatokat, így az adatbázis nem érhető el a frissítési műveletekhez. Ha azonban ez a beállítás nincs engedélyezve, az áttelepítés során adatfrissítések is előfordulhatnak. Ennek eredményeképpen a migrált adatok inkonzisztensek lehetnek, mert az adatbázis pillanatképei különböző időpontokban lesznek beolvasva.
A konzisztens pillanatkép olvasási zárolással való engedélyezésének előfeltételei
A migrálás sikeres befejezéséhez konzisztens pillanatkép és engedélyezett olvasási zárolás:
Győződjön meg arról, hogy a táblákat olvasási zárolással öblíteni próbáló felhasználó rendelkezik RELOAD vagy FLUSH engedéllyel.
A mysql-ügyféleszköz használatával állapítsa meg, hogy engedélyezve van-e log_bin a forráskiszolgálón. A bin napló alapértelmezés szerint nincs bekapcsolva, és ellenőrizni kell, hogy engedélyezve van-e az áttelepítés megkezdése előtt. A mysql-ügyféleszköz a következő parancs futtatásával állapítja meg, hogy a log_bin engedélyezve van-e a forráson: VÁLTOZÓK MEGJELENÍTÉSE, PÉLDÁUL "log_bin";
Feljegyzés
A legfeljebb 4 TB-t támogató önálló Azure Database for MySQL-kiszolgáló esetében ez alapértelmezés szerint nem engedélyezett. Ha azonban előléptet egy olvasási replikát a forráskiszolgálóhoz, majd törli az olvasási replikát, a paraméter BE értékre van állítva.
- Konfigurálja a binlog_expire_logs_seconds paramétert a forráskiszolgálón, hogy a binlogfájlok ne törlődjenek, mielőtt a replika véglegesíti a módosításokat. A sikeres átállás után az érték alaphelyzetbe állítható.
Ismert problémák és korlátozások a konzisztens pillanatkép zárolások nélküli engedélyezéséhez
- A Cascade vagy a Set Null beállítással rendelkező külső kulcsokat tartalmazó táblák nem támogatottak a törlési/frissítési záradékon.
- A kezdeti betöltés során nem szabad DDL-módosításokat végrehajtani.
Ismert problémák és korlátozások a konzisztens pillanatkép olvasási zárolással való engedélyezéséhez
A konzisztens biztonsági mentéssel kapcsolatos ismert problémák és korlátozások nagyjából két kategóriába sorolhatók: zárolások és újrapróbálkozások.
Feljegyzés
A migrálási szolgáltatás a START TRANSACTION WITH CONSISTENT SNAPSHOT lekérdezést futtatja az összes feldolgozó szálhoz a kiszolgáló pillanatképének lekéréséhez. Ezt azonban csak az InnoDB támogatja. További információ itt.
Zárolások
Általában ez egy egyszerű folyamat a zárolás beszerzéséhez, amelynek néhány másodperc és néhány perc közötti időt kell igénybe vennie. Néhány esetben azonban a forráskiszolgáló zárolásának lekérésére tett kísérletek sikertelenek lehetnek.
A hosszú ideig futó lekérdezések jelenléte szükségtelen állásidőt eredményezhet, mivel a DMS zárolhatja a táblák egy részét, majd időtúllépést okozhat, amíg az utolsó néhány elérhetővé válik. Az áttelepítés megkezdése előtt ellenőrizze, hogy vannak-e hosszú ideig futó műveletek a SHOW PROCESSLIST parancs futtatásával.
Ha a forráskiszolgáló számos írási frissítést tapasztal a zárolás kérésének időpontjában, a zárolás nem kérhető le könnyen, és a zárolási várakozás időtúllépése után meghiúsulhat. Ez akkor fordul elő, ha a tábla kötegelt feldolgozási feladatait hajtja végre, ami a zárolási kérelem elutasítását eredményezheti, ha folyamatban van. Ahogy korábban említettük, a kért zárolás egyetlen globális szintű zárolás a teljes kiszolgáló számára, így még ha egyetlen tábla vagy adatbázis is feldolgozás alatt áll, a zárolási kérésnek várnia kell a folyamatban lévő feladat befejezésére.
Egy másik korlátozás az AWS RDS-forráskiszolgálóról való migrálásra vonatkozik. Az RDS nem támogatja az olvasási zárolással rendelkező táblák kiürítését, és a LOCK TABLE lekérdezés a kiválasztott táblákon fut a motorháztető alatt. Mivel a táblák külön-külön vannak zárolva, a zárolási folyamat kevésbé megbízható, és a zárolások beszerzése hosszabb időt vehet igénybe.
Újrapróbálkozások
A migrálás kezeli az átmeneti csatlakozási problémákat, és a további kapcsolatok általában előre vannak kiépítve erre a célra. Áttekintjük a migrálási beállításokat, különösen a forrás párhuzamos olvasási műveleteinek számát, és alkalmazunk egy tényezőt (általában ~1,5), és annyi kapcsolatot hozunk létre elölről. Így a szolgáltatás gondoskodik arról, hogy a műveletek párhuzamosan fussanak. Ha bármikor megszakad a kapcsolat, vagy a szolgáltatás nem tud zárolást szerezni, a szolgáltatás a kiosztott többletkapcsolatokat használja az áttelepítés újrapróbálkozásához. Ha az összes kiépített kapcsolat kimerült, ami az időponthoz kötött szinkronizálás elvesztését eredményezi, az áttelepítést az elejétől újra kell indítani. Sikeres és sikertelen esetekben az offline migrálási szolgáltatás minden tisztítási műveletet végrehajt, és a felhasználónak nem kell explicit törlési műveleteket végrehajtania.