Az Azure Database for MySQL-adatok replikációjának konfigurálása

Cikk
12/19/2023

A következőkre vonatkozik: Azure Database for MySQL – Önálló kiszolgáló

Fontos

Az önálló Azure Database for MySQL-kiszolgáló a kivonási útvonalon van. Határozottan javasoljuk, hogy frissítsen rugalmas Azure Database for MySQL-kiszolgálóra. További információ a rugalmas Azure Database for MySQL-kiszolgálóra való migrálásról: Mi történik az önálló Azure Database for MySQL-kiszolgálóval?

Ez a cikk bemutatja, hogyan állíthatja be a data-in replikációt az Azure Database for MySQL-ben a forrás- és replikakiszolgálók konfigurálásával. Ez a cikk feltételezi, hogy rendelkezik korábbi tapasztalatokkal a MySQL-kiszolgálók és -adatbázisok terén.

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.

Ha replikát szeretne létrehozni az Azure Database for MySQL szolgáltatásban, a Data-in Replication szinkronizálja az adatokat egy helyszíni forrás MySQL-kiszolgálóról, virtuális gépeken vagy felhőbeli adatbázis-szolgáltatásokban. Az adatbetöltési replikáció a Bináris napló (binlog) fájl pozícióalapú vagy GTID-alapú replikáción alapul, amely natív a MySQL-ben. A binlog replikációval kapcsolatos további információkért tekintse meg a MySQL-binlog replikációjának áttekintését.

A cikk lépéseinek végrehajtása előtt tekintse át a data-in replikáció korlátait és követelményeit .

Egyetlen Azure Database for MySQL-kiszolgálópéldány létrehozása replikaként való használatra

Önálló Azure Database for MySQL-kiszolgáló új példányának létrehozása (például replica.mysql.database.azure.com). Tekintse meg az Azure Database for MySQL-kiszolgáló létrehozását az Azure Portallal a kiszolgáló létrehozásához. Ez a kiszolgáló a data-in replikáció "replika" kiszolgálója.

Fontos

Az Azure Database for MySQL-kiszolgálót az általános célú vagy memóriaoptimalizált tarifacsomagokban kell létrehozni, mivel az adatreplikálás csak ezekben a szintekben támogatott. A GTID az 5.7- és 8.0-s verziókban támogatott, és csak olyan kiszolgálókon, amelyek legfeljebb 16 TB-os (általános célú tárolás v2) tárhelyet támogatnak.
Hozza létre ugyanazokat a felhasználói fiókokat és a megfelelő jogosultságokat.

A felhasználói fiókok nem replikálódnak a forráskiszolgálóról a replikakiszolgálóra. Ha azt tervezi, hogy hozzáférést biztosít a felhasználóknak a replikakiszolgálóhoz, manuálisan kell létrehoznia az összes fiókot és a megfelelő jogosultságot ezen az újonnan létrehozott Azure Database for MySQL-kiszolgálón.
Adja hozzá a forráskiszolgáló IP-címét a replika tűzfalszabályaihoz.

A tűzfalszabályokat az Azure Portallal vagy az Azure CLI-vel frissítheti.
Nem kötelező – Ha GTID-alapú replikációt szeretne használni a forráskiszolgálóról az Azure Database for MySQL replikakiszolgálóra, engedélyeznie kell a következő kiszolgálóparamétereket az Azure Database for MySQL-kiszolgálón az alábbi portálképen látható módon:

A forrás MySQL-kiszolgáló konfigurálása

Az alábbi lépések előkészítik és konfigurálják a helyszíni, virtuális gépen vagy más felhőszolgáltatók által üzemeltetett adatbázis-szolgáltatásban üzemeltetett MySQL-kiszolgálót a replikációhoz. Ez a kiszolgáló a data-in replikáció "forrása".

A folytatás előtt tekintse át a forráskiszolgáló követelményeit .
Győződjön meg arról, hogy a forráskiszolgáló engedélyezi a bejövő és kimenő forgalmat a 3306-os porton, és hogy nyilvános IP-címmel rendelkezik, a DNS nyilvánosan elérhető, vagy hogy teljes tartománynévvel (FQDN) rendelkezik.

