Diweddaru MySQL (Gweinydd Percona) o 5.7 i 8.0

Nid yw cynnydd yn aros yn ei unfan, felly mae'r rhesymau dros uwchraddio i'r fersiynau diweddaraf o MySQL yn dod yn fwyfwy cymhellol. Ddim yn bell yn ôl, yn un o'n prosiectau, roedd yn bryd diweddaru clystyrau clyd Percona Server 5.7 i fersiwn 8. Digwyddodd hyn i gyd ar blatfform Ubuntu Linux 16.04. Sut i berfformio llawdriniaeth o'r fath heb fawr o amser segur a pha broblemau y daethom ar eu traws yn ystod y diweddariad - darllenwch yn yr erthygl hon.

Hyfforddiant

Mae unrhyw ddiweddariad o weinydd y gronfa ddata yn fwyaf tebygol o fod yn gysylltiedig ag ad-drefnu cronfa ddata: newidiadau yn y gofynion ar gyfer cyfyngiadau ar adnoddau system a chywiro cyfluniadau cronfa ddata y mae angen eu dileu o gyfarwyddebau sydd wedi dyddio.

Cyn diweddaru, byddwn yn bendant yn cyfeirio at y ddogfennaeth swyddogol:

• Nodiadau rhyddhau MySQL 8;
• Canllaw uwchraddio MySQL;
• Canllaw diweddaru Percona;
• Canllaw MySQL i ddiweddaru replicas a meistri.

A gadewch i ni lunio cynllun gweithredu:

1. Cywiro ffeiliau cyfluniad trwy ddileu cyfarwyddebau sydd wedi dyddio.
2. Gwiriwch a yw'n gydnaws â chyfleustodau.
3. Diweddaru cronfeydd data caethweision trwy osod y pecyn percona-server-server.
4. Diweddarwch y meistr gyda'r un pecyn.

Gadewch i ni edrych ar bob pwynt o'r cynllun a gweld beth allai fynd o'i le.

PWYSIG! Mae gan y weithdrefn ar gyfer diweddaru clwstwr MySQL yn seiliedig ar Galera ei chynildeb ei hun nad yw'n cael ei ddisgrifio yn yr erthygl. Ni ddylech ddefnyddio'r cyfarwyddyd hwn yn yr achos hwn.

Rhan 1: Gwirio configs

Tynnwyd MySQL yn fersiwn 8 query_cache. Mewn gwirionedd yr oedd datgan darfodedig yn ôl yn fersiwn 5.7, ond nawr dileu yn llwyr. Yn unol â hynny, mae angen dileu'r cyfarwyddebau cysylltiedig. Ac i gadw ceisiadau gallwch nawr ddefnyddio offer allanol - er enghraifft, ProxySQL.

Hefyd yn y config roedd hen gyfarwyddebau ynghylch innodb_file_format. Os oedd hi'n bosibl dewis fformat InnoDB yn MySQL 5.7, yna mae'r 8fed fersiwn eisoes yn gweithio dim ond gyda fformat Barracuda.

Ein canlyniad yw dileu'r cyfarwyddebau canlynol:

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

I wirio, byddwn yn defnyddio delwedd Docker o Percona Server. Byddwn yn gosod cyfluniad y gweinydd yn y cyfeiriadur mysql_config_test, ac wrth ei ymyl byddwn yn creu cyfeiriaduron ar gyfer data a logiau. Enghraifft o brawf ffurfweddu gweinydd Percona:

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

Gwaelod llinell: naill ai yn y logiau Docker neu yn y cyfeiriadur gyda'r logiau - yn dibynnu ar eich configs - bydd ffeil yn ymddangos lle bydd y cyfarwyddebau problemus yn cael eu disgrifio.

Dyma beth oedd gennym ni:

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.

Felly, roedd angen i ni ddarganfod yr amgodiadau o hyd a disodli'r gyfarwyddeb hen ffasiwn expire-logs-days.

Rhan 2: Gwirio gosodiadau gweithio

