Kusasisha MySQL (Percona Server) kutoka 5.7 hadi 8.0

Maendeleo hayasimami, kwa hivyo sababu za kusasisha hadi matoleo ya hivi karibuni ya MySQL zinazidi kulazimisha. Si muda mrefu uliopita, katika mojawapo ya miradi yetu, ilikuwa ni wakati wa kusasisha nguzo za Percona Server 5.7 hadi toleo la 8. Haya yote yalitokea kwenye jukwaa la Ubuntu Linux 16.04. Jinsi ya kufanya operesheni kama hiyo kwa wakati mdogo na shida gani tulizokutana nazo wakati wa sasisho - soma katika nakala hii.

Mafunzo ya

Usasishaji wowote wa seva ya hifadhidata una uwezekano mkubwa wa kuhusishwa na usanidi upya wa hifadhidata: mabadiliko katika mahitaji ya vikomo kwenye rasilimali za mfumo na urekebishaji wa usanidi wa hifadhidata ambao unahitaji kufutwa kutoka kwa maagizo ya zamani.

Kabla ya kusasisha, hakika tutarejelea hati rasmi:

• Vidokezo vya kutolewa vya MySQL 8;
• Mwongozo wa kuboresha MySQL;
• Mwongozo wa sasisho wa Percona;
• Mwongozo wa MySQL wa kusasisha nakala na mabwana.

Na wacha tutengeneze mpango wa hatua:

1. Sahihisha faili za usanidi kwa kuondoa maagizo yaliyopitwa na wakati.
2. Angalia utangamano na huduma.
3. Sasisha hifadhidata za watumwa kwa kusakinisha kifurushi percona-server-server.
4. Sasisha bwana na kifurushi sawa.

Wacha tuangalie kila nukta ya mpango huo na tuone ni nini kinaweza kwenda vibaya.

MUHIMU! Utaratibu wa kusasisha nguzo ya MySQL kulingana na Galera ina hila zake ambazo hazijaelezewa katika makala. Haupaswi kutumia maagizo katika kesi hii.

Sehemu ya 1: Kuangalia mipangilio

MySQL iliondolewa katika toleo la 8 query_cache. Kweli alikuwa iliyotangazwa kuwa ya kizamani nyuma katika toleo la 5.7, lakini sasa imefutwa kabisa. Ipasavyo, ni muhimu kuondoa maagizo yanayohusiana. Na kuweka akiba ya maombi sasa unaweza kutumia zana za nje - kwa mfano, ProxySQL.

Pia katika usanidi kulikuwa na maagizo ya kizamani kuhusu innodb_file_format. Ikiwa katika MySQL 5.7 iliwezekana kuchagua muundo wa InnoDB, basi toleo la 8 tayari linafanya kazi tu na muundo wa Barracuda.

Matokeo yetu ni kuondolewa kwa maagizo yafuatayo:

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

Kuangalia, tutatumia picha ya Docker ya Percona Server. Tutaweka usanidi wa seva kwenye saraka mysql_config_test, na karibu nayo tutaunda saraka za data na kumbukumbu. Mfano wa jaribio la usanidi wa 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

Mstari wa chini: ama kwenye kumbukumbu za Docker au kwenye saraka na kumbukumbu - kulingana na usanidi wako - faili itaonekana ambayo maagizo ya shida yataelezewa.

Hii ndio tuliyokuwa nayo:

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.

Kwa hivyo, bado tulihitaji kubaini usimbaji na kuchukua nafasi ya maagizo yaliyopitwa na wakati expire-logs-days.

Sehemu ya 2: Kukagua mitambo inayofanya kazi

Nyaraka za sasisho zina huduma 2 za kuangalia hifadhidata kwa uoanifu. Matumizi yao husaidia msimamizi kuangalia utangamano wa muundo uliopo wa data.

Wacha tuanze na matumizi ya kawaida ya mysqlcheck. Endesha tu:

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

Ikiwa hakuna shida zinazopatikana, matumizi yatatoka na nambari 0:

Kwa kuongeza, matumizi yanapatikana katika matoleo ya kisasa ya MySQL mysql-shell (kwa upande wa Percona hii ndio kifurushi percona-mysql-shell) Ni mbadala wa mteja wa mysql wa kawaida na unachanganya kazi za mteja, kihariri cha msimbo wa SQL na zana za usimamizi za MySQL. Kuangalia seva kabla ya kusasisha, unaweza kuendesha amri zifuatazo kupitia hiyo:

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

Hapa kuna maoni tuliyopokea:

Kwa ujumla, hakuna kitu muhimu - maonyo tu juu ya usimbuaji (tazama hapa chini). Matokeo ya jumla ya utekelezaji:

Tuliamua kwamba sasisho linapaswa kwenda bila matatizo.