Tesztelje a forráskiszolgálóval való kapcsolatot úgy, hogy megpróbál csatlakozni egy másik gépen üzemeltetett MySQL-parancssorból vagy az Azure Portalon elérhető Azure Cloud Shellből .

Ha a szervezet szigorú biztonsági szabályzatokkal rendelkezik, és nem engedélyezi a forráskiszolgálón lévő összes IP-címet az Azure és a forráskiszolgáló közötti kommunikáció engedélyezéséhez, az alábbi paranccsal meghatározhatja a MySQL-kiszolgáló IP-címét.
1. Jelentkezzen be az Azure Database for MySQL-kiszolgálóra egy olyan eszközzel, mint a MySQL parancssor.
2. Hajtsa végre a következő lekérdezést.
```
mysql> SELECT @@global.redirect_server_host;
```
  Az alábbiakban néhány mintakimenet látható:
```
+-----------------------------------------------------------+
| @@global.redirect_server_host                             |
+-----------------------------------------------------------+
| e299ae56f000.tr1830.westus1-a.worker.database.windows.net |
 +-----------------------------------------------------------+
```
3. Lépjen ki a MySQL parancssorból.
4. Az IP-cím lekéréséhez hajtsa végre a következő parancsot a pingelési segédprogramban:
```
ping <output of step 2b>
```
  Például:
```
C:\Users\testuser> ping e299ae56f000.tr1830.westus1-a.worker.database.windows.net
Pinging tr1830.westus1-a.worker.database.windows.net (**11.11.111.111**) 56(84) bytes of data.
```
5. Konfigurálja a forráskiszolgáló tűzfalszabályait úgy, hogy az tartalmazza az előző lépés kimeneti IP-címét a 3306-os porton.
  
  Megjegyzés:
  
  Ez az IP-cím karbantartási/üzembehelyezési műveletek miatt változhat. Ez a kapcsolati módszer csak azoknak az ügyfeleknek szól, akik nem engedhetik meg maguknak az összes IP-cím engedélyezését a 3306-os porton.
Kapcsolja be a bináris naplózást.

Ellenőrizze, hogy engedélyezve van-e a bináris naplózás a forráson az alábbi parancs futtatásával:
```
SHOW VARIABLES LIKE 'log_bin';
```
Ha a változó log_bin "ON" értékkel lesz visszaadva, a bináris naplózás engedélyezve van a kiszolgálón.

Ha log_bin a rendszer a "KI" értékkel adja vissza, és a forráskiszolgáló helyszíni vagy virtuális gépeken fut, ahol hozzáférhet a konfigurációs fájlhoz (my.cnf), kövesse az alábbi lépéseket:
1. Keresse meg a MySQL-konfigurációs fájlt (my.cnf) a forráskiszolgálón. Például: /etc/my.cnf
2. Nyissa meg a konfigurációs fájlt a szerkesztéshez, és keresse meg a mysqld szakaszt a fájlban.
3. A mysqld szakaszban adja hozzá a következő sort:
```
log-bin=mysql-bin.log
```
4. Indítsa újra a MySQL-forráskiszolgálót a módosítások érvénybe lépéséhez.
5. A kiszolgáló újraindítása után ellenőrizze, hogy a bináris naplózás engedélyezve van-e a korábbi lekérdezés futtatásával:
```
SHOW VARIABLES LIKE 'log_bin';
```
Konfigurálja a forráskiszolgáló beállításait.

A data-in replikáció megköveteli, hogy a paraméter lower_case_table_names konzisztens legyen a forrás- és replikakiszolgálók között. Ez a paraméter alapértelmezés szerint 1 az Azure Database for MySQL-ben.
```
SET GLOBAL lower_case_table_names = 1;
```
Nem kötelező – Ha GTID-alapú replikációt szeretne használni, ellenőriznie kell, hogy a GTID engedélyezve van-e a forráskiszolgálón. A következő parancsot a forrás MySQL-kiszolgálón futtatva ellenőrizheti, hogy gtid_mode be van-e kapcsolva.
```
show variables like 'gtid_mode';
```
Fontos

