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

Adatok replikálása a rugalmas Azure Database for MySQL-kiszolgálóba

  • Cikk

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

A data-in replikáció lehetővé teszi az adatok szinkronizálását egy külső MySQL-kiszolgálóról egy rugalmas Azure Database for MySQL-kiszolgálópéldányba. A külső kiszolgáló lehet helyszíni, virtuális gépeken, önálló Azure Database for MySQL-kiszolgálón vagy más felhőszolgáltatók által üzemeltetett adatbázis-szolgáltatásban. Az adatbetöltési replikáció a bináris napló (binlog) fájlpozícióján vagy GTID-alapú replikáción alapul. A binlog-replikációval kapcsolatos további információkért tekintse meg a MySQL-replikációt.

Feljegyzés

A magas rendelkezésre állású kiszolgálók adatbeosztásának konfigurálása csak GTID-alapú replikációval támogatott.

Mikor érdemes a data-in replikációt használni?

A data-in replikáció használatának fő forgatókönyvei a következők:

  • Hibrid adatszinkronizálás hronizálás: A data-in replikációval szinkronizálhatja az adatokat a helyszíni kiszolgálók és a rugalmas Azure Database for MySQL-kiszolgáló között. Ez a szinkronizálás segít a hibrid alkalmazások létrehozásában. Ez a módszer akkor vonzó, ha már rendelkezik helyi adatbázis-kiszolgálóval, de az adatokat egy olyan régióba szeretné áthelyezni, amely közelebb van a végfelhasználókhoz.
  • Többfelhős szinkronizálás: Összetett felhőmegoldások esetén a Data-in replikációval szinkronizálhatja az adatokat a rugalmas Azure Database for MySQL-kiszolgáló és a különböző felhőszolgáltatók között, beleértve az ezekben a felhőkben üzemeltetett virtuális gépeket és adatbázis-szolgáltatásokat.
  • Migrálás: Az ügyfelek minimális idő alatt migrálhatnak olyan nyílt forráskódú eszközökkel, mint például a MyDumper/MyLoader adatbetöltési replikációval. Az éles terhelés szelektív átállása a forrásból a céladatbázisba a data-in replikációval lehetséges.

Migrálási forgatókönyvek esetén használja az Azure Database Migration Service(DMS) szolgáltatást.

Korlátozások és szempontok

Nem replikált adatok

A forráskiszolgálón lévő mysql rendszeradatbázis nincs replikálva. Emellett a forráskiszolgálón lévő fiókok és engedélyek módosításai nem replikálódnak. Ha létrehoz egy fiókot a forráskiszolgálón, és ennek a fióknak hozzá kell férnie a replikakiszolgálóhoz, manuálisan hozza létre ugyanazt a fiókot a replikakiszolgálón. A rendszeradatbázis tábláinak megismeréséhez tekintse meg a MySQL-kézikönyvet.

Az adatreplikálás támogatott a magas rendelkezésre állású (HA) kompatibilis kiszolgálókon

A magas rendelkezésre állású (HA) kiszolgáló adatreplikációs támogatása csak GTID-alapú replikációval érhető el.

A GTID-t használó replikáció tárolt eljárása az összes HA-kompatibilis kiszolgálón elérhető a név mysql.az_replication_change_master_with_gtidalapján.

Szűrő

A paraméter replicate_wild_ignore_table replikációs szűrőt hoz létre a replikakiszolgáló tábláihoz. Ha módosítani szeretné ezt a paramétert az Azure Portalról, keresse meg a replikaként használt rugalmas Azure Database for MySQL-kiszolgálópéldányt, és válassza a "Kiszolgálóparaméterek" lehetőséget a replicate_wild_ignore_table paraméter megtekintéséhez/szerkesztéséhez.