Ujumbe kuhusu maonyo yaliyo hapo juu yanayoonyesha matatizo na usimbaji. Ukweli ni kwamba UTF-8 katika MySQL hadi hivi karibuni haikuwa "kweli" UTF-8, kwani ilihifadhi ka 3 tu badala ya 4. Katika MySQL 8 hii ndio mwishowe aliamua kurekebisha: lakabu utf8 hivi karibuni itasababisha kuweka msimbo utf8mb4, na safu wima za zamani kwenye jedwali zitakuwa utf8mb3. Usimbaji zaidi utf8mb3 itaondolewa, lakini si katika toleo hili. Kwa hiyo, tuliamua kusahihisha encodings tayari kwenye usakinishaji wa DBMS unaoendesha, baada ya kuisasisha.

Sehemu ya 3: Sasisho za Seva

Je, ni nini kinachoweza kwenda vibaya kunapokuwa na mpango mzuri kama huu?.. Kwa kuelewa vizuri kwamba nuances kila mara hutokea, tulifanya jaribio la kwanza kwenye nguzo ya waendelezaji wa MySQL.

Kama ilivyotajwa tayari, nyaraka rasmi inashughulikia suala la kusasisha seva za MySQL na nakala. Jambo la msingi ni kwamba unapaswa kusasisha kwanza nakala zote (watumwa), kwani MySQL 8 inaweza kuiga kutoka kwa toleo kuu la 5.7. Ugumu fulani upo katika ukweli kwamba tunatumia modi bwana bwana, wakati bwana wa mbali yuko katika hali kusoma tu. Hiyo ni, kwa kweli, trafiki ya kupambana huenda kwenye kituo kimoja cha data, na cha pili ni chelezo.

Topolojia inaonekana kama hii:

Sasisho lazima lianze na nakala replica ya mysql dc 2, mysql bwana dc 2 и mysql replica dc 1, na kuishia na seva ya mysql master dc 1. Ili kuwa wa kuaminika zaidi, tulisimamisha mashine za mtandaoni, tukapiga picha zake, na mara moja kabla ya sasisho kusitisha kurudiwa kwa amri. STOP SLAVE. Sasisho zingine zinaonekana kama hii:

1. Tunaanzisha tena kila nakala kwa kuongeza chaguzi 3 kwenye usanidi: skip-networking, skip-slave-start, skip-log-bin. Ukweli ni kwamba uppdatering database inazalisha kumbukumbu binary na updates kwa meza ya mfumo. Maagizo haya yanahakikisha kuwa hakutakuwa na mabadiliko kwa data ya programu katika hifadhidata, na taarifa kuhusu kusasisha jedwali za mfumo hazitajumuishwa kwenye kumbukumbu za mfumo wa jozi. Hii itaepuka matatizo wakati wa kurejesha tena.
2. Kufunga kifurushi percona-server-server. Ni muhimu kutambua kwamba katika toleo la 8 la MySQL hakuna unahitaji kuendesha amri mysqlupgrade baada ya sasisho la seva.
3. Baada ya kuanza kwa mafanikio, tunaanzisha tena seva tena - bila vigezo vilivyoongezwa katika aya ya kwanza.
4. Tunahakikisha kuwa urudufishaji hufanya kazi kwa mafanikio: angalia SHOW SLAVE STATUS na uone kwamba jedwali zilizo na vihesabio kwenye hifadhidata ya programu zinasasishwa.

Yote inaonekana rahisi sana: sasisho la dev lilifanikiwa. Sawa, unaweza kuratibu kwa usalama sasisho la kila usiku kwa ajili ya uzalishaji.

Hakukuwa na huzuni - tulisasisha prod

Walakini, uhamishaji wa uzoefu uliofanikiwa wa dev kwa uzalishaji haukuwa bila mshangao.

Kwa bahati nzuri, mchakato wa sasisho yenyewe huanza na nakala, kwa hivyo tulipokumbana na shida, tulisimamisha kazi na kurejesha nakala kutoka kwa picha. Uchunguzi wa matatizo hayo uliahirishwa hadi asubuhi iliyofuata. Kumbukumbu hizo zilikuwa na maingizo yafuatayo:

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

Kutafiti kwenye kumbukumbu za orodha mbalimbali za barua pepe kwenye Google kulipelekea kuelewa kuwa tatizo hili hutokea kutokana na Mdudu wa MySQL. Ingawa hii ni uwezekano mkubwa wa mdudu wa matumizi mysqlcheck и mysqlsh.

Inabadilika kuwa MySQL ilibadilisha jinsi wanavyowakilisha data ya sehemu za decimal (int, tinyint, nk), kwa hivyo mysql-server hutumia njia tofauti kuzihifadhi. Ikiwa hifadhidata yako awali ilikuwa katika toleo la 5.5 au 5.1, na kisha ulisasisha hadi 5.7, basi unaweza kuhitaji kufanya OPTIMIZE kwa baadhi ya meza. Kisha MySQL itasasisha faili za data, na kuzihamisha kwa umbizo la sasa la hifadhi.

Unaweza pia kuangalia hii na matumizi 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',
...

