🥇MYSQL-ի (Percona Server) թարմացումը 5.7-ից մինչև 8.0

Առաջընթացը տեղում չի կանգնում, ուստի MySQL-ի վերջին տարբերակներին թարմացնելու պատճառները գնալով ավելի նշանակալի են դառնում: Վերջերս մեր նախագծերից մեկում ժամանակն էր հարմարավետ Percona Server 5.7 կլաստերները թարմացնել 8-րդ տարբերակի: Այս ամենը տեղի ունեցավ Ubuntu Linux 16.04 հարթակում: Ինչպես կատարել նման գործողություն նվազագույն դադարներով և ինչ խնդիրների հանդիպեցինք թարմացման ընթացքում՝ կարդացեք այս հոդվածում:

Ուսուցում

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

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

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

Ուղղեք կարգավորման ֆայլերը՝ հեռացնելով հնացած հրահանգները։
Ստուգեք համատեղելիությունը կոմունալ ծառայությունների հետ։
Թարմացրեք ստրուկ տվյալների բազաները՝ տեղադրելով փաթեթը percona-server-server.
Թարմացրեք գլխավոր ֆայլը՝ տեղադրելով նույն փաթեթը։

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

ԿԱՐԵՎՈՐ. Galera-ի վրա հիմնված MySQL կլաստերի թարմացման ընթացակարգն ունի իր նրբությունները, որոնք հոդվածում նկարագրված չեն։ Նման դեպքում չպետք է օգտագործեք այս հրահանգը։

Մաս 1. Կարգավորումների ստուգում

MySQL-ի 8-րդ տարբերակում այն հեռացվեց query_cacheԻրականում նա էր։ հայտարարված է հնացած դեռևս 5.7 տարբերակում, բայց հիմա ամբողջությամբ հեռացվածՀետևաբար, անհրաժեշտ է հեռացնել համապատասխան դիրեկտիվները: Իսկ հարցումների քեշավորման համար այժմ կարող եք օգտագործել արտաքին գործիքներ, օրինակ՝ 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-ի logs-ում, կամ logs դիրեկտորիայում՝ կախված ձեր կարգավորումներից, կհայտնվի ֆայլ, որը կնկարագրի խնդրահարույց դիրեկտիվները։

Ահա թե ինչ ունեինք մենք.

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.

Այսպիսով, մենք դեռ պետք է պարզեինք կոդավորումները և փոխարինեինք հնացած հրահանգը։ expire-logs-days.

Մաս 2. Աշխատանքային սարքավորումների ստուգում

Թարմացման փաստաթղթերը պարունակում են 2 օգտակար ծրագիր՝ տվյալների բազայի համատեղելիությունը ստուգելու համար։ Դրանց օգտագործումը օգնում է ադմինիստրատորին ստուգել առկա տվյալների կառուցվածքի համատեղելիությունը։

Եկեք սկսենք դասական mysqlcheck ծրագրից։ Պարզապես գործարկեք այն։

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

Եթե խնդիրներ չհայտնաբերվեն, ծրագիրը կփակվի 0 կոդով։

Բացի այդ, MySQL-ի ժամանակակից տարբերակները ունեն օգտակար ծրագիր mysql shell (Պերկոնայի դեպքում դա փաթեթ է) 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

Եվ ահա մեր ստացած մեկնաբանությունները.

Ընդհանուր առմամբ, ոչինչ կարևոր չէ՝ պարզապես կոդավորման վերաբերյալ նախազգուշացումներ (տես ներքեւում)Կատարման ընդհանուր արդյունքը՝

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

Նշում վերը նշված կոդավորման խնդիրների մասին նախազգուշացումների վերաբերյալ։ Բանն այն է, որ MySQL-ում մինչև վերջերս UTF-8-ը «իրական» UTF-8 չէր, քանի որ այն պահպանում էր ընդամենը 3 բայթ՝ 4-ի փոխարեն։ MySQL 8-ում սա վերջապես որոշեց այն շտկել: կեղծանուն utf8 շուտով կհանգեցնի կոդավորման utf8mb4, և աղյուսակների հին սյուները կդառնան utf8mb3Հետագա կոդավորում utf8mb3 կհեռացվի, բայց ոչ այս թողարկման մեջ։ Հետևաբար, մենք որոշեցինք շտկել գործող DBMS տեղադրման վրա արդեն իսկ առկա կոդավորումները՝ դրա թարմացումից հետո։

