🥇MySQL-i (Percona Server) värskendamine 5.7-lt 8.0-le

Edusammud ei seisa paigal, nii et põhjused MySQL-i uusimatele versioonidele üleminekuks muutuvad üha kaalukamaks. Mitte kaua aega tagasi oli ühes meie projektis aeg värskendada hubaseid Percona Server 5.7 klastreid versioonile 8. Kõik see juhtus Ubuntu Linux 16.04 platvormil. Kuidas sellist toimingut minimaalse seisakuga läbi viia ja millised probleemid värskenduse käigus ilmnesid - lugege sellest artiklist.

Koolitus

Andmebaasiserveri igasugune värskendus on tõenäoliselt seotud andmebaasi ümberseadistamisega: süsteemiressursside piirangute nõuete muudatustega ja andmebaasi konfiguratsioonide parandamisega, mis tuleb aegunud direktiividest puhastada.

Enne värskendamist viitame kindlasti ametlikule dokumentatsioonile:

Ja koostame tegevuskava:

Parandage konfiguratsioonifailid, eemaldades aegunud direktiivid.
Kontrollige ühilduvust utiliitidega.
Värskendage alamandmebaase, installides paketi percona-server-server.
Värskendage kaptenit sama paketiga.

Vaatame iga plaani punkti ja vaatame, mis võib valesti minna.

TÄHTIS! Galeral põhineva MySQL-klastri värskendamise protseduuril on oma nüansid, mida artiklis ei kirjeldata. Sel juhul ei tohiks te seda juhendit kasutada.

1. osa: konfiguratsioonide kontrollimine

MySQL eemaldati versioonis 8 query_cache. Tegelikult ta oli kuulutati aegunuks tagasi versioonis 5.7, kuid nüüd täielikult kustutatud. Sellest tulenevalt on vaja sellega seotud direktiivid eemaldada. Ja taotluste vahemällu salvestamiseks saate nüüd kasutada väliseid tööriistu, näiteks ProxySQL.

Ka konfiguratsioonis olid aegunud juhised selle kohta innodb_file_format. Kui MySQL 5.7-s oli võimalik valida InnoDB vorming, siis töötab juba 8. versioon ainult Barracuda formaadis.

Meie tulemuseks on järgmised direktiivid:

query_cache_type, query_cache_limit и query_cache_size;
innodb_file_format и innodb_file_format_max.

Kontrollimiseks kasutame Percona Serveri Dockeri pilti. Asetame serveri konfiguratsiooni kataloogi mysql_config_test, ja selle kõrvale loome andmete ja logide kataloogid. Percona serveri konfiguratsiooni testi näide:

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

Alumine rida: kas Dockeri logides või logide kataloogis - olenevalt teie seadistustest - ilmub fail, milles kirjeldatakse probleemseid juhiseid.

Siin on see, mis meil oli:

2020-04-03T12:44:19.670831Z 0 [Warning] [MY-011068] [Server] The syntax 'expire-logs-days' is deprecated and will be removed in a future release. Please use binlog_expire_logs_seconds instead.
2020-04-03T12:44:19.671678Z 0 [Warning] [MY-013242] [Server] --character-set-server: 'utf8' is currently an alias for the character set UTF8MB3, but will be an alias for UTF8MB4 in a future release. Please consider using UTF8MB4 in order to be unambiguous.
2020-04-03T12:44:19.671682Z 0 [Warning] [MY-013244] [Server] --collation-server: 'utf8_general_ci' is a collation of the deprecated character set UTF8MB3. Please consider using UTF8MB4 with an appropriate collation instead.

Seega pidime ikkagi kodeeringud välja selgitama ja aegunud direktiivi asendama expire-logs-days.

Osa 2: Töötavate paigaldiste kontrollimine

Värskenduse dokumentatsioon sisaldab 2 utiliiti andmebaasi ühilduvuse kontrollimiseks. Nende kasutamine aitab administraatoril kontrollida olemasoleva andmestruktuuri ühilduvust.

Alustame klassikalise mysqlchecki utiliidiga. Lihtsalt jookse:

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

Kui probleeme ei leita, väljub utiliit koodiga 0:

Lisaks on MySQL-i kaasaegsetes versioonides saadaval utiliit mysql-shell (Percona puhul on see pakett percona-mysql-shell). See on klassikalise mysql-kliendi asendus ja ühendab endas kliendi, SQL-koodiredaktori ja MySQL-i haldustööriistade funktsioonid. Serveri kontrollimiseks enne värskendamist saate selle kaudu käivitada järgmised käsud:

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

