🥇MySQL-ի (Percona Server) թարմացում 5.7-ից 8.0

Ա progreso չի կանգնում, հետևաբար MySQL-ի արդիական տարբերակներին անցնելու պատճառները越来越 կարևոր են։ Մոտ ժամանակներում մեր նախագծերից մեկում եկել էր ժամանակը Percona Server 5.7-ն թարմացնել 8-րդ տարբերակին։ Այն ամենը տեղի ունեցավ Ubuntu Linux 16.04 платформայում։ Ինչպես իրականացնել նման ընթացակարգ առանց մեծ նկատելիության և առնչվող խնդիրները, որոնք մենք հանդիպեցինք թարմացման ընթացքում, կկարդաք այս հոդվածում։

Պատրաստություն

Բ cualquier թարմացում տվյալների բազայի սերվերի կհանգեցնի բազայի նորից կարգավորման՝ համակարգային ռեսուրսների սահմանների պահանջների փոփոխության և կոնֆիգուրացիայի ֆայլերի մաքրում, որոնք պետք է ազատվել հին հրահանգներից։

Թարմացումից առաջ մենք անպայման կանդրադառնանք պաշտոնական փաստաթղթերին։

Եվ կկազմենք գործողությունների պլան։

Կարգավորման ֆայլերը վերադասավորել, հին հրահանգները հեռացնել։
Համապատասխանությունը ստուգել պիտանի ուսումնական կազմակերպությունների միջոցով։
Թարմացնել slave բազաները, տեղադրելով փաթեթը percona-server-server.
Թարմացնել առաջնորդը, տեղադրելով նույն փաթեթը։

Ընդլայնենք յուրաքանչյուր կետ ապա, և տեսենք, թե ինչ կարող է տեղի ունենալ։

ՄԱՀԱԳ ԹԵ! MySQL Կլաստերների Galera հիման վրա թարմացման ընթացակարգը ունի իր համապատասխան նրբությունները, որոնք հոդվածում չեն նկարագրվում։ Մի հավատարիմ եղեք տվյալ հրահանգներին այդ դեպքում։

Մաս 1: Կոնֆիգների ստուգում

MySQL 8-ի տարբերակում վերացվել է query_cache։ Վերակա նրան հայտնաբերվել էր հին հիշողություններում, սակայն այժմ վերացվել է ամբողջովին։ Correspondingly, it is necessary to remove the related directives. And for query caching, external tools can now be used — for example, ProxySQL.

Նույն դեպքում կոնֆիգում գտանք հին հրահանգների մասին innodb_file_format։ Երբ MySQL 5.7-ում հնարավորություն կար ընտրելու InnoDB ձևաչափը, 8-րդ տարբերակը արդեն աշխատում է միայն Barracuda ձևաչափի հետ.

Մեր արդյունքը՝ հեռացնել հետևյալ հրահանգները՝

query_cache_type, query_cache_limit և query_cache_size;
innodb_file_format և innodb_file_format_max.

Ստուգման համար օգտվենք Percona Server-ի Docker պատկերից։ Սերվերի կոնֆիգը կդնենք mysql_config_testտեղամասում, իսկ կողքի տեղերում ստեղծելու ենք տվյալների և լոգերի համար։ Percona-server-ի կոնֆիգուրացիայի ստուգման օրինակը՝

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

Արդյունքում՝ կամ Docker-ի լոգերում, կամ լոգերի ստադիոյում՝ համեմատաբար ձեր կոնֆիգների՝ կստացվի մի ֆայլ, որտեղ կշարադրվեն խնդրահարույց հրահանգները։

Ահա ինչ եղել է մեզ մոտ։

2020-04-03T12:44:19.670831Z 0 [Warning] [MY-011068] [Server] 'expire-logs-days' սինտակտը հին է և կտրվի ապագա թողարկման մեջ: Խնդրում ենք օգտագործել binlog_expire_logs_seconds փոխարեն: 
2020-04-03T12:44:19.671678Z 0 [Warning] [MY-013242] [Server] --character-set-server: 'utf8'-ը ներկայումս 'UTF8MB3' կոդավորման alias է, բայց ապագա թողարկման մեջ կլինի 'UTF8MB4' alias-ը: Խնդրում ենք դիտարկել 'UTF8MB4'-ը որպես հստակ տարբերակ: 
2020-04-03T12:44:19.671682Z 0 [Warning] [MY-013244] [Server] --collation-server: 'utf8_general_ci'-ը 'UTF8MB3' կոդավորման մշակումը է: Խնդրում ենք դիտարկել 'UTF8MB4'-ը համապատասխան մշակմամբ իդենտիֆիկացնելու համար:

Այսպիսով, մեզ անհրաժեշտ է նաև հասկանալ կոդերկումները և փոխարինել հինը հրամանները: expire-logs-days.

Առաջին մաս: Վերագործարկված կարգավորումներն ստուգելու համար

Թարմացման փաստաթղթում կան 2 օգտակար սարքեր, որոնք հնարավորություն են տալիս ղեկավարին ստուգել տվյալների կառուցվածքի համապատասխանությունը:

Այսպիսով, սկսենք դասական mysqlcheck ծառայությունից: Պարզապես պետք է գործարկել.

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

Եթե խնդիրներ չեն հայտնաբերվել, ծառայությունը կավարտվի 0 կոդով:

Բացի այդ, ժամանակակից MySQL տարբերություններում առկա է mysql-shell (Percona դեպքում, սա փաթեթ է percona-mysql-shell). Սա փոխարինում է ավանդական mysql հաճախորդին և միավորում է SQL կոդի խմբագրողի և MySQL կառավարման գործիքները: Սերվերը թարմացնելուց առաջ կարող եք կատարել հետևյալ հրահանգները:

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

Եվ ահա, ինչ նկատառումներով մենք ստացանք:

Ընդհանուր առմամբ, ոչ մի կարևոր խնդիր չկա - ընդամենը կոդերի վերաբերյալ նախազգուշական նշումներ: (siehe unten). Կատարվածի ընդհանուր արդյունքը:

Մենք որոշեցինք, որ թարմացումը պետք է անցնի առանց խնդիրների:

Նախազգուշության նշումը վերևում, ինչը ցույց է տալիս կոդերի խնդիրների առկայությունը: Ավելին, փաստն այն է, որ UTF-8-ն MySQL-ում մինչև վերջերս չէր հանդիսանում 'իրական' UTF-8, քանի որ պահում էր ընդամենը 3 բիտ, այլ ոչ թե 4-ը: MySQL 8-ում, խոստումնալից, այս խնդիրը լուծելու որոշել է: 'utf8' aliasը հիմնականում կմատի 'utf8mb4' կոդավորմանն: , հին սյուները բոլորը կդառնան utf8mb3. Ապագայում այդ կոդավորումը կջնջվի, բայց ոչ այս թողարկման մեջ: Այսպիսով, մենք որոշեցինք ուղղել կոդավորումները արդեն գոյություն ունեցող տվյալների բազայում, նրա թարմացումից հետո: Առաջին մաս: Սերվերների թարմացումԻնչպե՞ս կարող է ինչ-որ բան սխալ գնալ, երբ նման վառ ծրագիր կա?.. Շատ լավ հասկանալով, որ մանրուքներ միշտ լինում են, առաջին փորձը անցկացնել Dev MySQL կլաստերում: Առաջին մաս: Սերվերների թարմացում Ինչպես նշվեց,

պաշտոնական փաստաթղթերն

ողբերգական ինչ-որ բանով մասին MySQL սերվերների թարմացումները ՝ կրկնակի կլաստերով: Հիմնականը կայանում է նրանում, որ նախ պետք է թարմացվեն բոլոր կրկնակի (slave) մասերը, քանի որ MySQL 8 կարողանում է կրկնօրինակել 5.7-ма եղանակով: Ցանկացած բարդությունը այն է, որ մեր համակարգն օգտագործում է

master <-> master թարմացման եղանակը 'read-only': . Այն է, որ փաստացի թռիչքը մեկ տվյալ կենտրոնում է, մինչդեռ 2-րդը - բալանսավորող կենտրոն: Թոփոլոգիան արտապատկանում է:Թարմացումը պետք է սկսվի կրկնակի mysql replica dc 2mysql master dc 2

mysql replica dc 1

Обновление должно начаться с реплик mysql replica dc 2, mysql master dc 2 և mysql replica dc 1, և ավարտվի MySQL master dc 1-ի սերվերով: Համաճարակի ճշգրտման համար մենք կանգնեցրել ենք վիրտուալ մեքենաները, ստեղծել ենք դրանց նկարահանումները, իսկ թարմացմանը նախորդ երեկոյան կանգնեցրել ենք կրկնօրինակը հրամանով ԵԿՐՈՒՄ ԿԱՐԴ ԾԱՆՈՒՄ. Բացի այս՝ թարմացումը գծային կարգով է.