Մաս 3. Սերվերների թարմացում

Ի՞նչը կարող է սխալ գնալ, երբ կա այդպիսի հանճարեղ ծրագիր։ Լավ գիտակցելով, որ նրբերանգները միշտ էլ լինում են, մենք առաջին փորձը անցկացրինք MySQL մշակողների կլաստերի վրա։

Ինչպես արդեն նշվեց, պաշտոնական փաստաթղթեր ընդգրկում է MySQL սերվերների կրկնօրինակներով թարմացման հարցը։ Հիմնականն այն է, որ դուք պետք է նախ թարմացնեք բոլոր կրկնօրինակները (slave), քանի որ MySQL 8-ը կարող է կրկնօրինակել master տարբերակ 5.7-ից։ Որոշ դժվարություն կայանում է նրանում, որ մենք օգտագործում ենք ռեժիմը վարպետ <-> վարպետ, երբ հեռակառավարիչը ռեժիմում է միայն կարդալու համարԱյսինքն, մարտական երթևեկությունը գալիս է մեկ տվյալների կենտրոն, իսկ երկրորդը պահեստային է:

Տոպոլոգիան այսպիսի տեսք ունի՝

Թարմացումը պետք է սկսվի կրկնօրինակներով mysql dc 2 կրկնօրինակը, mysql master dc 2 и mysql replica dc 1, և ավարտվում է mysql master dc 1 սերվերով։ Ավելի մեծ հուսալիության համար մենք կանգնեցրինք վիրտուալ մեքենաները, կատարեցինք դրանց լուսանկարներ և թարմացումից անմիջապես առաջ դադարեցրինք կրկնօրինակումը հրամանով։ STOP SLAVEՀակառակ դեպքում, թարմացումը հետևյալ տեսքն ունի՝

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

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

Տխրություն չկար՝ մենք թարմացրինք արտադրանքը

Այնուամենայնիվ, հաջողված մշակողների փորձը արտադրության մեջ տեղափոխելը անակնկալներից զերծ չանցավ։

Բարեբախտաբար, թարմացման գործընթացն ինքնին սկսվում է կրկնօրինակներից, ուստի երբ մենք դժվարությունների հանդիպեցինք, մենք դադարեցրինք աշխատանքը և վերականգնեցինք կրկնօրինակը լուսանկարից։ Խնդիրների ուսումնասիրությունը հետաձգվեց մինչև հաջորդ առավոտ։ Գրանցամատյաններում հայտնաբերվել են հետևյալ գրառումները՝

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

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 սկրիպտով.

Ինչո՞ւ մենք նման խնդիրներ չունեինք մշակողի վրա։ Տվյալների բազան պարբերաբար պատճենվում է այնտեղ՝ արտադրությունից, այսպիսով, աղյուսակները վերստեղծվում են.

Դժբախտաբար, իսկապես աշխատող մեծ տվյալների բազայում հնարավոր չի լինի պարզապես վերցնել և կատարել ամենուրեք OPTIMIZEԱյստեղ կօգնի percona-toolkit-ը. pt-online-schema-change ծրագիրը հիանալի է առցանց OPTIMIZE գործողության համար։

Թարմացված պլանը ստացվեց այսպիսին.

Օպտիմալացնել բոլոր աղյուսակները։
Կատարեք տվյալների բազայի թարմացում։

Այն փորձարկելու և նաև թարմացման ժամանակը պարզելու համար մենք անջատեցինք կրկնօրինակներից մեկը և բոլոր աղյուսակների համար գործարկեցինք հետևյալ հրամանը.

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

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

Դրանից խուսափելու համար, արտադրության մեջ մենք հրամանին ավելացրինք արգումենտ։ --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

Այս ֆայլերը ստեղծվել են 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-ին իրենց գերազանց արտադրանքի համար։