Minden kiszolgálóhoz be van állítva az alapértelmezett kikapcsolva érték gtid_mode. Nem kell engedélyeznie a GTID-t a forrás MySQL-kiszolgálón kifejezetten a data-in replikáció beállításához. Ha a GTID már engedélyezve van a forráskiszolgálón, a GTID-alapú replikációval is beállíthatja a data-in replikációt az önálló Azure Database for MySQL-kiszolgálóval. A fájlalapú replikációval minden kiszolgálóhoz beállíthat adatbetöltési replikációt, függetlenül a forráskiszolgáló gitd_mode konfigurációjától.
Hozzon létre egy új replikációs szerepkört, és állítson be engedélyt.

Hozzon létre egy felhasználói fiókot a forráskiszolgálón, amely replikációs jogosultságokkal van konfigurálva. Ezt SQL-parancsokkal vagy egy olyan eszközzel teheti meg, mint a MySQL Workbench. Fontolja meg, hogy SSL-sel szeretne-e replikálni, mivel ezt meg kell adni a felhasználó létrehozásakor. Tekintse meg a MySQL dokumentációját, amelyből megtudhatja, hogyan adhat hozzá felhasználói fiókokat a forráskiszolgálóhoz.

Az alábbi parancsokban az új replikációs szerepkör bármely gépről elérheti a forrást, nem csak a forrást üzemeltető gépről. Ehhez adja meg a "syncuser@'%" értéket a felhasználói létrehozási parancsban. A fióknevek megadásáról további információt a MySQL dokumentációjában talál.

SQL-parancs

Replikáció SSL-lel

Ha minden felhasználói kapcsolathoz SSL-t szeretne igényelni, hozzon létre egy felhasználót az alábbi paranccsal:
```
CREATE USER 'syncuser'@'%' IDENTIFIED BY 'yourpassword';
GRANT REPLICATION SLAVE ON *.* TO 'syncuser'@'%' REQUIRE SSL;
```
Replikáció SSL nélkül

Ha az SSL nem minden kapcsolathoz szükséges, a következő paranccsal hozzon létre egy felhasználót:
```
CREATE USER 'syncuser'@'%' IDENTIFIED BY 'yourpassword';
GRANT REPLICATION SLAVE ON *.* TO 'syncuser'@'%';
```
MySQL Workbench

A replikációs szerepkör a MySQL Workbenchben való létrehozásához nyissa meg a Felhasználók és jogosultságok panelt a Felügyeleti panelen, majd válassza a Fiók hozzáadása lehetőséget.

Írja be a felhasználónevet a Bejelentkezési név mezőbe.

Válassza a Rendszergazda osztó szerepkörök panelt, majd a Globális jogosultságok listájában válassza a Replikációs rabszolga lehetőséget. Ezután válassza az Alkalmaz lehetőséget a replikációs szerepkör létrehozásához.
Állítsa be a forráskiszolgálót írásvédett üzemmódra.

Az adatbázis kiírásának megkezdése előtt a kiszolgálót írásvédett módban kell elhelyezni. Írásvédett módban a forrás nem fogja tudni feldolgozni az írási tranzakciókat. Értékelje ki a vállalkozásra gyakorolt hatást, és szükség esetén ütemezze az írásvédett ablakot csúcsidőn kívülre.
```
FLUSH TABLES WITH READ LOCK;
SET GLOBAL read_only = ON;
```
Bináris naplófájl nevének és eltolásának lekérése.

Futtassa a show master status parancsot az aktuális bináris naplófájl nevének és eltolásának meghatározásához.
```
 show master status;
```
Az eredményeknek az alábbiakhoz hasonlóan kell megjelennie. Jegyezze fel a bináris fájl nevét a későbbi lépésekben való használatra.

A forráskiszolgáló memóriaképe és visszaállítása

Határozza meg, hogy mely adatbázisokat és táblákat szeretné replikálni az Azure Database for MySQL-be, és hajtsa végre a memóriaképet a forráskiszolgálóról.

A mysqldump használatával adatbázisokat hozhat ki az elsődleges kiszolgálóról. A részletekért tekintse meg a Memóriakép és visszaállítás című témakört. Szükségtelen a MySQL-kódtár és a teszttár kiírása.
Nem kötelező – Ha gtid-alapú replikációt szeretne használni, azonosítania kell az elsődlegesen végrehajtott utolsó tranzakció GTID-azonosítóját. A következő paranccsal jegyezheti fel a főkiszolgálón végrehajtott utolsó tranzakció GTID azonosítóját.
```
show global variables like 'gtid_executed';
```
Állítsa be a forráskiszolgálót olvasási/írási módra.

