🥇MySQL (Percona Server) uuendamine 5.7-lt 8.0-le

Edasiminek ei seisa paigal, seega muutuvad põhjused MySQLi uusimate versioonide värskendamiseks üha põhjendatumaks. Hiljuti tuli ühes meie projektis aeg uuendada mugavaid Percona Server 5.7 klastreid versioonile 8. Kõik see toimus Ubuntu Linux 16.04 platvormil. Kuidas sellist operatsiooni teostada minimaalsete seisakutega ja milliste probleemidega me uuendamise käigus silmitsi seisime — lugesite sellest artiklist.

Ettevalmistus

Igasugune andmebaasiserveri värskendamine on tõenäoliselt seotud andmebaasi seadistamisega: süsteemivõimsuse piirangute nõuete muutmise ja konfigureerimise korrigeerimisega, mida tuleb vananenud juhistest puhastada.

Enne värskendamist pöördume kindlasti ametlikku dokumentatsiooni:

Ja koostame tegevusplaani:

Parandame konfiguratsioonifailid, eemaldades vananenud juhised.
Kontrollime ühilduvust utiliitide abil.
Värskendame slave-andmebaasid, installides paketi percona-server-server.
Värskendame meistri, paigaldades sama paketi.

Läbime iga plaani punkti ja vaatame, mis võib valesti minna.

OLULINE! MySQL Galera klastrite uuendamise protsessil on oma keerukused, mida artiklis ei käsitleta. Seetõttu ei tohiks seda juhendit niisugustes olukordades kasutada.

1. osa: Konfiguratsioonide kontrollimine

MySQL 8. versioonis eemaldati query_cache. Tegelikult oli see tunnustatud vananenuks juba versioonis 5.7, kuid nüüd on see täiesti eemaldatud. Seetõttu tuleb eemaldada seotud direktiivid. Küsimuste vahemälu jaoks on nüüd võimalik kasutada välist tööriista — näiteks ProxySQL.

Samuti leiti konfiguratsioonist vananenud direktiivid innodb_file_format. Kui MySQL 5.7-s oli võimalik valida InnoDB formaati, siis 8. versioon töötab nüüd ainult Barracuda formaadiga.

Meie järeldus on järgmiste direktiivide eemaldamine:

query_cache_type, query_cache_limit ja query_cache_size;
innodb_file_format ja innodb_file_format_max.

Kontrollimiseks kasutame Percona Serveri Docker pildi. Serveri konfiguratsiooni paneme kausta mysql_config_test, ja loomeme kõrval kaustad andmete ja logide jaoks. Percona-serveri konfiguratsiooni testimise 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

Kokkuvõtteks: kas Docker'i logides või logide kataloogis — olenevalt teie konfiguratsioonidest — ilmub fail, kus kirjeldatakse probleemseid direktiive.

Siin on, mis meil oli:

2020-04-03T12:44:19.670831Z 0 [Warning] [MY-011068] [Server] Süntaks 'expire-logs-days' on vananenud ja eemaldatakse tulevasest versioonist. Palun kasutage selle asemel 'binlog_expire_logs_seconds'.
2020-04-03T12:44:19.671678Z 0 [Warning] [MY-013242] [Server] --character-set-server: 'utf8' on praegu alias tähemärgikomplektile UTF8MB3, kuid tulevases versioonis on see alias UTF8MB4-le. Palun kaaluge UTF8MB4 kasutamist, et olla ühemõtteline.
2020-04-03T12:44:19.671682Z 0 [Warning] [MY-013244] [Server] --collation-server: 'utf8_general_ci' on vananenud tähemärgikomplekti UTF8MB3 collatsioon. Palun kaaluge UTF8MB4 kasutamist sobiva collatsiooniga.

Nii et meil oli vaja veel tegeleda kodeeringutega ja asendada vananenud direktiiv. expire-logs-days.

Osa 2: Töötegevuste kontrollimine

Uuendamise dokumentatsioonis on kaks utiliiti, mis aitavad andmebaasi ühilduvust kontrollida. Nende kasutamine aitab administraatoril kontrollida olemasoleva andmestruktuuri ühilduvust.

Alustame klassikalisest utiliidist mysqlcheck. Piisab, kui käivitada:

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

Kui probleeme ei leitud, lõpetab utiliit koodiga 0:

