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

Cikk
12/09/2023

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.

Megjegyzés:

This article contains references to the term slave, a term that Microsoft no longer uses. 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 Gépház a különböző forgatókönyvek adatreplikálásához.
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.

Megjegyzé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.
Megjegyzé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:
1. A kiszolgáló létrehozása zónaredundáns ha engedélyezve
2. A HA letiltása
3. Kövesse a cikket az adatok replikációjának beállításához
4. Az átállás után távolítsa el a data-in replikációs konfigurációt
5. 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.
Csatlakozás a forráshoz és a célhoz a mysql-ügyféleszköz használatával.
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';
```
Megjegyzé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.txt
```
Tipp.

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ói rendszergazdát, vagy olyan felhasználót, aki rendelkezik Standard kiadás LECT és RELOAD engedélyekkel.
- --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/metadata
```
Ebben 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.txt
```
A 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);
```
  Megjegyzé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;
```
Megjegyzé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. A Standard kiadás LECT FROM mysql.user; parancsot futtathatja 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

További lépések

További információ a rugalmas Azure Database for MySQL-kiszolgáló adatainak replikálásáról és az Azure Database for MySQL rugalmas kiszolgálói adatok replikációjának konfigurálásáról
További információ az Azure Database for MySQL gyakori hibáinak elhárításáról.
További információ a MySQL azure Database for MySQL-be való offline migrálásáról az Azure Database Migration Service használatával.