Siin on meile saadud kommentaarid:

Üldiselt ei midagi kriitilist - ainult hoiatused kodeeringute kohta (vt allpool). Üldine teostuse tulemus:

Otsustasime, et värskendus peaks kulgema probleemideta.

Märkus ülaltoodud hoiatuste kohta, mis viitavad probleemidele kodeeringus. Fakt on see, et UTF-8 MySQL-is kuni viimase ajani ei olnud "tõene" UTF-8, kuna see salvestas 3 asemel ainult 4 baiti. MySQL 8-s on see lõpuks otsustas selle parandada: teise nimega utf8 viib peagi kodeerimiseni utf8mb4, ja tabelite vanad veerud muutuvad utf8mb3. Edasine kodeerimine utf8mb3 eemaldatakse, kuid mitte selles versioonis. Seetõttu otsustasime pärast selle värskendamist parandada juba töötava DBMS-i installi kodeeringud.

3. osa: Serveri värskendused

Mis võib valesti minna, kui on nii tark plaan?.. Mõistes hästi, et nüansse tuleb alati ette, tegime esimese katse MySQL-i arendajaklastriga.

Nagu juba mainitud, ametlik dokumentatsioon hõlmab MySQL-i serverite koopiatega värskendamise probleemi. Põhimõte on see, et peaksite esmalt värskendama kõiki koopiaid (alluvaid), kuna MySQL 8 suudab replikeerida põhiversioonist 5.7. Mõned raskused seisnevad selles, et kasutame režiimi kapten <-> peremees, kui kaugjuhtimispult on režiimis ainult lugemiseks. See tähendab, et tegelikult läheb lahinguliiklus ühte andmekeskusesse ja teine on varukeskus.

Topoloogia näeb välja selline:

Värskendus peab algama koopiatega mysql replica dc 2, mysql master dc 2 и mysql replica dc 1, ja lõpetage serveriga mysql master dc 1. Usaldusväärsemaks muutmiseks peatasime virtuaalsed masinad, tegime neist hetktõmmised ja vahetult enne värskendust peatasime replikatsiooni käsuga STOP SLAVE. Ülejäänud värskendus näeb välja selline:

Taaskäivitame iga koopia, lisades konfiguratsioonidele 3 valikut: skip-networking, skip-slave-start, skip-log-bin. Fakt on see, et andmebaasi värskendamine loob binaarlogid koos süsteemitabelite värskendustega. Need direktiivid tagavad, et andmebaasis olevad rakenduse andmed ei muutu ja binaarlogidesse ei lisata teavet süsteemitabelite värskendamise kohta. See väldib probleeme replikatsiooni jätkamisel.
Paketi paigaldamine percona-server-server. Oluline on märkida, et MySQL-i versioonis 8 ei peate käsu käivitama mysqlupgrade pärast serveri värskendamist.
Pärast edukat käivitamist taaskäivitame serveri uuesti – ilma esimeses lõigus lisatud parameetriteta.
Veendume, et replikatsioon töötab edukalt: kontrollige SHOW SLAVE STATUS ja vaata, et rakenduste andmebaasi loenduritega tabeleid uuendatakse.

Kõik tundub üsna lihtne: arendaja värskendus õnnestus. Ok, saate ohutult ajastada igaõhtuse värskenduse tootmiseks.

Kurbust polnud – uuendasime prod

Eduka arenduskogemuse ülekandmine tootmisse ei olnud aga üllatusteta.

Õnneks algab värskendusprotsess ise koopiatega, nii et kui meil tekkisid raskused, peatasime töö ja taastasime koopia hetktõmmisest. Probleemide uurimine lükati järgmise päeva hommikusse. Logid sisaldasid järgmisi kirjeid:

2020-01-14T21:43:21.500563Z 2 [ERROR] [MY-012069] [InnoDB] table: t1 has 19 columns but InnoDB dictionary has 20 columns
2020-01-14T21:43:21.500722Z 2 [ERROR] [MY-010767] [Server] Error in fixing SE data for db1.t1
2020-01-14T21:43:24.208365Z 0 [ERROR] [MY-010022] [Server] Failed to Populate DD tables.
2020-01-14T21:43:24.208658Z 0 [ERROR] [MY-010119] [Server] Aborting

Google'is erinevate meililistide arhiive uurides jõuti arusaamisele, et see probleem tuleneb MySQL-i viga. Kuigi see on tõenäolisemalt utiliidi viga mysqlcheck и mysqlsh.