Յուրաքանչյուր կրկնօրինակ վերագործարկենք, ավելացնելով 3 տարբերակ config-երում: skip-networking, skip-slave-start, skip-log-bin. Բանն այն է, որ տվյալների բանկը թարմացումը ստեղծում է բինարային օրագրեր համակարգային աղյուսակների թարմանումով: Այս ցուցումները վստահեցնում են, որ տվյալների բանկում չի լինի տվյալների փոխարկում կիրառման մասին, իսկ բինարային օրագրերում չի մտնի տեղեկատվություն համակարգային աղյուսակների թարմացման մասին: Սա թույլ կտա խուսափել կրկնօրինակի վերականգնման ժամանակ խնդիրներից:
Տեղադրում ենք փաթեթը percona-server-server. Կարևոր է նշել, որ MySQL 8 տարբերակում не պահանջվում է կատարել հրամանը mysqlupgrade սերվերի թարմացումից հետո:
Տեղական հաջող մեկնարկից հետո ևս մեկ անգամ վերագործարկում ենք սերվերը՝ առանց առաջին կետում ավելացված պարամետրերի:
Հանգստացեք, որ կրկնօրինակը հաջողությամբ աշխատում է՝ ստուգելով SHOW SLAVE STATUS և տեսնում ենք, որ հաշվիչների աղյուսակները թարմացվում են տվյալների բանկում:

Այս ամենը բավականին պարզ է թվում. dev թարմացումը հաջողությամբ անցել է: Շնորհակալություն, կարող ենք հանգիստ պլանավորել գիշերային թարմացումը production համար:

Չկար տխվան — production-ը մենք թարմացնում էինք

Մտորումները dev-ից production տեղափոխելը, սակայն, առանց անակնկալների չէր անցել:

Բախտի վրա, թարմացման գործընթացը սկսվում է կրկնօրինակներից, հետևաբար, բարդությունների դեպքում մենք կանգնեցրել ենք աշխատանքները և վերականգնել ենք կրկնօրինակը նկարահանումից: Խնդիրների հետազոտումն իրականացրել ենք հաջորդ առավոտ: Լոգերում հայտնվել են հետևյալ գրառումները:

2020-01-14T21:43:21.500563Z 2 [ՏԵՍԱԿ] [MY-012069] [InnnoDB] աղյուսակ: t1 ունի 19 սյուներ, բայց InnoDB բառացանկում կա 20 սյուն: 
2020-01-14T21:43:21.500722Z 2 [ՏԵՍԱԿ] [MY-010767] [Սերվեր] Վնասը DB1.t1-ի SE տվյալները շտկելու գործում: 
2020-01-14T21:43:24.208365Z 0 [ՏԵՍԱԿ] [MY-010022] [Սերվեր] Տվյալների DD աղյուսակների բնակեցումը ձախողվեց. 
2020-01-14T21:43:24.208658Z 0 [ՏԵՍԱԿ] [MY-010119] [Սերվեր] Ավարտախեղումը

Տարբեր մարքեթինգային առավելությունների հիմնավորման ուսումնասիրությունը Google-ում գտավ, որ նման խնդիրներ ծագում են MySQL-ի թերությունից. Որպեսզի դա որևէ այլոց փորձություն է, mysqlcheck և mysqlsh.

Հայտնաբերվեց, որ MySQL-ը փոխեց տասնորդական որակներ (int, tinyint և այլն), ուստի mysql-server-ի մեջ պահման այլ մոտեցում կիրառվում է: Եթե ձեր տվյալների բանկը թվարկվել է 5.5 կամ 5.1 версиայից, ապա կրկին անցել 5.7-ին, այն դեպքում, վանել ԿԵՆԿԻԿ OPTIMIZE մի քանի աղյուսակների համար: Այնուհետև MySQL-ն կթարմացնի տվյալների ֆայլերը՝ անցնելով արդիական պահման ձևակերպքին:

Սա կարելի է ստուգել նաև՝ 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',
...

Եթե field_type 0–ի դեպքում նույնիսկ հին տեսակի վերաբերել, պետք է OPTIMIZE. Բայց, եթե արժեքը 246 է, ապա ձեզ մոտ արդեն նոր տեսակ կա: Տեսակների մասին ավելի մանրամասն տեղեկություններ կարող եք գտնել կոդում.

Հատուկ շեշտը, որ սակայն, այս թերությունում քննարկվում է երկրորդ հնարավոր պատճառը, որը մեզ շրջանցեց, դա InnoDB-սեղանների բացակայությունն է համակարգային սեղանում INNODB_SYS_TABLESPACES, եթե այդ սեղանները ստեղծվել են 5.1 տարբերակում։ Թարմացման ընթացքում խնդիրներից խուսափելու համար կարող եք օգտվել կցված SQL-σκրիպտից.