Követelmények

  • A forráskiszolgáló verziójának legalább a MySQL 5.7-es verziójának kell lennie.

  • Azt javasoljuk, hogy ugyanazzal a verzióval rendelkezzen a forrás- és replikakiszolgálókhoz. Mindkettőnek például a MySQL 5.7-es verziójának kell lennie, vagy mindkettőnek a MySQL 8.0-s verziójának kell lennie.

  • Azt javasoljuk, hogy minden táblában legyen egy elsődleges kulcs. Ha egy elsődleges kulcs nélküli táblánk van, a replikáció lassúságára lehet szükség.

  • A forráskiszolgálónak a MySQL InnoDB motort kell használnia.

  • A felhasználónak rendelkeznie kell a megfelelő engedélyekkel a bináris naplózás konfigurálásához és új felhasználók létrehozásához a forráskiszolgálón.

  • A forráskiszolgálón lévő bináris naplófájlokat nem szabad kiüríteni, mielőtt a replika alkalmazza ezeket a módosításokat. Ha a forrás rugalmas Azure Database for MySQL-kiszolgáló, tekintse meg, hogyan konfigurálhat binlog_expire_logs_seconds rugalmas kiszolgálóhoz vagy önálló kiszolgálóhoz

  • Ha a forráskiszolgáló ssl-kompatibilis, győződjön meg arról, hogy a tartományhoz megadott SSL-hitelesítésszolgáltatói tanúsítvány szerepel a mysql.az_replication_change_master tárolt eljárásban. Tekintse meg az alábbi példákat és a paramétert master_ssl_ca .

  • Győződjön meg arról, hogy a forráskiszolgálót üzemeltető gép engedélyezi a bejövő és a kimenő forgalmat a 3306-os porton.

  • Nyilvános hozzáféréssel győződjön meg arról, hogy a forráskiszolgáló nyilvános IP-címmel rendelkezik, a DNS nyilvánosan elérhető, vagy hogy a forráskiszolgáló teljes tartománynévvel (FQDN) rendelkezik. Ha privát végponttal rendelkezik, és letiltotta a nyilvános hozzáférést, az adatreplikálás nem támogatott

  • Privát hozzáféréssel (VNet-integrációval) győződjön meg arról, hogy a forráskiszolgáló neve feloldható, és elérhető azon a virtuális hálózaton, amelyen a rugalmas Azure Database for MySQL-kiszolgálópéldány fut. (További részletekért látogasson el a Névfeloldás azure-beli virtuális hálózatok erőforrásaihoz).

Generált láthatatlan elsődleges kulcs

A MySQL 8.0-s vagy újabb verziója esetén a generált láthatatlan elsődleges kulcsok (GIPK) alapértelmezés szerint engedélyezve lesznek az összes rugalmas Azure Database for MySQL-kiszolgálópéldány esetében. A MySQL 8.0+-kiszolgálók hozzáadják a láthatatlan my_row_id oszlopot a táblákhoz és egy elsődleges kulcsot azon az oszlopon, ahol az InnoDB-tábla explicit elsődleges kulcs nélkül jön létre. Ez a funkció, ha engedélyezve van, hatással lehet néhány adatreplikációs használati esetre az alábbiak szerint:

  • Az adatreplikálás a következő replikációs hibával meghiúsul: "HIBA 1068 (42000): Több elsődleges kulcs definiálva", ha a forráskiszolgáló elsődleges kulcsot hoz létre a táblában elsődleges kulcs nélkül. A kockázatcsökkentéshez futtassa a következő SQL-parancsot, hagyja ki a replikációs hibát, és indítsa újra az adat-in replikációt.

    alter table <table name> drop column my_row_id, add primary key <primary key name>(<column name>);

  • Az adatreplikálás a következő replikációs hibával meghiúsul: "1075-ös HIBA (42000): Helytelen tábladefiníció; csak egy automatikus oszlop lehet, és kulcsként kell definiálni, ha a forráskiszolgáló egy auto_increment oszlopot ad hozzá egyedi kulcsként. A kockázatcsökkentéshez futtassa a következő SQL-parancsot, állítsa be a "sql_generate_invisible_primary_key" értéket KI értékre, hagyja ki a replikációs hibát, és indítsa újra az adatreplikációs adatokat.

    alter table <table name> drop column my_row_id, modify <column name> int auto_increment;

  • Az adatreplikálás meghiúsul, ha a forráskiszolgáló olyan SQL-t futtat, amely nem támogatott, ha a "sql_generate_invisible_primary_key" be van kapcsolva. Hozzon létre például egy partíciótáblát. Ilyen esetben a kockázatcsökkentés a "sql_generate_invisible_primary_key" beállítás kikapcsolva értékre van állítva, és újraindítja az adatreplikációs adatokat.

Következő lépések

  • További információ az adatreplikálás beállításáról
  • További információ az Azure-beli replikálásról olvasási replikákkal