Kama field_type Ikiwa unayo sawa na 0, basi aina ya zamani hutumiwa kwenye meza - unahitaji kutekeleza OPTIMIZE. Hata hivyo, ikiwa thamani ni 246, tayari una aina mpya. Maelezo zaidi kuhusu aina yanaweza kupatikana katika kanuni.

Kwa kuongezea, katika mdudu huyu Tunazingatia sababu ya pili inayowezekana, ambayo ilitupita: kutokuwepo kwa meza za InnoDB kwenye jedwali la mfumo INNODB_SYS_TABLESPACES, ikiwa wao, meza, ziliundwa katika toleo la 5.1. Ili kuepuka matatizo wakati wa kusasisha, unaweza kutumia hati ya SQL iliyoambatanishwa.

Kwa nini hatukuwa na matatizo kama haya kwenye dev? Hifadhidata inakiliwa mara kwa mara kutoka kwa uzalishaji - kwa hivyo, meza zinaundwa upya.

Kwa bahati mbaya, kwenye hifadhidata kubwa inayofanya kazi kweli, hutaweza tu kuchukua na kutekeleza zima OPTIMIZE. Percona-toolkit itasaidia hapa: matumizi ya pt-online-schema-change ni bora kwa operesheni ya OPTIMIZE ya mtandaoni.

Mpango uliosasishwa ulionekana kama hii:

1. Boresha majedwali yote.
2. Sasisha hifadhidata.

Ili kuiangalia na wakati huo huo kujua wakati wa kusasisha, tulizima moja ya nakala na tukaendesha amri ifuatayo kwa jedwali zote:

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

Majedwali yanasasishwa bila kufuli kwa muda mrefu kwa sababu ya ukweli kwamba shirika huunda jedwali mpya la muda ambalo linakili data kutoka kwa jedwali kuu. Wakati jedwali zote mbili zinafanana, jedwali la asili limefungwa na kubadilishwa na mpya. Kwa upande wetu, jaribio la majaribio lilionyesha kuwa itachukua siku moja kusasisha meza zote, lakini kunakili data kunasababisha mzigo mwingi kwenye diski.

Ili kuepuka hili, katika uzalishaji tuliongeza hoja kwa amri --sleep na thamani ya 10 - parameter hii inarekebisha urefu wa kusubiri baada ya kuhamisha kundi la data kwenye meza mpya. Kwa njia hii unaweza kupunguza mzigo ikiwa programu halisi inayoendesha inahitaji wakati wa kujibu.

Baada ya kufanya uboreshaji, sasisho lilifanikiwa.

... lakini sio kabisa!

Ndani ya nusu saa baada ya sasisho, mteja alikuja na tatizo. Hifadhidata ilifanya kazi kwa kushangaza sana: mara kwa mara walianza uunganisho upya. Hivi ndivyo ilivyokuwa katika ufuatiliaji:

Picha ya skrini inaonyesha grafu ya sawtooth kutokana na ukweli kwamba baadhi ya nyuzi za seva ya MySQL zilianguka mara kwa mara na hitilafu. Makosa yalionekana katika programu:

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

Ukaguzi wa haraka wa kumbukumbu ulifunua kuwa daemon ya mysqld haikuweza kupata rasilimali zinazohitajika kutoka kwa mfumo wa uendeshaji. Wakati wa kutatua makosa, tuligundua kwenye mfumo faili za sera za silaha za "yatima".:

# 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

Faili hizi ziliundwa wakati wa kupata toleo jipya la MySQL 5.7 miaka michache iliyopita na ni za kifurushi kilichoondolewa. Kufuta faili na kuanzisha tena huduma ya apparmor kulitatua tatizo:

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

Kwa kumalizia

Yoyote, hata operesheni rahisi zaidi, inaweza kusababisha matatizo yasiyotarajiwa. Na hata kuwa na mpango uliofikiriwa vizuri hakuhakikishi kila wakati matokeo yanayotarajiwa. Sasa, mipango yoyote ya usasishaji ambayo timu yetu inayo pia inajumuisha usafishaji wa lazima wa faili zisizo za lazima ambazo zingeweza kuonekana kama matokeo ya vitendo vya hivi majuzi.

Na kwa ubunifu huu sio wa kitaalamu sana wa picha, ningependa kusema asante kubwa kwa Percona kwa bidhaa zao bora!

PS

Soma pia kwenye blogi yetu:

• «Hifadhidata na Kubernetes (hakiki na ripoti ya video)";
• «Vidokezo na mbinu za Kubernetes: kuongeza kasi ya bootstrap kwa hifadhidata kubwa";
• «Hadithi 6 za vitendo kutoka kwa maisha yetu ya kila siku ya SRE";
• «Hadithi moja na opereta wa Redis katika K8s na hakiki ndogo ya huduma za kuchambua data kutoka kwa hifadhidata hii.";
• «Uhamiaji bila mshono wa MongoDB hadi Kubernetes'.

Chanzo: mapenzi.com