Azure Database for MySQL migrálása – Önálló kiszolgáló az Azure Database for MySQL-be – Rugalmas kiszolgáló nyílt forráskódú eszközökkel
Az Azure Database for MySQL egy példányát – önálló kiszolgálót az Azure Database for MySQL-be – rugalmas kiszolgálót minimális állásidővel migrálhatja az alkalmazásokba nyílt forráskódú eszközök, például a mydumper/myloader és a data-in replikáció kombinációjával.
Feljegyzés
Ebben a cikkben szerepel a slave (alárendelt) kifejezés, amelyet a Microsoft már nem használ. Ha a kifejezés el lesz távolítva a szoftverből, eltávolítjuk ebből a cikkből.
A data-in replikáció egy olyan technika, amely a bináris naplófájlok helymeghatározási módszere alapján replikálja a forráskiszolgálóról a célkiszolgálóra az adatváltozásokat. Ebben a forgatókönyvben a forrásként működő MySQL-példány (amelyről az adatbázis módosul) a frissítéseket és a módosításokat "eseményekként" írja a bináris naplóba. A bináris napló információi a rögzített adatbázis-módosításoknak megfelelően különböző naplózási formátumokban lesznek tárolva. A replikák úgy vannak konfigurálva, hogy beolvassák a bináris naplót a forrásból, és végrehajtsák az eseményeket a bináris bejelentkezésben a replika helyi adatbázisában.
Ha úgy állítja be a data-in replikációt, hogy az adatokat az Azure Database for MySQL egyik példányáról a másikra szinkronizálja, akkor az elsődleges (vagy forrásadatbázis) alkalmazásainak szelektív átállását végezheti el a replikára (vagy a céladatbázisra).
Ebben az oktatóanyagban a mydumper/myloader és a data-in replikáció használatával migrál egy mintaadatbázist (klasszikusmodelleket) az Azure Database for MySQL egy példányából – önálló kiszolgálóról egy rugalmas Azure Database for MySQL-kiszolgálóra, majd szinkronizálja az adatokat.
Ebben az oktatóanyagban az alábbiakkal fog megismerkedni:
- Konfigurálja a hálózati beállításokat az adat-in replikációhoz különböző forgatókönyvekhez.
- Konfigurálja az elsődleges és a replika közötti adatreplikálást.
- A replikáció tesztelése.
- Átállás a migrálás befejezéséhez.
Előfeltételek
Az oktatóanyag elvégzéséhez a következőkre lesz szüksége:
Az Önálló Azure Database for MySQL-kiszolgáló 5.7-es vagy 8.0-s verzióját futtató példány.
Feljegyzés
Ha az Önálló Azure Database for MySQL 5.6-os verzióját futtatja, frissítse a példányt az 5.7-es verzióra, majd konfigurálja az adatokat a replikációban. További információ: Főverzió-frissítés az Önálló Azure Database for MySQL-kiszolgálón.
A rugalmas Azure Database for MySQL-kiszolgáló egy példánya. További információ: Példány létrehozása rugalmas Azure Database for MySQL-kiszolgálón.
Feljegyzés
A zónaredundáns magas rendelkezésre állású kiszolgálók adatreplikációs konfigurálása nem támogatott. Ha zónaredundáns HA-t szeretne a célkiszolgálóhoz, hajtsa végre az alábbi lépéseket:
- A kiszolgáló létrehozása zónaredundáns ha engedélyezve
- A HA letiltása
- Kövesse a cikket az adatok replikációjának beállításához
- Az átállás után távolítsa el a data-in replikációs konfigurációt
- A HA engedélyezése
Győződjön meg arról, hogy GTID_Mode ugyanazzal a beállítással rendelkezik a forrás- és célkiszolgálókon.
Adatbázis csatlakoztatása és létrehozása a MySQL Workbench használatával. További információ: A MySQL Workbench használata az adatok csatlakoztatásához és lekérdezéséhez.
Annak biztosítása érdekében, hogy linuxos Azure-beli virtuális gépe legyen ugyanazon a régióban (vagy ugyanazon a virtuális hálózaton, privát hozzáféréssel), amely a forrás- és céladatbázisokat üzemelteti.
A mysql-ügyfél vagy a MySQL Workbench (az ügyféleszközök) telepítése az Azure-beli virtuális gépre. Győződjön meg arról, hogy az elsődleges és a replikakiszolgálóhoz is csatlakozhat. A cikk alkalmazásában a mysql-ügyfél telepítve van.
A mydumper/myloader telepítése az Azure-beli virtuális gépen. További információ: mydumper/myloader.
A klasszikusmodell-adatbázis mintaadatbázis-szkriptjének letöltése és futtatása a forráskiszolgálón.
Konfigurálja binlog_expire_logs_seconds a forráskiszolgálón, hogy a bináris naplók ne törlődjenek, mielőtt a replika véglegesíti a módosításokat. A sikeres átvágás után alaphelyzetbe állíthatja az értéket.
Hálózati követelmények konfigurálása
A data-in replikáció konfigurálásához meg kell győződnie arról, hogy a cél csatlakozni tud a forráshoz a 3306-os porton keresztül. A forráson beállított végpont típusától függően hajtsa végre a megfelelő lépéseket.
- Ha egy nyilvános végpont engedélyezve van a forráson, akkor a tűzfalszabályban az "Azure-szolgáltatásokhoz való hozzáférés engedélyezése" engedélyezésével győződjön meg arról, hogy a cél csatlakozni tud a forráshoz. További információ: Tűzfalszabályok – Azure Database for MySQL.
- Ha a forráson engedélyezve van egy privát végpont és a nyilvános hozzáférés megtagadása, telepítse a privát hivatkozást ugyanabban a virtuális hálózatban, amely a célhelyet üzemelteti. További információ: Private Link – Azure Database for MySQL.
Adatbeemlési replikáció konfigurálása
Az adatok replikációban való konfigurálásához hajtsa végre a következő lépéseket:
Jelentkezzen be arra az Azure-beli virtuális gépre, amelyre telepítette a mysql-ügyféleszközt.
Csatlakozzon a forráshoz és a célhoz a mysql-ügyfél eszközzel.
A következő parancs futtatásával állapítsa meg, hogy a log_bin engedélyezve van-e a forráson a mysql-ügyféleszköz:
SHOW VARIABLES LIKE 'log_bin';Feljegyzés
Az önálló Azure Database for MySQL-kiszolgáló nagy tárterülettel, amely legfeljebb 16 TB-ot támogat, ez alapértelmezés szerint engedélyezve van.
Tipp.
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 lesz állítva.
A forráskiszolgáló SSL-kényszerítése alapján hozzon létre egy felhasználót a forráskiszolgálón a replikációs engedéllyel a megfelelő parancs futtatásával.
SSL használata esetén futtassa a következő parancsot:
CREATE USER 'syncuser'@'%' IDENTIFIED BY 'yourpassword'; GRANT REPLICATION SLAVE ON *.* TO ' syncuser'@'%' REQUIRE SSL;Ha nem SSL-t használ, futtassa a következő parancsot:
CREATE USER 'syncuser'@'%' IDENTIFIED BY 'yourpassword'; GRANT REPLICATION SLAVE ON *.* TO ' syncuser'@'%';Az adatbázis mydumperrel történő biztonsági mentéséhez futtassa a következő parancsot az Azure-beli virtuális gépen, ahol telepítettük a mydumper\myloadert:
mydumper --host=<primary_server>.mysql.database.azure.com --user=<username>@<primary_server> --password=<Password> --outputdir=./backup --rows=100000 -G -E -R -z --trx-consistency-only --compress --build-empty-files --threads=16 --compress-protocol --ssl --regex '^(classicmodels\.)' -L mydumper-logs.txtTipp.
A --trx-konzisztencia lehetőség csak a tranzakciós konzisztenciához szükséges, amíg biztonsági másolatot készítünk.
- A mysqldump --egy tranzakciójának mydumper-megfelelője.
- Akkor hasznos, ha az összes tábla InnoDB.
- A "fő" szálnak csak a globális zárolást kell tárolnia, amíg a "memóriakép" szálak el nem indíthatnak egy tranzakciót.
- A globális zárolás legrövidebb időtartamát kínálja
A "fő" szálnak csak a globális zárolást kell tárolnia, amíg a "memóriakép" szálak el nem indíthatnak egy tranzakciót.
A parancs változóit az alábbiakban ismertetjük:
HOW-TO-MANAGE-FIREWALL-PORTAL –-host: Az elsődleges kiszolgáló neve
- --user: Egy felhasználó neve (username@servername formátumban, mivel az elsődleges kiszolgáló az Azure Database for MySQL- Single Servert futtatja). Használhat kiszolgáló-rendszergazdát, vagy select és RELOAD engedélyekkel rendelkező felhasználót.
- --Jelszó: A fenti felhasználó jelszava
További információ a mydumper használatáról: mydumper/myloader
Olvassa el a metaadatfájlt a bináris naplófájl nevének meghatározásához és az eltoláshoz az alábbi parancs futtatásával:
cat ./backup/metadataEbben a parancsban a ./backup az előző lépésben használt kimeneti könyvtárra hivatkozik.
Az eredményeknek az alábbi képen látható módon kell megjelennie:
Jegyezze fel a bináris fájl nevét a későbbi lépésekben való használatra.
Állítsa vissza az adatbázist a myloaderrel az alábbi parancs futtatásával:
myloader --host=<servername>.mysql.database.azure.com --user=<username> --password=<Password> --directory=./backup --queries-per-transaction=100 --threads=16 --compress-protocol --ssl --verbose=3 -e 2>myloader-logs.txtA parancs változóit az alábbiakban ismertetjük:
- --host: A replikakiszolgáló neve
- --user: Felhasználó neve. Használhat kiszolgálói rendszergazdát vagy olvasási\írási engedéllyel rendelkező felhasználót, aki képes visszaállítani a sémákat és az adatokat az adatbázisba
- --Jelszó: A felhasználó jelszava a fenti
Az elsődleges kiszolgálón az SSL-kényszerítéstől függően csatlakozzon a replikakiszolgálóhoz a mysql-ügyféleszköz használatával, és hajtsa végre az alábbi lépéseket.
Ha az SSL-kényszerítés engedélyezve van, akkor:
i. Innen letöltheti az SSL-en keresztüli kommunikációhoz szükséges tanúsítványt az Azure Database for MySQL-kiszolgálóval.
ii. Nyissa meg a fájlt a jegyzettömbben, és illessze be a tartalmat a "NYILVÁNOS KULCSÚ TANÚSÍTVÁNY KÖRNYEZETÉNEK ELHELYEZÉSE IDE" című szakaszba.
SET @cert = '-----BEGIN CERTIFICATE----- PLACE YOUR PUBLIC KEY CERTIFICATE'S CONTEXT HERE -----END CERTIFICATE-----'iii. Az adatok replikációban való konfigurálásához futtassa a következő parancsot:
CALL mysql.az_replication_change_master('<Primary_server>.mysql.database.azure.com', '<username>@<primary_server>', '<Password>', 3306, '<File_Name>', <Position>, @cert);Feljegyzés
Határozza meg a pozíciót és a fájlnevet a 6. lépésben beszerzett információkból.
Ha az SSL-kényszerítés nincs engedélyezve, futtassa a következő parancsot:
CALL mysql.az_replication_change_master('<Primary_server>.mysql.database.azure.com', '<username>@<primary_server>', '<Password>', 3306, '<File_Name>', <Position>, '');
A replikáció a replikakiszolgálóról való elindításához hívja meg az alábbi tárolt eljárást.
call mysql.az_replication_start;A replikáció állapotának ellenőrzéséhez futtassa a következő parancsot a replikakiszolgálón:
show slave status \G;Feljegyzés
A MySQL Workbench használata esetén a \G módosító nem szükséges.
Ha a Slave_IO_Running és a Slave_SQL_Running állapota Igen, és a Seconds_Behind_Master értéke 0, akkor a replikáció jól működik. Seconds_Behind_Master jelzi, hogy a replika mennyi késésben van. Ha az érték nem 0, akkor a replika a frissítéseket dolgozza fel.
A replikáció tesztelése (nem kötelező)
Annak ellenőrzéséhez, hogy a data-in replikáció megfelelően működik-e, ellenőrizheti, hogy az elsődleges táblák módosításai replikálva lettek-e a replikára.
Azonosítsa a teszteléshez használandó táblát, például az Ügyfelek táblát, majd ellenőrizze, hogy a benne található bejegyzések száma megegyezik-e az elsődleges és replikakiszolgálókon a következő parancs futtatásával:
select count(*) from customers;Jegyezze fel a bejegyzésszámot a későbbi összehasonlításhoz.
A replikáció teszteléséhez próbáljon meg adatokat hozzáadni az elsődleges kiszolgáló ügyféltábláihoz, és ellenőrizze, hogy az új adatok replikálva vannak-e. Ebben az esetben két sort fog hozzáadni egy táblához az elsődleges kiszolgálón, majd ellenőriznie kell, hogy replikálva vannak-e a replikakiszolgálón.
Az elsődleges kiszolgáló Ügyfelek táblájában szúrjon be sorokat az alábbi parancs futtatásával:
insert into `customers`(`customerNumber`,`customerName`,`contactLastName`,`contactFirstName`,`phone`,`addressLine1`,`addressLine2`,`city`,`state`,`postalCode`,`country`,`salesRepEmployeeNumber`,`creditLimit`) values (<ID>,'name1','name2','name3 ','11.22.5555','54, Add',NULL,'Add1',NULL,'44000','country',1370,'21000.00');A replikáció állapotának ellenőrzéséhez hívja meg a show slave status \G parancsot annak ellenőrzéséhez, hogy a replikáció a várt módon működik-e.
A replikakiszolgálón futtassa a következő parancsot annak ellenőrzéséhez, hogy a darabszám megegyezik-e:
select count(*) from customers;
Sikeres átállás biztosítása
A sikeres átállás érdekében a következő feladatokat kell elvégeznie:
- A célkiszolgálóhoz való csatlakozáshoz konfigurálja a megfelelő kiszolgálószintű tűzfalat és virtuális hálózati szabályokat. A portálon összehasonlíthatja a forrásra és a célra vonatkozó tűzfalszabályokat.
- Konfigurálja a megfelelő bejelentkezéseket és adatbázisszintű engedélyeket a célkiszolgálón. Futtathatja a SELECT FROM mysql.user; parancsot a forrás- és célkiszolgálókon az összehasonlításhoz.
- Győződjön meg arról, hogy az önálló Azure Database for MySQL-kiszolgálóhoz érkező összes bejövő kapcsolat le van állítva.
Tipp.
Beállíthatja, hogy az önálló Azure Database for MySQL-kiszolgáló csak olvasható legyen.
- Győződjön meg arról, hogy a replika felzárkózott az elsődlegeshez a \G megjelenítési rabszolga állapot futtatásával, és győződjön meg arról, hogy a Seconds_Behind_Master paraméter értéke 0.
- Ügyfelek és ügyfélalkalmazások átirányítása a rugalmas Azure Database for MySQL-kiszolgáló célpéldányára.
- Az átállás befejezéséhez futtassa a mysql.az_replication_stop tárolt eljárást, amely leállítja a replikakiszolgálóról történő replikációt.
- Hívja meg a mysql.az_replication_remove_master a data-in replikációs konfiguráció eltávolításához.
Ezen a ponton az alkalmazások csatlakoznak az új rugalmas Azure Database for MySQL-kiszolgálóhoz, és a forrás változásai többé nem replikálódnak a célhelyre. Azure Database for MySQL-tűzfalszabályok létrehozása és kezelése az Azure Portalon
Kapcsolódó tartalom
- Adatok replikálás rugalmas Azure Database for MySQL-kiszolgálóra
- Rugalmas Azure Database for MySQL-kiszolgálói adatok replikációjának konfigurálása
- az Azure Database for MySQL gyakori hibáinak elhárítása
- MySQL offline migrálása az Azure Database for MySQL-be az Azure Database Migration Service használatával