Megosztás a következőn keresztül:


Az Azure Database for MySQL konfigurálása – Rugalmas kiszolgálói adatok replikálása

Ez a cikk azt ismerteti, hogyan állíthatja be az adatok replikálását a rugalmas Azure Database for MySQL-kiszolgálóra a rugalmas Azure Database for MySQL-kiszolgálón 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.

Feljegyzés

A cikk a slave kifejezést tartalmazza, 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.

Ha replikát szeretne létrehozni a rugalmas Azure Database for MySQL-kiszolgálópéldányban, replikálja az adatokat az Azure Database for MySQL-be – A rugalmas kiszolgáló 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 adatreplikálás bináris napló (binlog) fájlpozícióalapú replikációval vagy GTID-alapú replikációval konfigurálható. A binlog-replikációval kapcsolatos további információkért tekintse meg a MySQL-replikációt.

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

Azure Database for MySQL Flexible Server példány létrehozása, amelyet replikaként lehet használni

  1. Hozzon létre egy új, rugalmas Azure Database for MySQL-kiszolgálópéldányt (például replica.mysql.database.azure.com). Tekintse meg a rövid útmutatót: Hozzon létre egy Azure Database for MySQL-példányt az Azure Portallal a kiszolgálólétrehozáshoz. Ez a kiszolgáló az adat-be replikáció replika kiszolgálója.

  2. 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 rugalmas Azure Database for MySQL-kiszolgálópéldányon.

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 data-in replikációhoz. Ez a kiszolgáló az adatbemeneti replikáció forrása.

  1. A folytatás előtt tekintse át a forráskiszolgáló követelményeit .

  2. Hálózatkezelési követelmények

    • 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.

    • Ha privát hozzáférés (VNet-integráció) van használatban, győződjön meg arról, hogy van kapcsolat a forráskiszolgáló és a replikakiszolgálót futtató virtuális hálózat között.

    • Győződjön meg arról, hogy helyek közötti kapcsolatot biztosítunk a helyszíni forráskiszolgálókhoz expressRoute vagy VPN használatával. A virtuális hálózat létrehozásával kapcsolatos további információkért tekintse meg a virtuális hálózat dokumentációját, és különösen a részletes információkat tartalmazó rövid útmutatókat.

    • Ha privát hozzáférést (VNet-integrációt) használ a replikakiszolgálón, és a forrás az Azure-beli virtuális gép, győződjön meg arról, hogy létrehozta a virtuális hálózatok közötti kapcsolatot. A VNet-VNet társviszony-létesítés támogatott. Más kapcsolati módszereket is használhat a különböző régiókban lévő virtuális hálózatok közötti kommunikációra, például a VNet-VNet kapcsolatot. További információ: VNet-to-VNet VPN Gateway

    • Győződjön meg arról, hogy a virtuális hálózati hálózati biztonsági csoport szabályai nem blokkolják a 3306-os kimenő portot (akkor is bejövő, ha a MySQL Azure-beli virtuális gépen fut). További részletek a Virtual Network NSG-forgalom szűréséről: Hálózati forgalom szűrése hálózati biztonsági csoportokkal.

    • Konfigurálja a forráskiszolgáló tűzfalszabályait a replikakiszolgáló IP-címének engedélyezéséhez.

  3. Kövesse a megfelelő lépéseket a bin-log pozíció vagy a GTID-alapú adatreplikálás használata alapján.

    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 szolgáltatást a forráskiszolgálón (vagy indítsa újra) 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';
      
  4. Konfigurálja a forráskiszolgáló beállításait.

    Az adatreplikáláshoz a paraméternek lower_case_table_names konzisztensnek kell lennie a forrás- és replikakiszolgálók között. Ez a paraméter alapértelmezés szerint 1 a rugalmas Azure Database for MySQL-kiszolgálón.

    SET GLOBAL lower_case_table_names = 1;
    
  5. 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.

    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' REQUIRE SSL;
    GRANT REPLICATION SLAVE ON *.* TO ' syncuser'@'%';
    

    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'@'%';
    
  6. Állítsa be a forráskiszolgálót olvasásra készenléti módra.

    Az adatbázis leürítésének megkezdése előtt a kiszolgálót írásvédett módba kell átállítani. Írásvédett módban a forrás nem fogja tudni feldolgozni az írási tranzakciókat. Értékelje ki a vállalkozására gyakorolt hatást, és szükség esetén ütemezze az írásvédett időszakot csúcsidőn kívüli időpontban.

    FLUSH TABLES WITH READ LOCK;
    SET GLOBAL read_only = ON;
    
  7. 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.

    Képernyőkép a főállapot-eredményekről.