Az adatbázis kidobása után módosítsa a forrás MySQL-kiszolgálót írási/olvasási módra.
```
SET GLOBAL read_only = OFF;
UNLOCK TABLES;
```
Memóriaképfájl visszaállítása új kiszolgálóra.

Állítsa vissza a memóriaképfájlt az Azure Database for MySQL szolgáltatásban létrehozott kiszolgálóra. A memóriaképfájl MySQL-kiszolgálóra való visszaállításáról a Dump &Restore (Memóriakép és visszaállítás) című témakörben tájékozódhat. Ha a memóriaképfájl nagy, töltse fel egy azure-beli virtuális gépre a replikakiszolgálóval azonos régióban. Állítsa vissza az Azure Database for MySQL-kiszolgálóra a virtuális gépről.
Nem kötelező – Jegyezze fel a visszaállított kiszolgáló GTID azonosítóját az Azure Database for MySQL-ben, hogy meggyőződjön arról, hogy az megegyezik az elsődleges kiszolgálóval. Az alábbi paranccsal jegyezheti fel az Azure Database for MySQL replikakiszolgálón a GTID kiürített értékének GTID-azonosítóját. A gtid_purged értékének meg kell egyeznie a GTID-alapú replikáció működéséhez a 2. lépésben feljegyzett főkiszolgáló gtid_executed értékével.
```
show global variables like 'gtid_purged';
```

Forrás- és replikakiszolgálók összekapcsolása a data-in replikáció elindításához

Állítsa be a forráskiszolgálót.

Az összes adatreplikációs függvény tárolt eljárásokkal történik. A data-in replikációs tárolt eljárásokban minden eljárás megtalálható. A tárolt eljárások futtathatók a MySQL-rendszerhéjban vagy a MySQL Workbenchben.

Két kiszolgáló összekapcsolásához és a replikáció elindításához jelentkezzen be a célreplika-kiszolgálóra az Azure Database for MySQL szolgáltatásban, és állítsa be a külső példányt forráskiszolgálóként. Ez az mysql.az_replication_change_master Azure Database for MySQL-kiszolgálón tárolt eljárással történik.
```
CALL mysql.az_replication_change_master('<master_host>', '<master_user>', '<master_password>', <master_port>, '<master_log_file>', <master_log_pos>, '<master_ssl_ca>');
```
Nem kötelező – Ha gtid-alapú replikációt szeretne használni, a következő paranccsal kell összekapcsolnia a két kiszolgálót
```
call mysql.az_replication_change_master_with_gtid('<master_host>', '<master_user>', '<master_password>', <master_port>, '<master_ssl_ca>');
```
- master_host: a forráskiszolgáló állomásneve
- master_user: a forráskiszolgáló felhasználóneve
- master_password: a forráskiszolgáló jelszava
- master_port: portszám, amelyen a forráskiszolgáló figyeli a kapcsolatokat. (A 3306 az alapértelmezett port, amelyen a MySQL figyel)
- master_log_file: a bináris naplófájl neve nem fut show master status
- master_log_pos: bináris napló pozíciója a futtatástól show master status
- master_ssl_ca: A hitelesítésszolgáltatói tanúsítvány környezete. Ha nem SSL-t használ, adjon meg üres sztringet.
  
  Javasoljuk, hogy ezt a paramétert változóként adja át. További információkért tekintse meg az alábbi példákat.
Megjegyzés:

Ha a forráskiszolgálót egy Azure-beli virtuális gépen üzemelteti, állítsa az "Azure-szolgáltatásokhoz való hozzáférés engedélyezése" értéket "ON" értékre, hogy a forrás- és replikakiszolgálók kommunikálhassanak egymással. Ez a beállítás módosítható a Csatlakozás ion biztonsági beállításai közül. További információ: Tűzfalszabályok kezelése a portálon .

Példák

Replikáció SSL-lel