Mae'r ddogfennaeth diweddaru yn cynnwys 2 gyfleustodau ar gyfer gwirio cydweddoldeb y gronfa ddata. Mae eu defnydd yn helpu'r gweinyddwr i wirio cydnawsedd y strwythur data presennol.

Gadewch i ni ddechrau gyda'r cyfleustodau mysqlcheck clasurol. Yn syml, rhedeg:

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

Os na chanfyddir unrhyw broblemau, bydd y cyfleustodau'n gadael gyda chod 0:

Yn ogystal, mae cyfleustodau ar gael mewn fersiynau modern o MySQL mysql-cragen (yn achos Percona dyma'r pecyn percona-mysql-shell). Mae'n disodli'r cleient mysql clasurol ac mae'n cyfuno swyddogaethau cleient, golygydd cod SQL ac offer gweinyddu MySQL. I wirio'r gweinydd cyn ei ddiweddaru, gallwch redeg y gorchmynion canlynol drwyddo:

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

Dyma’r sylwadau a gawsom:

Yn gyffredinol, dim byd hanfodol - dim ond rhybuddion am amgodio (gweler isod). Canlyniad gweithredu cyffredinol:

Fe wnaethom benderfynu y dylai'r diweddariad fynd heb unrhyw broblemau.

Nodyn am y rhybuddion uchod yn nodi problemau gydag amgodio. Y ffaith yw bod UTF-8 yn MySQL tan yn ddiweddar nid oedd yn "wir" UTF-8, gan ei fod yn storio dim ond 3 beit yn hytrach na 4. Yn MySQL 8 mae hyn yn olaf penderfynu ei drwsio: alias utf8 yn arwain at godio yn fuan utf8mb4, a bydd yr hen golofnau yn y tablau yn dod utf8mb3. Amgodio pellach utf8mb3 yn cael ei ddileu, ond nid yn y datganiad hwn. Felly, penderfynasom gywiro'r amgodiadau sydd eisoes ar y gosodiad DBMS sy'n rhedeg, ar ôl ei ddiweddaru.

Rhan 3: Diweddariadau Gweinydd

Beth allai fynd o'i le pan fo cynllun mor smart?... Gan ddeall yn iawn bod arlliwiau bob amser yn digwydd, fe wnaethom gynnal yr arbrawf cyntaf ar glwstwr dev MySQL.

Fel y soniwyd eisoes, dogfennaeth swyddogol yn ymdrin â mater diweddaru gweinyddwyr MySQL gyda chopïau. Y gwir amdani yw y dylech chi ddiweddaru pob atgynhyrchiad (caethweision) yn gyntaf, oherwydd gall MySQL 8 ailadrodd o fersiwn meistr 5.7. Mae peth anhawster yn gorwedd yn y ffaith ein bod yn defnyddio'r modd meistr <-> meistr, pan fydd y meistr o bell yn y modd darllen yn unig. Hynny yw, mewn gwirionedd, mae traffig ymladd yn mynd i un ganolfan ddata, ac mae'r ail un yn un wrth gefn.

Mae topoleg yn edrych fel hyn:

Rhaid i'r diweddariad ddechrau gyda chopïau mysql replica dc 2, meistr mysql dc 2 и mysql replica dc 1, a gorffen gyda gweinydd meistr mysql dc 1. Er mwyn bod yn fwy dibynadwy, fe wnaethom atal y peiriannau rhithwir, cymryd cipluniau ohonynt, ac yn union cyn i'r diweddariad roi'r gorau i ddyblygu gyda'r gorchymyn STOP SLAVE. Mae gweddill y diweddariad yn edrych fel hyn:

1. Rydym yn ailgychwyn pob replica trwy ychwanegu 3 opsiwn i'r ffurfweddiadau: skip-networking, skip-slave-start, skip-log-bin. Y ffaith yw bod diweddaru'r gronfa ddata yn cynhyrchu logiau deuaidd gyda diweddariadau i dablau system. Mae'r cyfarwyddebau hyn yn gwarantu na fydd unrhyw newidiadau i ddata cais yn y gronfa ddata, ac ni fydd gwybodaeth am ddiweddaru tablau system yn cael ei chynnwys yn y logiau deuaidd. Bydd hyn yn osgoi problemau wrth ailddechrau dyblygu.
2. Gosod y pecyn percona-server-server. Mae'n bwysig nodi hynny yn fersiwn 8 MySQL dim mae angen i chi redeg y gorchymyn mysqlupgrade ar ôl diweddariad gweinydd.
3. Ar ôl dechrau llwyddiannus, rydym yn ailgychwyn y gweinydd eto - heb y paramedrau a ychwanegwyd yn y paragraff cyntaf.
4. Rydym yn sicrhau bod atgynhyrchu'n gweithio'n llwyddiannus: gwiriwch SHOW SLAVE STATUS a gweld bod y tablau gyda chownteri yn y gronfa ddata ceisiadau yn cael eu diweddaru.

Mae'r cyfan yn edrych yn eithaf syml: roedd y diweddariad dev yn llwyddiannus. Iawn, gallwch chi drefnu diweddariad nosweithiol yn ddiogel ar gyfer cynhyrchu.

Doedd dim tristwch - fe ddiweddaron ni'r prod

Fodd bynnag, nid oedd trosglwyddo profiad datblygu llwyddiannus i gynhyrchu yn annisgwyl.

Yn ffodus, mae'r broses ddiweddaru ei hun yn dechrau gyda chopïau, felly pan ddaethom ar draws anawsterau, fe wnaethom roi'r gorau i'r gwaith ac adfer y replica o'r ciplun. Cafodd yr ymchwiliad i’r problemau ei ohirio tan y bore wedyn. Roedd y cofnodion yn cynnwys y cofnodion canlynol:

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

Arweiniodd ymchwilio i archifau amrywiol restrau postio ar Google at y ddealltwriaeth bod y broblem hon yn digwydd oherwydd MySQL byg. Er bod hyn yn fwy tebygol o nam cyfleustodau mysqlcheck и mysqlsh.

Mae'n ymddangos bod MySQL wedi newid y ffordd y maent yn cynrychioli data ar gyfer meysydd degol (int, tinyint, ac ati), felly mae mysql-server yn defnyddio ffordd wahanol i'w storio. Os yw eich cronfa ddata i ddechrau Roedd yn fersiwn 5.5 neu 5.1, ac yna fe wnaethoch chi ddiweddaru i 5.7, yna efallai y bydd angen i chi wneud OPTIMIZE ar gyfer rhai byrddau. Yna bydd MySQL yn diweddaru'r ffeiliau data, gan eu trosglwyddo i'r fformat storio cyfredol.

Gallwch hefyd wirio hyn gyda'r cyfleustodau 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',
...

Os field_type Os yw'n hafal i 0 gennych, yna defnyddir yr hen fath yn y tabl - mae angen i chi ei wneud OPTIMIZE. Fodd bynnag, os yw'r gwerth yn 246, mae gennych fath newydd eisoes. Mae rhagor o wybodaeth am y mathau ar gael yn côd.

Ar ben hynny, yn y byg hwn Rydym yn ystyried yr ail reswm posibl, a aeth heibio inni: absenoldeb tablau InnoDB yn y tabl system INNODB_SYS_TABLESPACES, os ydynt, tablau, wedi'u creu yn fersiwn 5.1. Er mwyn osgoi problemau wrth ddiweddaru, gallwch ddefnyddio sgript SQL ynghlwm.

Pam na chawsom broblemau o'r fath ar dev? Mae'r gronfa ddata yn cael ei chopïo yno o bryd i'w gilydd o'r cynhyrchiad - felly, byrddau yn cael eu hail-greu.

Yn anffodus, ar gronfa ddata fawr sy'n gweithio, ni fyddwch yn gallu cymryd a gweithredu cyffredinol yn unig OPTIMIZE. bydd percona-toolkit yn helpu yma: mae'r cyfleustodau pt-online-schema-change yn ardderchog ar gyfer y gweithrediad OPTIMIZE ar-lein.

Roedd y cynllun wedi'i ddiweddaru yn edrych fel hyn:

1. Optimeiddio'r holl dablau.
2. Diweddaru'r cronfeydd data.

Er mwyn ei wirio ac ar yr un pryd ddarganfod yr amser diweddaru, fe wnaethom analluogi un o'r atgynyrchiadau a rhedeg y gorchymyn canlynol ar gyfer pob tabl:

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

Mae tablau'n cael eu diweddaru heb gloeon hir oherwydd bod y cyfleustodau'n creu tabl dros dro newydd lle mae'n copïo data o'r prif dabl. Ar hyn o bryd pan fydd y ddau fwrdd yn union yr un fath, mae'r bwrdd gwreiddiol yn cael ei gloi a'i ddisodli gyda'r un newydd. Yn ein hachos ni, dangosodd rhediad prawf y byddai'n cymryd tua diwrnod i ddiweddaru'r holl dablau, ond roedd copïo data yn achosi gormod o lwyth ar y disgiau.

Er mwyn osgoi hyn, wrth gynhyrchu fe wnaethom ychwanegu'r ddadl at y gorchymyn --sleep gyda gwerth o 10 - mae'r paramedr hwn yn addasu'r hyd aros ar ôl trosglwyddo swp o ddata i dabl newydd. Fel hyn, gallwch chi leihau'r llwyth os yw'r cais rhedeg gwirioneddol yn gofyn am amser ymateb.

Ar ôl perfformio'r optimeiddio, roedd y diweddariad yn llwyddiannus.

... ond nid yn gyfan gwbl!

O fewn hanner awr ar ôl y diweddariad, daeth y cleient â phroblem. Gweithiodd y gronfa ddata yn rhyfedd iawn: o bryd i'w gilydd fe ddechreuon nhw ailosod cysylltiad. Dyma sut roedd yn edrych wrth fonitro:

Mae'r sgrin yn dangos graff sawtooth oherwydd bod rhai o edafedd gweinydd MySQL wedi damwain o bryd i'w gilydd gyda gwall. Ymddangosodd gwallau yn y cais:

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

Datgelodd archwiliad cyflym o'r logiau na allai'r daemon mysqld gael yr adnoddau gofynnol o'r system weithredu. Wrth ddatrys gwallau, fe wnaethon ni ddarganfod yn y system ffeiliau polisi apparmor "amddifad".:

# 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

Crëwyd y ffeiliau hyn wrth uwchraddio i MySQL 5.7 ychydig flynyddoedd yn ôl ac maent yn perthyn i becyn sydd wedi'i ddileu. Roedd dileu'r ffeiliau ac ailgychwyn y gwasanaeth offer wedi datrys y broblem:

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

I gloi

Gall unrhyw un, hyd yn oed y llawdriniaeth symlaf, arwain at broblemau annisgwyl. Ac nid yw hyd yn oed cael cynllun wedi'i feddwl yn ofalus bob amser yn gwarantu'r canlyniad disgwyliedig. Nawr, mae unrhyw gynlluniau diweddaru y mae ein tîm wedi'u cynnwys hefyd yn cynnwys glanhau'n orfodol ffeiliau diangen a allai fod wedi ymddangos o ganlyniad i gamau gweithredu diweddar.

A chyda'r creadigrwydd graffig hwn nad yw'n broffesiynol iawn, hoffwn ddweud diolch enfawr i Percona am eu cynnyrch rhagorol!

PS

Darllenwch hefyd ar ein blog:

• «Cronfeydd data a Kubernetes (adroddiad adolygu a fideo)";
• «Awgrymiadau a thriciau Kubernetes: cyflymu'r bootstrap ar gyfer cronfeydd data mawr";
• «6 stori ymarferol o'n bywyd bob dydd ARhPh";
• «Un stori gyda gweithredwr Redis yn K8s ac adolygiad bach o gyfleustodau ar gyfer dadansoddi data o'r gronfa ddata hon";
• «Mudo di-dor o MongoDB i Kubernetes'.

Ffynhonnell: hab.com