Forráskiszolgáló mentése és visszaállítása

  1. Határozza meg, hogy mely adatbázisokat és táblákat szeretné replikálni az Azure Database for MySQL Flexible Server-be, és hajtsa végre az exportálást 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 Dump & Restore témát. Szükségtelen a MySQL-kódtár és a teszttár kiírása.

  2. Á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;
    

    Megjegyzés

    Mielőtt a kiszolgáló vissza van állítva olvasási/írási módra, lekérheti a GTID-adatokat a GTID_EXECUTED globális változó használatával. Ez a későbbiekben a GTID replikakiszolgálón való beállításához lesz használva.

  3. Mentési fájl visszaállítása új szerverre.

    Állítsa vissza az adatmentési fájlt az Azure Database for MySQL Rugalmas Kiszolgálón 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 azonos régióban mint a replikakiszolgáló. Állítsa vissza a rugalmas Azure Database for MySQL-kiszolgálópéldányra a virtuális gépről.

Feljegyzés

Ha el szeretné kerülni, hogy az adatbázist olvasási módba állítsa a mentés és visszaállítás során, használhatja a mydumper/myloadert.

GTID beállítása a replikakiszolgálón

  1. Kihagyja a lépést, ha bin-log pozícióalapú replikációt használ

  2. A forrásból származó memóriaképfájlból származó GTID-információk szükségesek a célkiszolgáló (replika) GTID-előzményeinek visszaállításához.

  3. A forrásból származó GTID-adatok használatával hajtsa végre a GTID alaphelyzetbe állítását a replikakiszolgálón a következő CLI-paranccsal:

    az mysql flexible-server gtid reset --resource-group  <resource group> --server-name <replica server name> --gtid-set <gtid set from the source server> --subscription <subscription id>
    

További részletekért tekintse meg a GTID alaphelyzetbe állítását.

Feljegyzés

A GTID alaphelyzetbe állítása nem hajtható végre georedundáns biztonsági mentést engedélyező kiszolgálón. Tiltsa le a georedundanciát a GTID alaphelyzetbe állításához a kiszolgálón. A GTID alaphelyzetbe állítása után újra engedélyezheti a Georedundancia beállítást. A GTID alaphelyzetbe állítási művelete érvényteleníti az összes rendelkezésre álló biztonsági mentést, ezért a georedundancia ismételt engedélyezését követően eltarthat egy napig, amíg a georedundáns visszaállítás elvégezhető a kiszolgálón

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

    Az összes adatbemeneti replikáció funkció tárolt eljárásokkal történik. A Data-in replikáció tárolt eljárások között megtalálhatók minden eljárás. 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 a MySQL kiszolgálóhoz tartozó Azure Database mysql.az_replication_change_master vagy mysql.az_replication_change_master_with_gtid 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>');
    
    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 a futásból show master status
    • master_log_pos: bináris napló pozíciója a futó folyamatbó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.

    Feljegyzé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 Kapcsolat biztonsági beállításai között. További információ: Tűzfalszabályok kezelése az Azure Database for MySQL -rugalmas kiszolgálóhoz az Azure Portal használatával.
    • Ha a mydumper/myloader használatával készített memóriaképet az adatbázisról, akkor lekérheti a master_log_file-t és a master_log_pos-t a /backup/metadata fájlból.

    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 a rugalmas Azure Database for MySQL-kiszolgálón üzemeltetett replikakiszolgáló között van beállítva. Ez a tárolt eljárás a replikán kerül végrehajtásra.

    CALL mysql.az_replication_change_master('master.companya.com', 'syncuser', 'P@ssword!', 3306, 'mysql-bin.000002', 120, @cert);
    
    CALL mysql.az_replication_change_master_with_gtid('master.companya.com', 'syncuser', 'P@ssword!', 3306, @cert);
    

    Replikáció SSL nélkül

    Az SSL nélküli replikáció a "companya.com" tartományban üzemeltetett forráskiszolgáló és a rugalmas Azure Database for MySQL-kiszolgálón ü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, '');
    
    CALL mysql.az_replication_change_master_with_gtid('master.companya.com', 'syncuser', 'P@ssword!', 3306, '');
    
  2. 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;
    
  3. 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;
    

    A replikáció helyes állapotának megismeréséhez tekintse meg a replikációs metrikákat – Replika IO-állapota és replika SQL-állapota a figyelési oldalon.

    Ha a Seconds_Behind_Master "0" érték, a replikáció jól működik. Seconds_Behind_Master azt jelzi, hogy mennyit késik a replika. 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 a data-in repliká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;
SHOW BINLOG EVENTS [IN 'log_name'] [FROM pos][LIMIT [offset,] row_count]

Képernyőkép a bináris napló eredményeinek megjelenítéséről.

Következő lépés