Ինչու՞ մենք նման խնդիրներ չենք ունեցել dev-ում։ Համաձայնները ժամանակ առ ժամանակ կընդօրինակվեն production-ից՝ այդ կերպ, սեղանները վերակազմվում են.

Ցավոք, իրական աշխատող մեծ տվյալների բազայում պարզապես հնարավոր չէ կատարել հետազոտություն OPTIMIZE։ Այստեղ օգնության կհասնի percona-toolkit-ը։ Online OPTIMIZE գործողության համար իդեալականն է утիլիտա pt-online-schema-change-ը։

Թարմացված պլանը ստացվեց հետևյալը՝

Բոլոր սեղանների օպտիմիզացիա իրականացումը։
Տվյալների բազաների թարմացում իրականացումը։

Արդյունքները ստուգելու և միաժամանակ թարմացման ժամանակը պարզելու համար մենք отключили մեկ կրկնօրինակ, իսկ բոլոր սեղանների համար գործարկել ենք հետևյալ հրամանը՝

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

Սեղանների թարմացումը կատարվում է երկարատև արգելափակումներով շնորհիվ այն բանի, որ մեր համակարգիչը ստեղծում է նոր ժամանակավոր սեղան, որի մեջ պատճենում է տվյալները հիմնական սեղանից։ Արժեքային սեղանը արգելափակվում է և փոխում է նորի։ Մեր դեպքում փորձնական գործարկումը ցույց է տվել, որ բոլոր սեղանների թարմացմանը կպահանջվի մոտ մեկ օր, բայց տվյալների պատճենումը շատ բարձր ծանրաբեռնում է մահճակալները։

Այդ խուսափելու համար production-ում մենք հրամանին ավելացրեցինք аргумент --sleep 10 արժեքով՝ այս պարամետրը կարգավորում է սպասման երկարությունը տվյալների փունջը նոր սեղան տեղափոխելուց հետո։ Այդ կերպ հնարավոր է նվազեցնել ծանրաբեռնվածությունը, եթե իրականում գործառնական հայտարարը պահանջկոտ է արձագանքման ժամանակի։

Օպտիմիզացիայի իրականացումից հետո թարմացումը անցավ հաջողությամբ։

… Բայց ոչ այնքան ամբողջությամբ!

Որոշ ժամանակ անց, թարմացումից հետո, հաճախորդը շտապ կապվեց խնդրով։ Դատարանը գործեց շատ տարօրինակ. ժամանակ առ ժամանակ սկսվեցին կապերի անջատումներ։ Նայեք, թե ինչպես է դա երևում մոնիտորինգում։

Սքրինշոթում երևում է շեղ գծանշան, որը կապված է այն բանի հետ, որ MySQL-սերվերի մի քանի հոսանքներ ժամանակ առ ժամանակ ընկնում էին սխալով։ Նայեք, որ ծրագրային հասցեն մեջ ցույց է տալիս սխալները՝

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

Ամենադյուր նախաձեռնության հետազոտությունը ցույց է տվել, որ mysqld համակարգիչը չէր կարող ստանալ անհրաժեշտ ռեսուրսները օպերացիոն համակարգից։ Սխալների հետ աշխատելիս մենք բացահայտեցինք համակարգում «մեռած» apparmor քաղաքականության ֆայլեր:

# 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

Այս ֆայլերը կազմվել էին 2 տարի առաջ MySQL 5.7 թարմացման ժամանակ և պատկանում էին անհետացած փաթեթին։ Ֆայլերի ջնջումը և apparmor ծառայության վերագործարկումը լուծեց խնդիրը՝

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

Ընդհանուր առմամբ

Որի ցանկացած, նույնիսկ պարզ գործողությունը կարող է բերել անսպասելի խնդիրների: Եվ նույնիսկ մտածված ծրագրի առկայությունը չի երաշխավորում սպասված արդյունքը: Այժմ մեր թիմի վարպետական ծրագրերին կմտնի նաև պարտադիր լրացուցիչ ֆայլերի մաքրումը, որոնք կարող են առաջանալ վերջին գործողությունների արդյունքում:

Այս ոչ այնքան պրոֆեսիոնալ գրաֆիկական ստեղծագործության համար ցանկանում եմ մեծ շնորհակալություն հայտնել Percona ընկերությանը նրանց գերազանց արտադրանքների համար:

P.S.

Նաեւ կարդացեք մեր բլոգում:

Ընտանիք: habr.com