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

MySQL helyszíni migrálása az Azure Database for MySQL-be: Értékelés

A MySQL-adatbázisok helyszíni környezetekből az Azure Database for MySQL-be való migrálásának értékelése kritikus fontosságú első lépés a zökkenőmentes és sikeres átállás biztosításához. Ez a cikk részletesen megvizsgálja az értékelési fázisban érintett főbb tényezőket és szempontokat. A szervezet céljaihoz igazodó megalapozott döntéseket hozhat a jelenlegi infrastruktúra kiértékelésével, a lehetséges kihívások azonosításával és az Azure felügyelt adatbázis-szolgáltatásainak előnyeinek megismerésével. Akár a teljesítmény javítására, a méretezhetőség javítására, akár a működési költségek csökkentésére törekszik, ez az útmutató a migrálási stratégia hatékony megtervezéséhez és végrehajtásához szükséges elemzéseket nyújtja.

Előfeltételek

Helyszíni MySQL migrálása az Azure Database for MySQL-be: Reprezentatív használati eset

Áttekintés

Mielőtt belevág egy MySQL-számítási feladat migrálásába, kellő gondossággal kell eljárni. Ez magában foglalja az adatok elemzését, az üzemeltetési környezetet és az alkalmazás számítási feladatait az Azure-beli célzóna megfelelő konfigurálásához és a hamarosan migrálható számítási feladatok üzemeltetéséhez való előkészítéséhez.

Korlátozások

Az Azure Database for MySQL a MySQL közösségi kiadás teljes körűen támogatott verziója, amely szolgáltatásként platformként fut. Az első értékelés során azonban van néhány korlátozás , amellyel megismerkedhet.

A legfontosabbak a következők:

  • A tárolómotor támogatása InnoDB és Memory csak

  • Korlátozott Privilege támogatás (DBA, SUPER, DEFINER)

  • Letiltott adatkezelési utasítások (SELECT ... INTO OUTFILE, LOAD DATA INFILE)

  • Automatikus jelentős adatbázis-migrálás (5.6–5.7, 5.7–8.0)

  • A MySQL Server felhasználó által definiált függvények (UDF-k) használatakor az egyetlen működőképes üzemeltetési lehetőség az Azure-ban üzemeltetett virtuális gépek, mivel nem lehet feltölteni az összetevőt az so dll Azure Database for MySQL-be.

Számos egyéb elem olyan üzemeltetési szempontok, amelyeket a rendszergazdáknak ismernie kell az operatív adatok számítási feladatainak életciklus-kezelésének részeként. Ez az útmutató a Migrálás utáni kezelés szakasz számos működési aspektusát ismerteti.

MySQL-verziók

A MySQL 1995-től kezdve gazdag előzményei vannak. Azóta széles körben használt adatbázis-kezelő rendszer lett belőle. Az Azure Database for MySQL a MySQL 5.6-os verziójának támogatásával indult, és az 5.7-es és a közelmúltban a 8.0-s verzióra vált. Az Azure Database for MySQL legújabb verziójának támogatásához tekintse meg a Támogatott Azure Database for MySQL-kiszolgálóverziókat. A Migrálás utáni kezelés szakaszban áttekintjük, hogyan történik a frissítések (például az 5.7.20-as és az 5.7.21-es verzió) alkalmazása az Azure-beli MySQL-példányokra.

Feljegyzés

Az 5.x-ről a 8.0-ra ugrás nagyrészt a MySQL Oracle-felvásárlásának köszönhető. A MySQL-előzményekről a MySQL wikilapján olvashat bővebben.

A forrás MySQL-verzió ismerete elengedhetetlen. A rendszert használó alkalmazások az adott verzióra jellemző adatbázis-objektumokat és funkciókat használhatják. Az adatbázisok alacsonyabb verzióra való migrálása kompatibilitási problémákat és funkcióvesztést okozhat. Azt is javasoljuk, hogy az adatokat és az alkalmazáspéldányt alaposan tesztelje, mielőtt újabb verzióra migrálna, mivel a bevezetett funkciók megszakíthatják az alkalmazást.