Selgub, et MySQL muutis kümnendväljade (int, tinyint jne) andmete esitamise viisi, nii et mysql-server kasutab nende salvestamiseks teistsugust viisi. Kui teie andmebaas esialgu oli versioonis 5.5 või 5.1 ja seejärel värskendasite versioonile 5.7, siis peate võib-olla tegema OPTIMIZE mõne laua jaoks. Seejärel värskendab MySQL andmefaile, teisaldades need praegusesse salvestusvormingusse.

Saate seda kontrollida ka utiliidiga mysqlfrm:

mysqlfrm --diagnostic -vv /var/lib/mysql/db/table.frm
...
 'field_length': 8,
  'field_type': 246, # формат поля
  'field_type_name': 'decimal',
  'flags': 3,
  'flags_extra': 67,
  'interval_nr': 0,
 'name': 'you_deciaml_column',
...

kui field_type Kui teil on see 0, siis kasutatakse tabelis vana tüüpi - peate läbi viima OPTIMIZE. Kui aga väärtus on 246, on teil juba uus tüüp. Lisateavet tüüpide kohta leiate aadressilt kood.

Veelgi enam, aastal see viga Kaalume teist võimalikku põhjust, mis meist mööda läks: InnoDB tabelite puudumine süsteemitabelis INNODB_SYS_TABLESPACES, kui need, tabelid, loodi versioonis 5.1. Probleemide vältimiseks värskendamisel võite kasutada lisatud SQL-skript.

Miks meil arendajaga selliseid probleeme ei olnud? Andmebaas kopeeritakse sinna perioodiliselt tootmisest – seega tabelid luuakse uuesti.

Kahjuks ei saa te tõeliselt töötavas suures andmebaasis universaalset lihtsalt võtta ja käivitada OPTIMIZE. Percona-toolkit aitab siin: pt-online-schema-change utiliit sobib suurepäraselt võrguoperatsiooniks OPTIMISEERIMINE.

Uuendatud plaan nägi välja selline:

Optimeerige kõik tabelid.
Uuenda andmebaase.

Selle kontrollimiseks ja samal ajal värskendusaja väljaselgitamiseks keelasime ühe koopiatest ja käivitasime kõigi tabelite jaoks järgmise käsu:

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

Tabeleid värskendatakse ilma pikkade lukkudeta, kuna utiliit loob uue ajutise tabeli, kuhu kopeerib põhitabelist andmed. Hetkel, kui mõlemad lauad on identsed, lukustatakse algne laud ja asendatakse uuega. Meie puhul näitas testtöö, et kõigi tabelite uuendamine võtab aega umbes päev, kuid andmete kopeerimine põhjustas ketastele liigse koormuse.

Selle vältimiseks lisasime tootmises käsule argumendi --sleep väärtusega 10 - see parameeter reguleerib oote pikkust pärast andmepartii uude tabelisse ülekandmist. Nii saate koormust vähendada, kui tegelikult töötav rakendus nõuab reageerimisaega.

Pärast optimeerimist oli värskendamine edukas.

... aga mitte täielikult!

Poole tunni jooksul pärast värskendust tekkis kliendil probleem. Andmebaas töötas väga kummaliselt: perioodiliselt hakkasid nad käima ühendus lähtestab. Nii nägi see välja jälgimisel:

Ekraanitõmmis näitab saehamba graafikut, kuna mõned MySQL-i serveri lõimed jooksid perioodiliselt kokku veaga. Rakenduses ilmnesid vead:

[PDOException] SQLSTATE[HY000] [2002] Connection refused

Kiirel logide kontrollimisel selgus, et mysqld deemon ei saanud operatsioonisüsteemist vajalikke ressursse. Vigu sorteerides avastasime süsteemis "orb" apparmor poliitikafailid:

# 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

Need failid loodi paar aastat tagasi MySQL 5.7 versioonile üleminekul ja kuuluvad eemaldatud paketti. Failide kustutamine ja apparmori teenuse taaskäivitamine lahendas probleemi:

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

Kokkuvõttes

Iga, isegi kõige lihtsam toiming, võib põhjustada ootamatuid probleeme. Ja isegi läbimõeldud plaan ei taga alati oodatud tulemust. Nüüd on meie meeskonna kõik värskendusplaanid hõlmanud ka mittevajalike failide kohustuslikku puhastamist, mis võisid ilmuda hiljutiste toimingute tulemusena.

Ja selle mitte eriti professionaalse graafilise loovusega tahaksin öelda Perconale suurepärast tänu nende suurepäraste toodete eest!

PS

Loe ka meie blogist:

Allikas: www.habr.com

MySQL-i (Percona Server) värskendamine 5.7-lt 8.0-le