Uppfærir MySQL (Percona Server) úr 5.7 í 8.0

Framfarir standa ekki í stað, þannig að ástæður þess að uppfæra í nýjustu útgáfur af MySQL verða sífellt sannfærandi. Ekki alls fyrir löngu, í einu af verkefnum okkar, var kominn tími til að uppfæra notalegu Percona Server 5.7 klasana í útgáfu 8. Allt þetta gerðist á Ubuntu Linux 16.04 pallinum. Hvernig á að framkvæma slíka aðgerð með lágmarks niður í miðbæ og hvaða vandamál við lentum í við uppfærsluna - lestu í þessari grein.

Þjálfun

Sérhver uppfærsla á gagnagrunnsþjóninum tengist líklega endurstillingu gagnagrunns: breytingar á kröfum um takmarkanir á kerfisauðlindum og leiðréttingu á gagnagrunnsstillingum sem þarf að hreinsa úr úreltum tilskipunum.

Áður en við uppfærum munum við örugglega vísa í opinberu skjölin:

• MySQL 8 útgáfuskýringar;
• MySQL uppfærsluleiðbeiningar;
• Leiðbeiningar um Percona uppfærslu;
• MySQL leiðarvísir til að uppfæra eftirmyndir og meistara.

Og gerum aðgerðaáætlun:

1. Leiðréttu stillingarskrár með því að fjarlægja úreltar tilskipanir.
2. Athugaðu samhæfni við tól.
3. Uppfærðu þrælagagnagrunna með því að setja upp pakkann percona-server-server.
4. Uppfærðu meistarann ​​með sama pakka.

Skoðum hvern lið áætlunarinnar og sjáum hvað gæti farið úrskeiðis.

MIKILVÆGT! Aðferðin við að uppfæra MySQL þyrping byggt á Galera hefur sína eigin fínleika sem ekki er lýst í greininni. Þú ættir ekki að nota þessa leiðbeiningar í þessu tilfelli.

Part 1: Athugaðu stillingar

MySQL var fjarlægt í útgáfu 8 query_cache. Reyndar var hann það lýst úrelt aftur í útgáfu 5.7, en núna alveg eytt. Í samræmi við það er nauðsynlegt að fjarlægja tengdar tilskipanir. Og til að vista beiðnir geturðu nú notað ytri verkfæri - td, ProxySQL.

Einnig í stillingunni voru úreltar tilskipanir um innodb_file_format. Ef í MySQL 5.7 var hægt að velja InnoDB sniðið, þá virkar 8. útgáfan nú þegar aðeins með Barracuda sniði.

Niðurstaða okkar er að fjarlægja eftirfarandi tilskipanir:

• query_cache_type, query_cache_limit и query_cache_size;
• innodb_file_format и innodb_file_format_max.

Til að athuga munum við nota Docker myndina af Percona Server. Við munum setja stillingar netþjónsins í möppuna mysql_config_test, og við hliðina á því munum við búa til möppur fyrir gögn og logs. Percona-miðlara stillingarprófunardæmi:

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

Niðurstaða: annaðhvort í Docker logs eða í möppunni með logs - allt eftir stillingum þínum - mun birtast skrá þar sem erfiðum tilskipunum verður lýst.

Hér er það sem við áttum:

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.

Þannig þurftum við enn að finna út kóðunirnar og skipta um úrelta tilskipunina expire-logs-days.

Hluti 2: Athugun á virkum uppsetningum

Uppfærsluskjölin innihalda 2 tól til að athuga hvort gagnagrunnurinn sé samhæfður. Notkun þeirra hjálpar stjórnandanum að athuga samhæfni núverandi gagnaskipulags.

Byrjum á klassíska mysqlcheck tólinu. Einfaldlega keyra:

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

Ef engin vandamál finnast mun tólið hætta með kóðanum 0:

Að auki er tól í boði í nútíma útgáfum af MySQL mysql-skel (í tilfelli Percona er þetta pakkinn percona-mysql-shell). Það kemur í staðinn fyrir klassíska mysql biðlarann ​​og sameinar aðgerðir viðskiptavinar, SQL kóða ritstjóra og MySQL stjórnunarverkfæri. Til að athuga netþjóninn áður en þú uppfærir geturðu keyrt eftirfarandi skipanir í gegnum hann:

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

Hér eru athugasemdirnar sem við fengum:

Almennt ekkert mikilvægt - aðeins viðvaranir um kóðun (sjá fyrir neðan). Heildarframkvæmdarniðurstaða:

Við ákváðum að uppfærslan ætti að ganga án vandræða.

