🥇MySQL (Percona Server) frissítése 5.7-ről 8.0-ra

A fejlődés nem áll meg, ezért egyre indokoltabb, hogy frissítsünk a legújabb MySQL verziókra. Nemrégiben egyik projektünkben elérkezett az idő, hogy frissítsük a Percona Server 5.7 kényelmes klasztereket a 8-as verzióra. Mindez az Ubuntu Linux 16.04 platformon zajlott. Hogyan hajthattuk végre ezt a műveletet minimális leállással, és milyen problémákkal találkoztunk a frissítés során — erről olvashat ebben a cikkben.

Előkészületek

Bármely adatbázis-szerver frissítése valószínűleg az adatbázis újrakonfigurálásával jár: a rendszer erőforrásokra vonatkozó igények változása és a konfigurációs fájlok, amelyekből el kell távolítani a elavult utasításokat.

A frissítés előtt mindenképpen hivatkozni fogunk a hivatalos dokumentációra:

És elkészítjük a cselekvési tervet:

Javítsuk a konfigurációs fájlokat, távolítsuk el az elavult utasításokat.
Ellenőrizzük a kompatibilitást az eszközökkel.
Frissítsük a slave adatbázisokat a következő csomag telepítésével percona-server-server.
Frissítsük a mestert, telepítve ugyanazt a csomagot.

Vizsgáljuk meg a terv minden egyes pontját, és nézzük meg, hogy mi mehet rosszul.

FONTOS! A Galera alapú MySQL klaszter frissítési eljárása saját sajátosságokkal bír, amelyek nincsenek részletezve a cikkben. Ebben az esetben ne használja ezt az útmutatót.

1. rész: A konfigurációk ellenőrzése

A MySQL 8-as verziójában eltávolították a query_cache-t. Valójában ezt már elavultnak nyilvánították az 5.7-es verzióban, de most már teljesen eltávolították. Ennek megfelelően el kell távolítani a hozzá kapcsolódó utasításokat. Mostantól a lekérdezések cache-eléséhez külső eszközök használata ajánlott — például, ProxySQL.

A konfigurációban elavult utasítások találhatóak a innodb_file_format-ról is. Míg a MySQL 5.7-ben lehetőség volt az InnoDB formátumának kiválasztására, a 8-as verzió már csak a Barracuda formátummal működik.

A végső összegzés — a következő utasítások eltávolítása:

query_cache_type, query_cache_limit és query_cache_size;
innodb_file_format és innodb_file_format_max.

A teszteléshez használjunk Percona Server Docker képet. A szerver konfigurációját elhelyezzük a mysql_config_testkönyvtárba, és mellette létrehozunk könyvtárakat az adatoknak és a naplóknak. Példa a percona-server konfigurációjának tesztelésére:

mkdir -p {mysql_config_test,mysql_data,mysql_logs}
cp -r /etc/mysql/conf.d/* mysql_config_test/
docker run --name some-percona -v $(pwd)/mysql_config_test:/etc/my.cnf.d/ -v $(pwd)/mysql_data/:/var/lib/mysql/ -v $(pwd)/mysql_logs/:/var/log/mysql/ -e MYSQL_ROOT_PASSWORD=${MYSQL_PASSWORD} -d percona:8-centos

A végén: vagy a Docker naplókban, vagy a naplókkal foglalkozó könyvtárban — attól függően, hogy milyen konfigurációt használ — meg fog jelenni egy fájl, amelyben a problémás utasítások lesznek leírva.

Ez történt nálunk:

2020-04-03T12:44:19.670831Z 0 [Figyelmeztetés] [MY-011068] [Szerver] Az 'expire-logs-days' szintaxis elavult és egy jövőbeli kiadásban eltávolításra kerül. Kérjük, a binlog_expire_logs_seconds használatát kérem.
2020-04-03T12:44:19.671678Z 0 [Figyelmeztetés] [MY-013242] [Szerver] --character-set-server: 'utf8' jelenleg az UTF8MB3 karakterkészlet aliasa, de egy jövőbeli kiadásban az UTF8MB4 aliasa lesz. Kérjük, fontolja meg az UTF8MB4 használatát a félreértések elkerülése érdekében.
2020-04-03T12:44:19.671682Z 0 [Figyelmeztetés] [MY-013244] [Szerver] --collation-server: 'utf8_general_ci' elavult UTF8MB3 karakterkészlet kollációja. Kérjük, fontolja meg az UTF8MB4 megfelelő kollációval való használatát.

Így nekünk is foglalkoznunk kellett a karakterkódolásokkal és az elavult utasítás kicserélésével. expire-logs-days.

2. rész: Működő telepítések ellenőrzése

A frissítési dokumentációban van 2 segédeszköz az adatbázis kompatibilitásának ellenőrzésére. Ezek használata segít az adminisztrátornak ellenőrizni az adatstruktúra kompatibilitását.

Kezdjük a klasszikus mysqlcheck segédeszközzel. Elég egyszerűen elindítani:

mysqlcheck -u root -p --all-databases --check-upgrade

Ha nem található probléma, az eszköz 0-ás kóddal fejeződik be:

Ezen kívül a modern MySQL verziókban elérhető az eszköz mysql-shell (Percona esetén ez a csomag percona-mysql-shell). Ez helyettesíti a klasszikus mysql kliens programot, és ötvözi a kliens, SQL-kód szerkesztő és MySQL adminisztrációs eszköz funkcióit. A frissítés előtti szerver ellenőrzéséhez az alábbi parancsot hajthatja végre rajta:

mysqlsh -- util check-for-server-upgrade { --user=root --host=1.1.1.1 --port=3306 } --config-path=\/etc\/mysql\/my.cnf

És ezek voltak a megjegyzések, amelyeket kaptunk:

Összességében semmi kritikus — csak figyelmeztetések a karakterkódolásokkal kapcsolatban. (see below)A végrehajtás összesített eredménye:

Úgy döntöttünk, hogy a frissítés problémák nélkül fog végbemenni.

A fenti figyelmeztetések a karakterkódolásokkal kapcsolatos problémákról tanúskodnak. Az a helyzet, hogy az UTF-8 a MySQL-ben nem volt "valódi" UTF-8 egészen nemrégig. csupán 3 bájtot tárolt 4 helyett. A MySQL 8 végre eztmegoldotta: az 'utf8' aliashamarosan a következő kódolásra fog vezetni: utf8mb4 , míg a régi oszlopok a táblázatokban utf8mb3-ra változnak. A jövőben a kódolás eltávolításra kerül, de nem ebben a kiadásban. Ezért úgy döntöttünk, hogy már a működő adatbázis telepítésén javítunk a frissítése után.3. rész: A szerverek frissítése eltávolításra kerül, de nem ebben a kiadásban. Ezért úgy döntöttünk, hogy már a működő adatbázis telepítésén javítunk a frissítése után. eltávolításra kerül, de nem ebben a kiadásban. Ezért úgy döntöttünk, hogy a kódolásokat már a működő adatbázis-telepítésünkön javítjuk, a frissítés után.

3. rész: A szerverek frissítése

Mi történhet rosszul, amikor egy ilyen lenyűgöző tervünk van?.. Teljesen tisztában voltunk azzal, hogy mindig vannak apró részletek, így az első kísérletünket a MySQL dev klaszteren végeztük.

Ahogy már említettük, az hivatalos dokumentáció foglalkozik a MySQL szerverek replikákkal való frissítésének kérdésével. A lényeg az, hogy először minden replikát (slave) érdemes frissíteni, mivel a MySQL 8 képes replikálni a 5.7-es verziójú mesterből. Néhány nehézség adódik abból, hogy nálunk mester <-> mesterüzemmódban működik, amikor a távoli mester read-only módban van. Ez azt jelenti, hogy a tényleges forgalom egy adatközpontba érkezik, a második pedig tartalék.. Tehát a tényleges éles forgalom egy adatközpontba érkezik, míg a második tartalék.

A topológia a következőképpen néz ki:

A frissítésnek a replikákkal kell kezdődnie mysql replica dc 2, mysql master dc 2 és mysql replica dc 1, és a mysql master dc 1 szerverrel kell végződnie. A még nagyobb megbízhatóság érdekében leállítottuk a virtuális gépeket, készítettünk róluk pillanatképeket, és közvetlenül a frissítés előtt leállítottuk a replikációt a következő paranccsal: STOP SLAVE. A frissítés egyébként így néz ki:

Mindegyik replikát újraindítjuk, és hozzáadunk a konfigurációkhoz 3 opciót: skip-networking, skip-slave-start, skip-log-bin. Az a helyzet, hogy a frissítés során a rendszer táblák frissítése szintén bináris naplókat generál. Ezek a direktívák garantálják, hogy az adatbázisban nem változik meg az alkalmazás adata, és a bináris naplókba nem kerülnek be a rendszer táblák frissítésének adatai. Ez lehetővé teszi a replikáció folytatását problémák nélkül.
Telepítjük a csomagot percona-server-server. Fontos megemlíteni, hogy a MySQL 8 verzióban nem az mysqlupgrade parancsot a szerver frissítése után kell futtatni. A sikeres indítás után még egyszer újraindítjuk a szervert – már az első pontban hozzáadott paraméterek nélkül.
Győződjünk meg arról, hogy a replikáció sikeresen működik: ellenőrizzük a
SHOW SLAVE STATUS parancsot, és nézzük meg, hogy az alkalmazás adatbázisában a táblák frissülnek-e a számlálókkal. Mindez elég egyszerűnek tűnik: a dev frissítése sikeresen megtörtént. Rendben, nyugodtan tervezhetjük az éjszakai frissítést a produkcós környezetre.

Nem volt szomorúság – a prod-t frissítettük

Azonban a dev sikeres tapasztalatának átvitele a produkcióra nem ment végbe meglepetések nélkül.

Szerencsére maga a frissítési folyamat a replikákkal kezdődik, így amikor nehézségekbe ütköztünk, leállítottuk a munkát, és helyreállítottuk a replikát a pillanatképből. A problémák vizsgálatát a következő reggelre halasztottuk. A naplókban a következő bejegyzések voltak:

Szerencsére a frissítési folyamat a replikákkal kezdődik, így miután néhány nehézségbe ütköztünk, leállítottuk a munkát és helyreállítottuk a replikát a pillanatképből. A problémák vizsgálatát a következő reggelre halasztottuk. A naplókban a következő bejegyzéseket találtuk:

2020-01-14T21:43:21.500563Z 2 [ERROR] [MY-012069] [InnoDB] A t1 táblának 19 oszlopa van, de az InnoDB szótárban 20 oszlop található.
2020-01-14T21:43:21.500722Z 2 [ERROR] [MY-010767] [Server] Hiba az SE adatok javítása közben a db1.t1 esetében.
2020-01-14T21:43:24.208365Z 0 [ERROR] [MY-010022] [Server] A DD táblák feltöltése sikertelen.
2020-01-14T21:43:24.208658Z 0 [ERROR] [MY-010119] [Server] Megszakítás.

A különböző levelezési archívumok kutatása a Google-ben azt mutatta, hogy ez a probléma abból fakad, hogy MySQL hibája. Bár valójában inkább a mysqlcheck és mysqlsh.

kiderült, hogy a MySQL megváltoztatta az adatok ábrázolásának módját a tizedes mezők (int, tinyint stb.) esetében, így a mysql-server belsejében más módon tárolják őket. Ha az adatbázisa eredetileg az 5.5-ös vagy 5.1-es verzióban volt, majd frissítette 5.7-re, akkor lehet, hogy szükség van Így érkeznek az első metrikák. És ezek bizonyos helyet foglalnak el. A következő események változhatnak számos tényezőtől függően: egyes táblák esetében. Ekkor a MySQL frissíti az adatfájlokat, átállítva azokat az aktuális tárolási formátumra.

Ezt a mysqlfrm segédprogrammal is ellenőrizheti. mysqlfrm --diagnostic -vv /var/lib/mysql/db/table.frm ... 'field_length': 8, 'field_type': 246, # mező formátum 'field_type_name': 'decimal', 'flags': 3, 'flags_extra': 67, 'interval_nr': 0, 'name': 'you_deciaml_column', ...:

field_type

Ha ha 0-át mutat, akkor a táblában a régi típus szerepel — azt ki kell cserélni. . Ha azonban 246-ot mutat — akkor már új típusú. A típusokkal részletesebben megismerkedhet a Így érkeznek az első metrikák. És ezek bizonyos helyet foglalnak el. A következő események változhatnak számos tényezőtől függően:Továbbá, ebben kód.

a hibában már egy másik lehetséges ok is szerepel, amely elkerülte a figyelmünket — ez az InnoDB táblák hiánya a rendszer táblában INNODB_SYS_TABLESPACES , ha ezek a táblák 5.1-es verzióban lettek létrehozva. A frissítési problémák elkerüléséhez használhatjaa mellékelt SQL szkriptet. Miért nem tapasztaltunk ilyen problémákat a dev-en? Az adatbázis rendszeresen másolódik a productionra — így a.

táblák újjáépülnek. Sajnos egy valóban működő nagy adatbázison nem lehet csak úgy végrehajtani egy általános.

. Ehhez a percona-toolkit segít: az online OPTIMIZE művelethez kiválóan megfelel a pt-online-schema-change segédprogram. Így érkeznek az első metrikák. És ezek bizonyos helyet foglalnak el. A következő események változhatnak számos tényezőtől függően:A frissített terv a következőképpen alakult:

Hozzuk létre az összes tábla optimalizálását.

Frissítsük az adatbázisokat.
A terv ellenőrzésére és a frissítés időtartamának megismerésére leállítottuk az egyik replikát, és az összes táblához a következő parancsot futtattuk:

pt-online-schema-change --critical-load Threads_running=150 --alter "ENGINE=InnoDB" --execute --chunk-size 100 --quiet --alter-foreign-keys-method auto h=127.0.0.1,u=root,p=${MYSQL_PASSWORD},D=db1,t=t1

pt-online-schema-change --critical-load Threads_running=150 --alter "ENGINE=InnoDB" --execute --chunk-size 100 --quiet --alter-foreign-keys-method auto h=127.0.0.1,u=root,p=${MYSQL_PASSWORD},D=db1,t=t1

A táblák frissítése hosszú blokkolások nélkül történik, mivel az eszköz új ideiglenes táblát hoz létre, amelybe átmásolja az adatokat az alap táblából. Amikor mindkét tábla azonos, az alap tábla blokkolásra kerül, és helyére az új kerül. Tesztünk során azt mutatta, hogy minden tábla frissítése körülbelül egy napot vesz igénybe, de közben az adatok másolása túl nagy terhelést jelentett a lemezeken.

Ennek elkerülése érdekében a production környezetben hozzáadtuk a parancshoz az alábbi argumentumot: --sleep értékkel 10 — ez a paraméter szabályozza az új táblába történő adatcsomag átvitele utáni várakozási időt. Így csökkenthető a terhelés, ha a valóban futó alkalmazás érzékeny a válaszidőre.

Az optimalizálás befejezése után a frissítés sikeresen megtörtént.

… de nem teljesen!

Már fél órával a frissítés után a kliens problémával keresett meg. Az adatbázis nagyon furcsán működött: időnként kapcsolati megszakítások. Így nézett ki a megfigyelés során:

A képernyőképen látható egy fogazott grafikon, ami annak tudható be, hogy a MySQL szerver egyes szálai időnként hibával estek ki. Az alkalmazásban hibák jelentkeztek:

[PDOException] SQLSTATE[HY000] [2002] Kapcsolat megtagadva

A naplók gyors áttekintése feltárta, hogy a mysqld démon nem tudta megszerezni a szükséges erőforrásokat az operációs rendszertől. A hibák vizsgálata során felfedeztük a rendszerben a tárolatlan apparmor politikai fájlokat.:

# dpkg -S /etc/apparmor.d/cache/usr.sbin.mysqld
dpkg-query: no path found matching pattern /etc/apparmor.d/cache/usr.sbin.mysqld
# dpkg -S /etc/apparmor.d/local/usr.sbin.mysqld
dpkg-query: no path found matching pattern /etc/apparmor.d/local/usr.sbin.mysqld
# dpkg -S /etc/apparmor.d/usr.sbin.mysqld
mysql-server-5.7: /etc/apparmor.d/usr.sbin.mysqld
# dpkg -l mysql-server-5.7
rc  mysql-server-5.7 5.7.23-0ubuntu0.16.04.1      amd64

Ezek a fájlok két évvel ezelőtt, a MySQL 5.7-re történő frissítéskor alakultak ki, és egy távoli csomaghoz tartoznak. A fájlok törlése és az apparmor szolgáltatás újraindítása megoldotta a problémát:

systemctl stop apparmor
rm /etc/apparmor.d/cache/usr.sbin.mysqld
rm /etc/apparmor.d/local/usr.sbin.mysqld
rm /etc/apparmor.d/usr.sbin.mysqld
systemctl start apparmor

Végül

Bármi, még a legegyszerűbb művelet is váratlan problémákhoz vezethet. Még a gondosan kidolgozott terv sem garantálja mindig a várt eredményt. Most minden frissítési tervbe csapatunk számára kötelezően beletartozik a felesleges fájlok takarítása is, amelyek a legutóbbi tevékenységek következtében jöhettek létre.

Ezen nem túl professzionális grafikai alkotásért szeretnék köszönetet mondani a Percona cégnek a kiváló termékeikért!

P.S.

Olvasson további információkat a blogunkban:

Forrás: habr.com