MySQL–Azure Database for MySQL-adatmigrálás – MySQL-módosítások replikálása
Replikálási módosítások migrálása a "Tranzakciós konzisztencia engedélyezése" offline forgatókönyvünkkel lehetővé teszi, hogy a vállalatok migrálhassák adatbázisaikat az Azure-ba, miközben az adatbázisok továbbra is működőképesek maradnak. Más szóval a migrálás a kritikus alkalmazások minimális állásidejével is elvégezhető, ami korlátozza a szolgáltatásszint rendelkezésre állására és a végfelhasználókra gyakorolt kényelmetlenséget.
Megjegyzés:
This article contains references to the term slave, a term that Microsoft no longer uses. When the term is removed from the software, we’ll remove it from this article.
Jelenlegi implementáció
A "Tranzakciós konzisztencia engedélyezése" lehetőséggel offline áttelepítési forgatókönyvet kell futtatnia a bin naplófájl lekéréséhez és a bejövő módosítások replikálásához szükséges pozícióhoz. A DMS portál felhasználói felülete a bináris naplófájl nevét és pozícióját jeleníti meg a zárolások forráson való beszerzésének időpontjához igazítva a konzisztens pillanatképhez. Ezt az értéket a replikált módosítások migrálásában használhatja a bejövő módosítások streameléséhez.
A replikálási módosítások migrálása közben, amikor a cél majdnem felzárkózott a forráskiszolgálóhoz, állítsa le a forrásadatbázisba érkező összes bejövő tranzakciót, és várja meg, amíg az összes függőben lévő tranzakciót alkalmazza a céladatbázisra. Annak ellenőrzéséhez, hogy a céladatbázis naprakész-e a forráskiszolgálón, futtassa a "MASTER ÁLLAPOT MEGJELENÍTÉSE;" lekérdezést, majd hasonlítsa össze ezt a pozíciót az utolsó véglegesített binlogeseményrel (amely a migrálási folyamat alatt jelenik meg). Ha a két pozíció megegyezik, a cél elérte az összes változást, és megkezdheti az átállást.
A módosítások replikálása
A jelenlegi implementáció a forráskiszolgálóról származó streamelési binlog-módosításokon alapul, és alkalmazza őket a célkiszolgálóra. A data-in replikációhoz hasonlóan ez is egyszerűbben beállítható, és nem igényel fizikai kapcsolatot a forrás és a célkiszolgálók között.
A kiszolgáló bináris adatokat tartalmazó streamként küldhet binlogot az itt dokumentált módon. Az ügyfél megadhatja a kezdeti naplópozíciót, amellyel elindíthatja a streamet. A naplófájl neve leírja a naplófájl pozícióját, a fájlon belüli pozíciót, és opcionálisan a GTID -t (globális tranzakcióazonosítót), ha a gtid mód engedélyezve van a forrásnál.
Az adatváltozások "sor" eseményként lesznek elküldve, amelyek az egyes sorok adatait tartalmazzák (a módosítás előtt és/vagy után a művelet típusától függően, amelyet beszúrnak, törölnek vagy frissítenek). A soresemények ezután nyers formátumban lesznek alkalmazva egy BINLOG utasítással: MySQL 8.0 Referencia-kézikönyv :: 13.7.8.1 BINLOG utasítás. Az 5.7-kiszolgálóra történő DMS-migrálás esetén azonban a DMS nem alkalmazza a módosításokat BINLOG-utasításokként (mivel a DMS nem rendelkezik ehhez szükséges jogosultságokkal), hanem in Standard kiadás RT, UPDATE vagy DELETE utasításokra fordítja le a soreseményeket.
Előfeltételek
A replikált módosítások migrálásának sikeres befejezéséhez győződjön meg arról, hogy a következő előfeltételek teljesülnek:
- A választott MySQL parancssori eszközzel állapítsa meg, hogy a log_bin engedélyezve van-e a forráskiszolgálón. A binlog alapértelmezés szerint nincs bekapcsolva, ezért az áttelepítés megkezdése előtt ellenőrizze, hogy engedélyezve van-e. Annak megállapításához, hogy a log_bin engedélyezve van-e a forráskiszolgálón, futtassa a következő parancsot: VÁLTOZÓK MEGJELENÍTÉSE, PÉLDÁUL "log_bin"
- Győződjön meg arról, hogy a felhasználó rendelkezik "REPLICATION_APPLIER" vagy "BINLOG_ADMIN" engedéllyel a célkiszolgálón a tárolónapló alkalmazásához.
- Győződjön meg arról, hogy a felhasználó rendelkezik "REPLIKÁCIÓS RABSZOLGA" engedéllyel a célkiszolgálón.
- Győződjön meg arról, hogy a felhasználó rendelkezik "REPLIKÁCIÓS ÜGYFÉL" és "REPLIKÁCIÓS RABSZOLGA" engedéllyel a forráskiszolgálón a tárolónapló olvasásához és alkalmazásához.
- Futtasson offline migrálási forgatókönyvet a "Tranzakciós konzisztencia engedélyezése" funkcióval a tároló naplófájljának és pozíciójának lekéréséhez.
- Ha replikálási módosítások áttelepítését célozza, 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 kezdéshez legalább két napot javasoljuk. A sikeres átállás után az érték alaphelyzetbe állítható.
Limitations
- Replikált módosítások áttelepítésekor a célkiszolgálón lévő adatbázis nevének meg kell egyeznie a forráskiszolgáló nevével.
- A támogatás a SOR binlog formátumra korlátozódik.
- A DDL-módosítások replikációja csak akkor támogatott, ha rugalmas Azure Database for MySQL-kiszolgálói célkiszolgálóra migrál egy 8.0-s verziós Azure Database for MySQL-célkiszolgálóra, és ha kiválasztotta a kiválasztott objektumok adatdefinícióinak és felügyeleti utasításainak replikálása lehetőséget a DMS felhasználói felületén. A replikációs funkció támogatja az adatdefiníciók és felügyeleti utasítások replikálását, amelyek a kezdeti betöltés után következnek be, és a bináris naplóban vannak naplózva a célhoz.
- Az adatbázisok vagy táblák átnevezése nem támogatott a módosítások replikálásakor.