Lisaks on nüüdisaegsetes MySQL versioonides saadaval utiliit, mysql-shell (Percona puhul on see paket percona-mysql-shell). See on klassikalise mysql kliendi asendaja, mis ühendab endas mysql kliendi, SQL-koodi redaktori ja haldustööriistad. Serveri kontrollimiseks enne uuendamist saab selle kaudu käivitada järgmise käsu:

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

Ja siin on märkused, mille me saime:

Üldiselt mitte midagi kriitilist — ainult hoiatused kodeeringute kohta (vt allpool). Üldine tulemused:

Oleme otsustanud, et uuendamine peaks kulgema probleemideta.

Märkused ülaltoodud hoiatuste kohta viitavad kodeeringu probleemidele. Asi on selles, et UTF-8 MySQL-is ei olnud hiljuti „päris“ UTF-8, kuna see salvestas vaid 3 baiti 4 asemel. MySQL 8-s on see lõpuks otsustatud parandada: alias utf8 varsti viib kodeeringule utf8mb4, ja vanad veerud tabelites muutuvad utf8mb3. Tulevikus eemaldatakse kodeering utf8mb3 aga mitte selles väljaandes. Seetõttu otsustasime parandada kodeeringud juba töötavas andmebaasi installeerimises pärast selle uuendamist.

Osa 3: Serverite uuendamine

Mis võib siis valesti minna, kui on olemas nii luksuslik plaan? Meie esimene katse toimus dev-klusteris MySQL, arvestades, et nüansid on alati olemas.

Nagu juba mainitud, ametlik dokumentatsioon karjub MySQL-serverite värskendamise küsimuse üle, kus on replikatsioonid. Oluline on see, et kõigepealt tuleks värskendada kõik replikad (slave), kuna MySQL 8 oskab replitseeruda versioonist 5.7. Mõningane keerukus seisneb selles, et meil on kasutusel režiim master master, kus eemal asuv meister on režiimis read-only. See tähendab, et tegelik liiklus siseneb ühte andmekeskusesse, teine on varuplaan.

Topoloogia näeb välja järgmine:

Värskendus peaks algama replikatest mysql replica dc 2, mysql master dc 2 ja mysql replica dc 1, ja lõppema peab mysql master dc 1 serveriga. Täiendava usaldusväärsuse tagamiseks peatusime virtuaalmasinad, tegime neist snapshotid ja enne värskenduse algust peatasime replikatsiooni käsuga STOP SLAVE. Muus osas näeb värskendus välja järgmiselt:

Iga replikat taaskäivitame, lisades konfiguratsioonidesse kolm valikut: skip-networking, skip-networking, skip-slave-startskip-log-bin
Installime paketi percona-server-server. Oluline on märkida, et MySQL 8 versioonis ei on vajalik käivitada käsk mysqlupgrade serveri uuendamise järel.
Pärast edukat käivitamist käivitame serveri veel kord — nüüd juba ilma esimeses punktis lisatud parameetriteta.
Veendume, et replikatsioon töötab edukalt: kontrollime SHOW SLAVE STATUS ja vaatame, et rakenduse andmebaasis uuendatakse tabelid, mis sisaldavad loendureid.

Kõik see tundub piisavalt lihtne: dev värskendus läks edukalt. Okei, nüüd saab rahulikult planeerida öö värskendust production'ile.

Ei olnud muresid — prod oleme värskendanud

Kuid dev'ist eduka kogemuse üleviimine production'ile ei möödunud ilma üllatusteta.

Õnneks algab värskendamise protsess replikatelt, seega kohtades raskustes peatasime tööd ja taastasime repliika snapshot'ist. Probleemide uurimine lükkus järgmisse hommikusse. Logides leiti järgmised kirjed:

2020-01-14T21:43:21.500563Z 2 [ERROR] [MY-012069] [InnoDB] tabel: t1-l on 19 veergu, kuid InnoDB sõnastikus on 20 veergu
2020-01-14T21:43:21.500722Z 2 [ERROR] [MY-010767] [Server] Vigane SE andmete parandamine db1.t1 jaoks
2020-01-14T21:43:24.208365Z 0 [ERROR] [MY-010022] [Server] DD tabelite täitmine ebaõnnestus.
2020-01-14T21:43:24.208658Z 0 [ERROR] [MY-010119] [Server] Katkestamine

Erinevate postituste arhiivide uurimine Googles tõi meele, et selline probleem tekib MySQL vea. Kuigi tõenäolisemalt on see lausa teenuse mysqlcheck ja mysqlsh.