A változó @cert a következő MySQL-parancsok futtatásával jön létre:
```
SET @cert = '-----BEGIN CERTIFICATE-----
PLACE YOUR PUBLIC KEY CERTIFICATE'`S CONTEXT HERE
-----END CERTIFICATE-----'
```
Az SSL-replikáció a "companya.com" tartományban üzemeltetett forráskiszolgáló és az Azure Database for MySQL-ben üzemeltetett replikakiszolgáló között van beállítva. Ez a tárolt eljárás a replikán fut.
```
CALL mysql.az_replication_change_master('master.companya.com', 'syncuser', 'P@ssword!', 3306, 'mysql-bin.000002', 120, @cert);
```
Replikáció SSL nélkül

Az SSL nélküli replikáció a "companya.com" tartományban üzemeltetett forráskiszolgáló és az Azure Database for MySQL-ben üzemeltetett replikakiszolgáló között van beállítva. Ez a tárolt eljárás a replikán fut.
```
CALL mysql.az_replication_change_master('master.companya.com', 'syncuser', 'P@ssword!', 3306, 'mysql-bin.000002', 120, '');
```
Állítsa be a szűrést.

Ha kihagy néhány tábla replikálását a főkiszolgálóról, frissítse a replicate_wild_ignore_table kiszolgálóparamétert a replikakiszolgálón. Több táblázatmintát is megadhat vesszővel tagolt lista használatával.

A paraméterről további információt a MySQL dokumentációjában talál.

A paraméter frissítéséhez használhatja az Azure Portalt vagy az Azure CLI-t.
Indítsa el a replikációt.

A replikáció elindításához hívja meg a mysql.az_replication_start tárolt eljárást.
```
CALL mysql.az_replication_start;
```
Ellenőrizze a replikáció állapotát.

A replikáció állapotának show slave status megtekintéséhez hívja meg a replikakiszolgáló parancsát.
```
show slave status;
```
Ha az állapota Slave_IO_RunningSlave_SQL_Running "igen", és értéke Seconds_Behind_Master "0", a replikáció jól működik. Seconds_Behind_Master A replika késését jelzi. Ha az érték nem "0", az azt jelenti, hogy a replika frissítéseket dolgoz fel.

Egyéb hasznos tárolt eljárások az adatreplikációs műveletekhez

Replikáció leállítása

A forrás- és replikakiszolgáló közötti replikáció leállításához használja a következő tárolt eljárást:

CALL mysql.az_replication_stop;

Replikációs kapcsolat eltávolítása

A forrás- és replikakiszolgáló közötti kapcsolat eltávolításához használja a következő tárolt eljárást:

CALL mysql.az_replication_remove_master;

Replikációs hiba kihagyása

A replikációs hiba kihagyásához és a replikáció folytatásának engedélyezéséhez használja a következő tárolt eljárást:

CALL mysql.az_replication_skip_counter;

Nem kötelező – Ha gtid-alapú replikációt szeretne használni, a tranzakció kihagyásához használja az alábbi tárolt eljárást

call mysql. az_replication_skip_gtid_transaction(‘<transaction_gtid>’)

Az eljárás kihagyhatja az adott GTID tranzakcióját. Ha a GTID formátum nem megfelelő, vagy a GTID-tranzakció már végrehajtásra került, az eljárás végrehajtása sikertelen lesz. A tranzakció GTID-azonosítója a bináris napló elemzésével határozható meg a tranzakciós események ellenőrzéséhez. A MySQL egy segédprogram mysqlbinlogot biztosít a bináris naplók elemzéséhez és a tartalom szöveges formátumban való megjelenítéséhez, amely a tranzakció GTID azonosítójának azonosítására használható.

Fontos

Ez az eljárás csak egy tranzakció kihagyására használható, és nem használható a gtid-készlet kihagyására vagy gtid_purged beállítására.

Ha az aktuális replikációs pozíció után szeretné kihagyni a következő tranzakciót, az alábbi paranccsal azonosítsa a következő tranzakció GTID azonosítóját az alább látható módon.

SHOW BINLOG EVENTS [IN 'log_name'] [FROM pos][LIMIT [offset,] row_count]

Show binary log results

További lépések

További információ az Azure Database for MySQL-hez készült data-in replikációról.

Share via