Athugasemd um viðvaranirnar hér að ofan sem gefa til kynna vandamál með kóðun. Staðreyndin er sú að UTF-8 í MySQL þar til nýlega var ekki "sönn" UTF-8, þar sem það geymdi aðeins 3 bæti í stað 4. Í MySQL 8 er þetta loksins ákvað að laga það: öðru nafni utf8 mun brátt leiða til kóðun utf8mb4, og gömlu dálkarnir í töflunum verða utf8mb3. Frekari kóðun utf8mb3 verður fjarlægt, en ekki í þessari útgáfu. Þess vegna ákváðum við að leiðrétta kóðun sem þegar er í gangi DBMS uppsetninguna, eftir að hafa uppfært hana.

Hluti 3: Uppfærslur á netþjóni

Hvað gæti farið úrskeiðis þegar það er svona snjöll áætlun? .. Með því að skilja að blæbrigði gerast alltaf, gerðum við fyrstu tilraunina á MySQL dev þyrping.

Eins og áður hefur komið fram, opinber skjöl fjallar um málið að uppfæra MySQL netþjóna með eftirlíkingum. Niðurstaðan er sú að þú ættir fyrst að uppfæra allar eftirmyndir (þræla), þar sem MySQL 8 getur endurtekið frá meistaraútgáfu 5.7. Sumir erfiðleikar liggja í þeirri staðreynd að við notum haminn meistari <-> meistari, þegar ytri meistarinn er í ham lesið aðeins. Það er í raun og veru að bardagaumferð fer í eina gagnaver og sú seinni er öryggisafrit.

Topology lítur svona út:

Uppfærslan verður að byrja á eftirlíkingum mysql eftirmynd dc 2, mysql master dc 2 и mysql replica dc 1, og enduðum með mysql master dc 1 þjóninum. Til að vera áreiðanlegri stöðvuðum við sýndarvélarnar, tókum skyndimyndir af þeim og strax áður en uppfærslan stöðvuðum endurgerð með skipuninni STOP SLAVE. Restin af uppfærslunni lítur svona út:

1. Við endurræsum hverja eftirmynd með því að bæta 3 valkostum við stillingarnar: skip-networking, skip-slave-start, skip-log-bin. Staðreyndin er sú að uppfærsla gagnagrunnsins býr til tvöfalda annála með uppfærslum á kerfistöflum. Þessar tilskipanir tryggja að engar breytingar verða á umsóknargögnum í gagnagrunninum og upplýsingar um uppfærslu á kerfistöflum verða ekki teknar með í tvíundarskránum. Þetta mun koma í veg fyrir vandamál þegar endurtekning er hafin.
2. Að setja upp pakkann percona-server-server. Það er mikilvægt að hafa í huga að í MySQL útgáfu 8 ekki þú þarft að keyra skipunina mysqlupgrade eftir uppfærslu miðlara.
3. Eftir vel heppnaða byrjun endurræsum við netþjóninn aftur - án breytu sem var bætt við í fyrstu málsgrein.
4. Við tryggjum að afritun virki með góðum árangri: athugaðu SHOW SLAVE STATUS og sjáðu að töflurnar með teljara í forritagagnagrunninum eru uppfærðar.

Þetta lítur allt frekar einfalt út: þróunaruppfærslan tókst. Allt í lagi, þú getur örugglega tímasett næturuppfærslu fyrir framleiðslu.

Það var engin sorg - við uppfærðum pród

Hins vegar kom flutningur á farsælli þróunarreynslu yfir í framleiðslu ekki á óvart.

Sem betur fer byrjar uppfærsluferlið sjálft með eftirlíkingum, þannig að þegar við lentum í erfiðleikum stöðvuðum við vinnuna og endurheimtum eftirmyndina úr skyndimyndinni. Rannsókn á vandamálunum var frestað til næsta morguns. Logarnir innihéldu eftirfarandi færslur:

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

Rannsókn á skjalasafni ýmissa póstlista á Google leiddi til þess skilnings að þetta vandamál á sér stað vegna MySQL galla. Þó að þetta sé líklegra tólagalla mysqlcheck и mysqlsh.

Það kemur í ljós að MySQL breytti því hvernig þau tákna gögn fyrir aukastafareiti (int, tinyint osfrv.), þannig að mysql-þjónninn notar aðra leið til að geyma þau. Ef gagnagrunnurinn þinn upphaflega var í útgáfu 5.5 eða 5.1, og síðan uppfærðir þú í 5.7, þá gætirðu þurft að gera OPTIMIZE fyrir sum borð. Þá mun MySQL uppfæra gagnaskrárnar og flytja þær yfir á núverandi geymslusnið.