Selgub, et MySQL on muutnud andmete esitamise meetodit kümnendkohtade (int, tinyint jne) jaoks, seega kasutatakse mysql-serveris nende salvestamiseks teistsugust meetodit. Kui teie andmebaas oli algselt versioonis 5.5 või 5.1 ja siis uuendati see versioonile 5.7, siis võib osutuda vajalikuks OPTIMIZE mõnede tabelite jaoks. Siis uuendab MySQL failid andmetega, muutes need kaasaegseks salvestusvorminguks.

Seda saab kontrollida utiliidiga mysqlfrm:

mysqlfrm --diagnostic -vv /var/lib/mysql/db/table.frm
...
 'field_length': 8,
  'field_type': 246, # välja formaat
  'field_type_name': 'decimal',
  'flags': 3,
  'flags_extra': 67,
  'interval_nr': 0,
 'name': 'you_deciaml_column',
...

Kui field_type kui teil on 0, siis laual kasutatakse vana tüüpi — tuleb teha OPTIMIZE. Kuid kui väärtus on 246 — teil on juba uus tüüp. Tüüpide kohta saab rohkem teada koodis.

Lisaks sellele selles veaparanduses kaalutakse teist võimalikku põhjust, mis meid kõrvale jättis — InnoDB-tabelite puudumine süsteemitabelis INNODB_SYS_TABLESPACES, kui need tabelid loodi versioonis 5.1. Uuendamiseks probleemide vältimiseks võib kasutada kaasaegset SQL-skripti.

Kuid miks ei tekkinud meil selliseid probleeme dev-is? Andmebaas kopeeritakse sinna perioodiliselt tootmisest — seega tabelid luuakse ümber.

Kahjuks ei saa töötavas suuremas andmebaasis lihtsalt võtta ja teostada laialdast OPTIMIZE. Siin aitab percona-toolkit: online OPTIMIZE operatsiooni jaoks sobib suurepäraselt tööriist pt-online-schema-change.

Uuendatud plaan sai selliseks:

Teha kõigi tabelite optimeerimine.
Teha andmebaaside värskendamine.

Kuna kontrollisime ja tahtsime selgitada värskendamise aega, keelatasime ühe repliigi ning käivitasime järgmise käsu kõigi tabelite jaoks:

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

Tabelite värskendamine toimub ilma pikaajaliste blokeeringuteta, kuna utiliit loob uue ajutise tabeli, kuhu kopeeritakse andmed põhitaabelist. Kui mõlemad tabelid on identsed, blokeeritakse algne tabel ja asendatakse uuega. Meie testkäivitamine näitas, et kõikide tabelite värskendamiseks on vajalik umbes üks päev, kuid andmete kopeerimine põhjustas liiga suurt koormust kettale.

Selle vältimiseks lisasime produktsioonis käsule argumendi --sleep väärtusega 10 — see parameeter reguleerib ooteaega pärast andmepaki viimist uude tabelisse. Nii saab koormust vähendada, kui jahutusprotsessi ajal on rakendus ajakavade suhtes nõudlik.

Pärast optimeerimise tegemist läks värskendus edukalt läbi.

… kuid mitte lõpuni!

Juba poole tunni pärast pärast värskendust tuli klient probleemiga. Andmebaas töötas väga kummaliselt: perioodiliselt tekkisid ühenduste katkestamised. Nii see jälgimine välja nägi:

Screenerilt on näha hambulise graafiku, mis on seotud sellega, et osa MySQL-serveri vooge kukkusid perioodiliselt vea tõttu. Rakenduses ilmusid vead:

[PDOException] SQLSTATE[HY000] [2002] Ühendus keeldus

Kiire ülevaatus logidest näitas, et mysqld deemon ei saanud operatsioonisüsteemilt vajalikku ressursse. Vead lahendades avastasime süsteemis «hülgatud» apparmor poliitikafaile:

# 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 tekkisid paar aastat tagasi, kui värskendati MySQL 5.7 ja kuuluvad eemalduvale paketile. Failide kustutamine ja apparmor 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õtteks

Iga, isegi kõige lihtsam operatsioon, võib põhjustada ootamatuid probleeme. Ja isegi hästi läbimõeldud plaan ei garanteeri alati oodatud tulemust. Nüüd sisaldab meie meeskonna iga värskendamise plaan kindlasti ka kohustuslikku üleliigsete failide puhastamist, mis on võinud tekkida viimaste tegevuste tulemusena.

Ma sooviksin väga tänada ettevõtet Percona nende suurepäraste toodete eest selle mitte eriti professionaalse graafilise loomingu kaudu!