Példák az áttelepítési útvonalra és a verzióra:

  • 5.6: TIMESTAMP oszlop az ezredmásodpercek és a teljes szöveges keresés megfelelő tárolásához

  • 5.7: Natív JSON-adattípus támogatása

  • 8.0: NoSQL-dokumentumtár, atomi és összeomlásbiztos DDL- és JSON-táblafüggvények támogatása

    Feljegyzés

    A MySQL 5.6 2021 februárjában elveszíti az általános támogatást. A MySQL számítási feladatainak az 5.7-es vagy újabb MySQL-verzióra kell migrálniuk.

A MySQL-kiszolgáló verziójának ellenőrzése:

SHOW VARIABLES LIKE "%version%";

Adatbázis-tárolómotorok

Az Azure Database for MySQL csak az InnoDB- és memóriaadatbázis-tárolómotorokat támogatja. Más tárolómotorokat, például a MyISAM-et, egy támogatott tárolómotorba kell migrálni. A MyISAM és az InnoDB közötti különbségek az üzemeltetési funkciók és a teljesítménykimenet. A magasabb szintű táblák és sémastruktúra általában nem változik a motorok között, de az index és a tábla oszloptípusai tárolási és teljesítménybeli okokból változhatnak. Bár az InnoDB-ről ismert, hogy nagy adatfájlméretekkel rendelkezik, ezeket a tárolási adatokat az Azure Database for MySQL szolgáltatás kezeli.

Migrálás a MyISAM-ről az InnoDB-be

A MyISAM-adatbázist és a táblákat InnoDB-táblákká kell konvertálni. Az átalakítás után az alkalmazásokat tesztelni kell a kompatibilitás és a teljesítmény szempontjából. A legtöbb esetben a teszteléshez újra kell adni a táblát, és DDL-utasításokon keresztül módosítani kell a céltároló motort. Nem valószínű, hogy ezt a módosítást a migrálás során kell végrehajtani, mivel az az Azure-cél séma létrehozása során következik be. További részletekért tekintse át a konvertáló táblák fejlesztőinek dokumentációját a MySQL webhelyén.