Þú getur líka athugað þetta með tólinu 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',
...

Ef field_type Ef þú hefur það jafnt og 0, þá er gamla gerðin notuð í töflunni - þú þarft að framkvæma OPTIMIZE. Hins vegar, ef gildið er 246, ertu nú þegar með nýja gerð. Frekari upplýsingar um tegundirnar má finna í kóða.

Þar að auki, í þessi galli Við erum að íhuga aðra mögulega ástæðu, sem fór framhjá okkur: skortur á InnoDB töflum í kerfistöflunni INNODB_SYS_TABLESPACES, ef þær, töflur, voru búnar til í útgáfu 5.1. Til að forðast vandamál við uppfærslu geturðu notað meðfylgjandi SQL forskrift.

Af hverju áttum við ekki í slíkum vandamálum á dev? Gagnagrunnurinn er reglulega afritaður þangað úr framleiðslu - þannig, töflur eru endurgerðar.

Því miður, á virkilega virkum stórum gagnagrunni, muntu ekki geta bara tekið og framkvæmt alhliða OPTIMIZE. percona-toolkit mun hjálpa hér: pt-online-schema-change tólið er frábært fyrir OPTIMIZE aðgerðina á netinu.

Uppfærða áætlunin leit svona út:

1. Fínstilltu allar töflur.
2. Uppfærðu gagnagrunna.

Til að athuga það og á sama tíma finna út uppfærslutímann slökktum við eina af eftirlíkingunum og keyrðum eftirfarandi skipun fyrir allar töflur:

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

Töflur eru uppfærðar án langra læsinga vegna þess að tólið býr til nýja tímabundna töflu sem það afritar gögn úr aðaltöflunni í. Í augnablikinu þegar bæði borðin eru eins er upprunalega borðinu læst og skipt út fyrir það nýja. Í okkar tilviki sýndi prufukeyrsla að það tæki um sólarhring að uppfæra allar töflur, en afritun gagna olli of miklu álagi á diskana.

Til að forðast þetta, í framleiðslu bættum við röksemdinni við skipunina --sleep með gildinu 10 - þessi færibreyta stillir biðlengdina eftir að gagnalota er flutt yfir í nýja töflu. Þannig geturðu dregið úr álaginu ef raunverulegt forrit sem er í gangi krefst viðbragðstíma.

Eftir að fínstillingin var framkvæmd tókst uppfærslan.

... en ekki alveg!

Innan hálftíma eftir uppfærsluna kom viðskiptavinurinn með vandamál. Gagnagrunnurinn virkaði mjög undarlega: reglulega byrjuðu þeir tenging endurstillist. Svona leit það út í eftirliti:

Skjáskotið sýnir sagtanngrafík vegna þess að sumir MySQL netþjónaþræðir hrundu reglulega með villu. Villur birtust í forritinu:

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

Fljótleg skoðun á annálunum leiddi í ljós að mysqld púkinn gat ekki fengið tilskilin tilföng úr stýrikerfinu. Við uppgötvuðum villur í kerfinu þegar við leituðum út villur „munaðarlaus“ apparmor stefnuskrár:

# 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

Þessar skrár voru búnar til við uppfærslu í MySQL 5.7 fyrir nokkrum árum og tilheyra fjarlægum pakka. Að eyða skrám og endurræsa apparmor þjónustuna leysti vandamálið:

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

Að lokum

Sérhver, jafnvel einföldustu aðgerð, getur leitt til óvæntra vandamála. Og jafnvel að hafa úthugsaða áætlun tryggir ekki alltaf væntanlega niðurstöðu. Nú, allar uppfærsluáætlanir sem teymi okkar hefur einnig innihaldið skylduhreinsun á óþarfa skrám sem gætu hafa birst vegna nýlegra aðgerða.

Og með þessari ekki sérlega faglegu grafísku sköpun vil ég þakka Percona kærlega fyrir frábærar vörur!

PS

Lestu líka á blogginu okkar:

• «Gagnagrunnar og Kubernetes (endurskoðun og myndbandsskýrsla)»;
• «Kubernetes ráð og brellur: flýta fyrir ræsibúnaði fyrir stóra gagnagrunna»;
• «6 hagnýtar sögur úr SRE hversdagslífinu okkar»;
• «Ein saga með Redis rekstraraðilanum í K8s og smáúttekt á tólum til að greina gögn úr þessum gagnagrunni»;
• «Óaðfinnanlegur flutningur á MongoDB til Kubernetes'.

Heimild: www.habr.com