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

Evolutsioon ei seisa paigal, seetõttu muutuvad põhjused uuendada MySQL uusimatele versioonidele üha kaalukamaks. Hiljuti meie projektis tuli aeg uuendada mugavaid Percona Server 5.7 klastreid 8. versioonile. Kõik see toimus Ubuntu Linux 16.04 platvormil. Kuidas sellist operatsiooni teostada minimaalse seisakuga ja millega me kokku puutusime uuendamise käigus — loe sellest artiklist.

Ettevalmistus

Iga andmebaasi serveri uuendamine on tõenäoliselt seotud andmebaasi seadistamisega: muutustega süsteemivahendite piirangute nõuetes ja konfiguratsioonifailide parandamisega, mis tuleb puhastada aegunud direktiividest.

Enne uuendamist peame kindlasti tutvuma ametliku dokumentatsiooniga:

Ja koostame tegevuskava:

Parandada konfiguratsioonifailid, eemaldades aegunud direktiivid.
Kontrollime ühilduvust utiliitidega.
Uuendame slave andmebaasid, paigaldades paketi percona-server-server.
Uuendame meistri, paigaldades sama paketi.

Käime läbi iga tegevuskava punkti ja vaatame, mis võib valesti minna.

OLULINE! MySQL Galera klustri uuendamise protseduuril on omad nüansid, mida here artikel ei käsitle. Sellisel juhul ei tohiks seda juhendit kasutada.

Osa 1: Konfiguratsioonide kontroll

MySQL 8. versioonis eemaldati query_cache. Tegelikult peeti seda aegunud juba 5.7 versioonis, kuid nüüd on see täielikult eemaldatud. Seega tuleb eemaldada sellega seotud direktiivid. Küsimuste vahemälu jaoks võib kasutada nüüd väliseid tööriistu — näiteks ProxySQL.

Samuti leidsime konfiguratsioonist aegunud direktiive innodb_file_format. Kui MySQL 5.7-s oli võimalik valida InnoDB formaati, siis 8. versioon töötab ainult Barracuda formaadiga.

Meie lõpptulemus — 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 Server'i Docker-imaži. Serveri konfiguratsioon paigaldame katalooge mysql_config_test, ja loome kõrvale andmete ja logide kataloogid. Näide percona-serveri konfiguratsiooni testist:

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 logidesse või logide katalooge — sõltuvalt teie konfiguratsioonidest — ilmub fail, kus on kirjas probleemsed direktiivid.

Siin on, mis meil oli:

2020-04-03T12:44:19.670831Z 0 [Warning] [MY-011068] [Server] Süntaks 'expire-logs-days' on aegunud ja eemaldatakse tulevases väljaandes. Palun kasutage selle asemel binlog_expire_logs_seconds.
2020-04-03T12:44:19.671678Z 0 [Warning] [MY-013242] [Server] --character-set-server: 'utf8' on hetkel alias tähtedele UTF8MB3, kuid tulevases väljaandes on see alias UTF8MB4 jaoks. Palun kasutage UTF8MB4-d, et see oleks selge.
2020-04-03T12:44:19.671682Z 0 [Warning] [MY-013244] [Server] --collation-server: 'utf8_general_ci' on aegunud tähtede UTF8MB3 sortimine. Palun kasutage selle asemel UTF8MB4 koos sobiva sortimisega.

Nii olime sunnitud uurima ka kodeeringute üle ja asendama aegunud direktiivi expire-logs-days.

Järk 2: Töökindlate installatsioonide kontrollimine

Uuendamise dokumentatsioonis on 2 tööriista andmebaasi ühilduvuse kontrollimiseks. Nende kasutamine aitab administraatoril olemasolevate andmestruktuuride ühilduvust kontrollida.

Alustame klassikalisest tööriistast mysqlcheck. Piisab, kui käivitada:

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

Kui probleeme ei leita, lõppeb tööriist koodiga 0:

Lisaks on tänapäevastes MySQL versioonides saadaval tööriist mysql-shell (Percona puhul on see pakett percona-mysql-shell). See on asenduseks klassikalisele mysql kliendile ning ühendab endas kliendi, SQL koodi redaktori ja MySQL haldustööriistad. Serveri kontrollimiseks enne uuendamist saate selle kaudu täita 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, milliseid märkusi me saime:

Üldiselt ei ole midagi kriitilist — ainult hoiatused kodeeringutest (vt allpool). Üldine täitmise tulemus:

Otsustasime, et uuendus peaks minema probleemideta.

Eelneva hoiatused, mis viitavad kodeeringute probleemidele. Asi on selles, et UTF-8 MySQL-is ei olnud hiljuti tõeline "UTF-8", kuna salvestas vaid 3 baiti neljast. MySQL 8-s on see lõpuks otsustatud parandada: alias utf8 peagi suunatakse kodeeringule utf8mb4, ja vanad veerud tabelites muutuvad utf8mb3. Tulevikus kodeering utf8mb3 eemaldatakse, kuid mitte käesolevas väljaandes. Seetõttu otsustasime kodeeringud juba töötava andmebaasi järel, pärast selle uuendamist, parandada.

Järk 3: Serverite uuendamine

Mida võiks valesti minna, kui meil on nii suurepärane plaan?.. Täiesti arusaadav, et nüansid juhtuvad alati, seega viisime esimese katse läbi MySQL dev-klusteris.

Nagu juba mainitud, ametlik dokumentatsioon katab MySQL-serverite värskendamise küsimuse replikatega. Põhimõte on järgmine: kõigepealt tuleks värskendada kõik replikad (slave), kuna MySQL 8 suudab replikeerida 5.7 versiooni masterist. Teatud keerukus seisneb selles, et meil on kasutusel režiim master master, kus kaugarvuti on read-only. See tähendab, et tegelik liiklus suundub ühte andmekeskusesse ja teine on varukoopia.

Topoloogia on järgmine:

Värskendamine peaks algama replikatest mysql replica dc 2, mysql master dc 2 ja mysql replica dc 1, ja lõppema - mysql master dc 1 serveriga. Suurema usaldusväärsuse tagamiseks peatame virtuaalmasinad, teeme nende snapshotid ja vahetult enne värskendamist peatame replikatsiooni käsuga STOP SLAVE. Muul juhul tundub värskendamine olevat järgmine:

Iga replikate käivitame uuesti, lisades konfiguratsioonidesse 3 valikut: skip-networking, skip-slave-start, skip-log-bin. Asi on selles, et andmebaasi värskendamine genereerib binaarlogid süsteemide tabelite värskendamisel. Need direktiivid tagavad, et andmebaasis ei toimu rakenduse andmete muutmist, ja binaarlogidesse ei satu süsteemide tabelite värskendamise kohta teavet. See aitab vältida probleeme replikatsiooni taastamisel.
Paigaldame paketi percona-server-server. Oluline on märkida, et MySQL 8 versioonis ei tuleb käivitada käsk mysqlupgrade peale serveri värskendamist.
Pärast edukat käivitamist käivitame serveri veel kord - juba ilma esimeses punktis lisatud parameetriteta.
Veendume, et replikatsioon töötab edukalt: kontrollime SHOW SLAVE STATUS ja vaatame, et rakenduse andmebaasis uuendatakse tabelite kasutusloendeid.

See kõik tundub piisavalt lihtne: dev värskendamine läks edukalt. Okei, võime rahulikult planeerida öist värskendamist productionile.

Mingeid probleeme ei olnud - prod värskendasime

Kuid dev-lt production-le edasiviiv kogemus ei möödunud üllatusteta.

Õnneks algab värskendamisprotsess replikatest, seega, kui tõrgetega kokku puutusime, peatasime tööd ja taastastasime repliika snapshotist. Probleemide uurimine viidi järgmisel hommikul edasi. Logides leidsime järgmised kirjed:

2020-01-14T21:43:21.500563Z 2 [ERROR] [MY-012069] [InnoDB] tabel: t1 on 19 veergu, kuid InnoDB sõnastikus on 20 veergu
2020-01-14T21:43:21.500722Z 2 [ERROR] [MY-010767] [Server] Viga SE andmete parandamisel 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] Peatamine

Erinevate meililisti arhiivide uurimine Google'is viis arusaamiseni, et see probleem tekib MySQL veast. Kuigi pigem on see isegi utiliitide viga mysqlcheck ja mysqlsh.

Selgub, et MySQL on muutnud andmete esitamise viisi kümnendikute aluste (int, tinyint jne) jaoks, seega kasutatakse mysql-serveris nende salvestamiseks muud meetodit. Kui teie andmebaas oli algselt versioonis 5.5 või 5.1 ja seejärel uuendati versioonini 5.7, siis võib olla, et peate teostama OPTIMIZE mõnede tabelitega. Siis uuendab MySQL andmefailid, viies need uuemasse salvestusformaati.

Seda saab kontrollida ka 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 on 0, siis tabelis kasutatakse vana tüüpi — tuleb teha OPTIMIZE. Kuid kui väärtus on 246 — Teil on juba uus tüüp. Tüüpidega saab tutvuda koodis.

Lisaks sellele, et selles veas kaalutakse teist võimalikku põhjust, mis jäi meid kõrvale — see on InnoDB tabelite puudumine süsteemitabelis INNODB_SYS_TABLESPACES, kui need tabelid loodi versioonis 5.1. Uuendamise probleemide vältimiseks saab kasutada lisatud SQL-skripti.

Miks meil ei tekkinud selliseid probleeme dev'is? Andmebaasi kopeeritakse sinna pidevalt tootmisest — seega tabeleid luuakse ümber.

Kahjuks ei saa tegelikult töötava suure andmebaasiga lihtsalt võtta ja teha ulatuslikku OPTIMIZE. Siin aitab percona-toolkit: online OPTIMIZE'i toiminguks sobib suurepäraselt utiliit pt-online-schema-change.

Uuendatud plaan sai selliseks:

Teha optimeerimine kõikide tabelite jaoks.
Teha andmebaaside uuendamine.

Selle kontrollimiseks ning samal ajal uuendamise aega välja selgitamiseks, lülitasime välja ühe koopiatest ja kõigi tabelite jaoks käivitasime 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

Tabelite uuendamine toimub ilma püsivate lukustusteta, kuna utiliit loob uue ajutise tabeli, kuhu kopeerib andmed põhietabelist. Hetkel, mil mõlemad tabelid on sarnased, lukustatakse algne tabel ja asendatakse uuendatuga. Meie testkäivitus näitas, et kõikide tabelite uuendamiseks on vaja umbes ööpäeva, kuid samal ajal põhjustas andmete kopeerimine liiga suurt koormust ketastele.

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

Pärast optimeerimise lõpetamist läks uuendus edukalt läbi.

… kuid mitte lõpuni!

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

Ehkki ekraanipildil on näha hambuline graafik, tulenes see sellest, et osa MySQL-serveri vooge kukkus perioodiliselt tõrgete tõttu. Rakenduses ilmusid vead:

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

Kiire ülevaatus logidest paljastas, et mysqld teenus ei suutnud operatsioonisüsteemilt vajalikke ressursse hankida. Tõrketeateid uurides avastasime süsteemis "hooldamata" apparmor'i poliitika failid:

# 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 uuendati MySQL 5.7 versioonile ning kuuluvad kustutatud 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 tegevus, võib viia ootamatute probleemideni. Ja isegi hästi läbi mõeldud plaan ei taga alati oodatud tulemust. Nüüd sisaldab meie meeskonna igas uuendamisplaanis ka kohustuslikud üleliigsete failide puhastamine, mis võivad olla tekkinud viimaste tegevuste tulemusena.

Selle mitte väga professionaalse graafilise loominguga tahaksin öelda suurt aitäh ettevõttele Percona nende suurepäraste toodete eest!