A táblázat hasznos információinak megkereséséhez használja ezt a lekérdezést:

    SELECT
        tab.table_schema,
        tab.table_name,
        tab.engine as engine_type,
        tab.auto_increment,
        tab.table_rows,
        tab.create_time,
        tab.update_time,
        tco.constraint_type
    FROM information_schema.tables tab
    LEFT JOIN information_schema.table_constraints tco
        ON (tab.table_schema = tco.table_schema
            AND tab.table_name = tco.table_name
            )
    WHERE
        tab.table_schema NOT IN ('mysql', 'information_schema', 'performance_
schema', 'sys')
        AND tab.table_type = 'BASE TABLE';

Feljegyzés

Ha több adatbázison futtat lekérdezést INFORMATION_SCHEMA, az hatással lehet a teljesítményre. Futtatás alacsony használati időszakokban.

Ha egy táblát a MyISAM-ből InnoDB-vé szeretne konvertálni, futtassa a következőket:

ALTER TABLE {table\_name} ENGINE=InnoDB;

Feljegyzés

Ez a konverziós módszer zárolja a táblát, és minden alkalmazás megvárhatja a művelet befejezését. A táblazárolás miatt az adatbázis rövid ideig offline állapotban jelenik meg.

Ehelyett a tábla létrehozható ugyanazzal a szerkezettel, de egy másik tárolómotorral. A létrehozás után másolja a sorokat az új táblába:

INSERT INTO {table\_name} SELECT * FROM {myisam\_table} ORDER BY {primary\_key\_columns}

Feljegyzés

Ahhoz, hogy ez a módszer sikeres legyen, az eredeti táblát törölni kell, majd át kell nevezni az új táblát. Ez a tevékenység rövid állásidőt okoz.

Adatbázisadatok és objektumok

Az adatok az adatbázis-migrálás egyik összetevője. Az adatbázist támogató objektumokat migrálni és ellenőrizni kell, hogy az alkalmazások továbbra is megbízhatóan fussanak.

Az alábbi lista az áttelepítés előtt és után leltárba vegye az elemeket:

  • Táblák (séma)

  • Elsődleges kulcsok, idegen kulcsok

  • Indexek

  • Függvények

  • Eljárások

  • Triggerek

  • Megjelenítések

Felhasználó által definiált függvények

A MySQL lehetővé teszi a külső kódot hívó függvények használatát. Sajnos a felhasználó által definiált függvényeket (UDF-eket) külső kóddal használó adatterhelések nem migrálhatók az Azure Database for MySQL-be. Ennek az az oka, hogy a szükséges MySQL-függvény háttérrendszere vagy dll-kódja nem tölthető fel az Azure-kiszolgálóra.

Futtassa a következő lekérdezést a telepített UDF-ek megkereséséhez:

SELECT * FROM mysql.func;

Forrásrendszerek

A migrálás előkészítése a forrásrendszertől és a helyétől függően változhat. Az adatbázis-objektumokon kívül fontolja meg, hogyan szerezheti be az adatokat a forrásrendszerből a célrendszerbe. Az adatok migrálása kihívást jelenthet, ha a tűzfalak és más hálózati összetevők a forrás és a cél között vannak.

Emellett az adatok interneten keresztüli áthelyezése lassabb is lehet, mint dedikált kapcsolatcsoportok használata az Azure-ba. Ezért ha sok gigabájtot, terabájtot és petabájtnyi adatot helyez át, érdemes lehet ExpressRoute-kapcsolatot beállítani a forráshálózat és az Azure-hálózat között.

Ha az ExpressRoute már létezik, valószínű, hogy más alkalmazások is használják a kapcsolatot. Ha egy meglévő útvonalon végez migrálást, az megterhelheti a hálózati átviteli sebességet, és jelentős teljesítménycsökkenést okozhat mind a migrálás, mind a hálózatot használó egyéb alkalmazások esetében.

Végül a lemezterületet ki kell értékelni. Nagy adatbázis exportálásakor vegye figyelembe az adatok méretét. Győződjön meg arról, hogy a rendszer, ahol az eszköz fut, és végső soron az exportálási hely elegendő lemezterülettel rendelkezik az exportálási művelet végrehajtásához.

Felhőszolgáltatók

Az adatbázisok felhőszolgáltatókból, például az Amazon Web Servicesből (AWS) való migrálása további hálózati konfigurációs lépést igényelhet a felhőben üzemeltetett MySQL-példányok eléréséhez. A migrálási eszközökhöz, például a Data Migration Serviceshez, külső IP-tartományból kell hozzáférést kérni, és más módon blokkolva lehet.

Helyszíni

A felhőszolgáltatókhoz hasonlóan, ha a MySQL-adatterhelés tűzfalak vagy más hálózati biztonsági rétegek mögött található, létre kell hozni egy útvonalat a helyszíni példány és az Azure Database for MySQL között.

Eszközök

A MySQL-adatterhelések és -környezetek értékeléséhez számos eszköz és módszer használható. Minden eszköz különböző értékelési és migrálási funkciókat és funkciókat biztosít. Az útmutató részeként áttekintjük a MySQL-adatterhelések értékeléséhez leggyakrabban használt eszközöket.

Az Azure migrálása

Bár az Azure Migrate nem támogatja közvetlenül a MySQL-adatbázis számítási feladatainak migrálását, akkor is használható, ha a rendszergazdák nem tudják, hogy a felhasználók és alkalmazások milyen adatokat használnak fel, akár virtuális, akár hardveralapú gépen vannak tárolva. A függőségelemzés úgy végezhető el, hogy telepíti és futtatja a monitorozási ügynököt a MySQL-számítási feladatot futtató gépen. Az ügynök egy megadott időszakban, például egy hónapban gyűjti az adatokat. A függőségi adatok elemezhetők az adatbázissal létesített ismeretlen kapcsolatok megkereséséhez. A kapcsolati adatok segíthetnek azonosítani azokat az alkalmazástulajdonosokat, amelyeket értesíteni kell a függőben lévő migrálásról.

Az alkalmazások és a felhasználói kapcsolati adatok függőségelemzése mellett az Azure Migrate a Hyper-V, a VMware vagy a fizikai kiszolgálók elemzésére is használható, hogy kihasználtsági mintákat biztosítson az adatbázis számítási feladataihoz, hogy a megfelelő célkörnyezetet javasolhassa.

Telgraf Linuxhoz

A Linux-számítási feladatok a Microsoft Monitoring Agent (MMA) használatával gyűjthetnek adatokat a virtuális és fizikai gépeken. Emellett fontolja meg a Telegraf-ügynök és a beépülő modulok széles skálájának használatát a teljesítménymetrikák gyűjtéséhez.

Szolgáltatásszintek

Az értékelési adatokkal (CPU, memória, tárolás stb.) ellátott migrálási felhasználó következő választása, hogy eldöntse, melyik Azure Database for MySQL tarifacsomagot érdemes használnia.

Jelenleg három szint létezik:

  • Alapszintű: Könnyű számítási és I/O-teljesítményt igénylő számítási feladatok.

  • Általános célú: A legtöbb olyan üzleti számítási feladat, amely kiegyensúlyozott számítást és memóriát igényel skálázható I/O-átviteli sebességgel.

  • Memóriaoptimalizált: Nagy teljesítményű adatbázis-számítási feladatok, amelyek memórián belüli teljesítményt igényelnek a gyorsabb tranzakciófeldolgozáshoz és a nagyobb egyidejűséghez.

A rétegdöntést az adatterhelés RTO- és RPO-követelményei befolyásolhatják. Ha az adatterhelés több mint 4 TB tárterületet igényel, további lépésre van szükség. Tekintse át és válassza ki azt a régiót, amely legfeljebb 16 TB tárterületet támogat .

A döntéshozatal általában a tárolásra és az IOPS-ra, illetve a másodpercenkénti bemeneti/kimeneti műveletekre összpontosít. Így a célrendszernek mindig legalább annyi tárhelyre van szüksége, mint a forrásrendszerben. Emellett mivel az IOPS 3/GB-os, fontos, hogy megfeleljen az IOPS-eknek a végső tárolóméretnek.

Tényezők Szint
Basic Fejlesztőgép, nincs szükség nagy teljesítményre 1 TB-nál kisebb tárterülettel.
Általános célú Az IOPS-nak többre van szüksége, mint amennyit az alapszint biztosít, de a 16 TB-nál kisebb tárhelyhez és a 4 GB-nál kevesebb memóriához.
Memóriaoptimalizált Nagy memóriát vagy nagy gyorsítótárat és pufferrel kapcsolatos kiszolgálókonfigurációt használó adatterhelések, például magas egyidejűségi innodb_buffer_pool_instances, nagy BLOB-méretek, sok replikációs példányt tartalmazó rendszerek.

Költségek

A WWI a teljes WWI MySQL-adatterhelés kiértékelése után megállapította, hogy legalább 4 virtuális magra és 20 GB memóriára és legalább 100 GB tárterületre lesz szükségük 450 IOPS-kapacitással. A 450 IOPS-követelmény miatt legalább 150 GB tárterületet kell lefoglalniuk az Azure Database for MySQL IOPP-foglalási módszer miatt. Emellett a kiépített kiszolgáló tárterületének legalább 100%-át biztonsági mentési tárként és egy olvasási replikaként kell használniuk. Nem számítanak 5 GB-nál nagyobb kimenő kimenő forgalomra.

Az Azure Database for MySQL díjszabási kalkulátorával a WWI meg tudta határozni az Azure Database for MySQL-példány költségeit. 2020. 09. 09-étől a teljes tulajdonosi költség (TCO) megjelenik a WWI konferenciaadatbázis alábbi táblázatában.

Erőforrás Leírás Mennyiség Költség
Számítás (általános célú) 4 virtuális mag, 20 GB 1 @ 0,351 USD/óra $3074.76 / yr
Tárolás 5 GB 12 x 150 @ 0,115 $ $207 / yr
Biztonsági mentés A kiépített tároló legfeljebb 100%-a A kiépített kiszolgálói tárterület 100%-ig nem jár többletköltséggel $0.00 / yr
Replika olvasása 1 másodperces régióreplika számítás + tárolás $3281.76 / yr
Hálózat < 5 GB/hó kimenő forgalom Ingyenes
Teljes $6563.52 / yr

A kezdeti költségek áttekintése után a WWI CIO-ja megerősítette, hogy három évnél hosszabb ideig vannak az Azure-ban. Úgy döntöttek, hogy 3 éves tartalékpéldányokat használnak további ~4K/yr megtakarításhoz.

Erőforrás Leírás Mennyiség Költség
Számítás (általános célú) 4 virtuális mag 1 @ 0,1375 USD/óra $1204.5 / yr
Tárolás 5 GB 12 x 150 @ 0,115 $ $207 / yr
Biztonsági mentés A kiépített tároló legfeljebb 100%-a A kiépített kiszolgálói tárterület 100%-ig nem jár többletköltséggel $0.00 / yr
Hálózat < 5 GB/hó kimenő forgalom Ingyenes
Replika olvasása 1 másodperces régióreplika számítás + tárolás $1411.5 / yr
Teljes $2,823 / yr

Ahogy a fenti táblázat is mutatja, a biztonsági mentéseket, a hálózati kimenő forgalmat és az olvasási replikákat a teljes tulajdonosi költség (TCO) figyelembe kell venni. Mivel több adatbázist adnak hozzá, a létrehozott tároló- és hálózati forgalom lenne az egyetlen további költségalapú tényező, amelyet figyelembe kell venni.

Feljegyzés

A fenti becslések nem tartalmazzák az alkalmazásrétegek ExpressRoute-, Azure-alkalmazás-átjáró-, Azure Load Balancer- vagy App Service-költségeit.

A fenti díjszabás bármikor változhat, és régiótól függően változhat.

Alkalmazásokkal kapcsolatos következmények

Az Azure Database for MySQL-be való áttéréskor a szoftvercsatornák rétege (SSL) alapú kommunikációvá alakítása valószínűleg az alkalmazások egyik legjelentősebb változása. Az SSL alapértelmezés szerint engedélyezve van az Azure Database for MySQL-ben, és valószínű, hogy a helyszíni alkalmazás és az adatterhelés nincs beállítva a MySQL-hez való SSL-csatlakozáshoz. Ha engedélyezve van, az SSL-használat többletterhelést ad a feldolgozáshoz, ezért figyelni kell.

Feljegyzés

Bár az SSL alapértelmezés szerint engedélyezve van, letilthatja azt.

Kövesse az alkalmazás SSL-kapcsolatának konfigurálására vonatkozó tevékenységeit , hogy biztonságosan csatlakozzon az Azure Database for MySQL-hez az alkalmazás újrakonfigurálásához, hogy támogassa ezt az erős hitelesítési útvonalat.

Végül módosítsa a kiszolgáló nevét az alkalmazás kapcsolati sztring, vagy váltson a DNS-re, hogy az új Azure Database for MySQL-kiszolgálóra mutasson.

WWI-forgatókönyv

A WWI úgy kezdte meg az értékelést, hogy információkat gyűjt a MySQL-adattulajdonról, ahogy az az alábbi táblázatban is látható.

Név Forrás Db-motor Méret IOPS Verzió Tulajdonos Leállás
WwwDB AWS (PaaS) InnoDB 1 GB 150 5.7 Marketing osztály 1 óra
BlogDB AWS (PaaS) InnoDB 1 GB 100 5.7 Marketing osztály 4 óra
ConferenceDB Helyszíni InnoDB 5 GB 50 5,5 Értékesítési részleg 4 óra
CustomerDB Helyszíni InnoDB 10 GB 75 5,5 Értékesítési részleg 2 óra
SalesDB Helyszíni InnoDB 20 GB 75 5,5 Értékesítési részleg 1 óra

Minden adatbázis-tulajdonossal felvette a kapcsolatot az elfogadható állásidő meghatározásához. A kiválasztott tervezési és migrálási módszer az adatbázis elfogadható állásidején alapult.

Az első fázisban a WWI kizárólag a ConferenceDB-adatbázisra összpontosított. A csapatnak szüksége volt a migrálási felületre az adatterhelések migrálásához. A ConferenceDB-adatbázist az egyszerű adatbázis-struktúra és a nagy elfogadható állásidő miatt választották ki. Az adatbázis migrálása után a csapat az alkalmazás biztonságos Azure-célzónába való migrálására összpontosított.

Értékelési ellenőrzőlista

  • Tesztelje a számítási feladat sikeres futtatását a célrendszeren.

  • Győződjön meg arról, hogy a megfelelő hálózati összetevők vannak a migráláshoz.

  • Az adatterhelési erőforrás követelményeinek megismerése.

  • A teljes költség becslése.

  • Ismerje meg az állásidőre vonatkozó követelményeket.

  • Készüljön fel az alkalmazás módosítására.

Következő lépés

MySQL helyszíni migrálása az Azure Database for MySQL-be: Tervezés