Progresi nuk qëndron, prandaj arsyet për t'u azhurnuar në versionet më të fundit të MySQL po bëhen gjithnjë e më domethënëse. Kohët e fundit, në një nga projektet tona, erdhi koha për të azhurnuar klasterat e rehatshëm të Percona Server 5.7 në versionin 8. Kjo e gjithë ndodhi në platformën Ubuntu Linux 16.04. Si të realizohet një operacion i tillë me një minimum shkarke dhe mbi cilat probleme u përballëm gjatë azhurnimit - lexoni në këtë artikull.
PĂ«rgatitja
Ădo azhurnim tĂ« serverit tĂ« bazĂ«s sĂ« tĂ« dhĂ«nave ndoshta lidhet me riparimin e bazĂ«s: ndryshimin e kĂ«rkesave ndaj kufijve tĂ« burimeve sistemore dhe pastrimin e konfigurations sĂ« bazĂ«s, tĂ« cilat duhet tĂ« largohen nga direktivat e vjetruara.
Para azhurnimit, ne do të sigurohemi të konsultohemi me dokumentacionin zyrtar:
- ;
- ;
- ;
- .
Dhe do të përgatisim një plan veprimi:
- Të korrigjojmë skedarët e konfigurimit, duke hequr direktivat e vjetruara.
- Të kontrollojmë përputhshmërinë duke përdorur mjete.
- Të azhurnojmë bazat slave, duke instaluar paketën
percona-server-server. - Të azhurnojmë masterin, duke instaluar të njëjtën paketë.
Do të shqyrtojmë secilën pikë të planit dhe do të shohim se çfarë mund të shkojë keq.
E RĂNDĂSISHME! Procedura e azhurnimit tĂ« clusterit MySQL mbi bazĂ«n Galera ka nuanca tĂ« veta, tĂ« cilat nuk pĂ«rmenden nĂ« kĂ«tĂ« artikull. Mos e pĂ«rdorni kĂ«tĂ« udhĂ«zues nĂ« kĂ«tĂ« rast.
Pjesa 1: Kontrollimi i konfigurimeve
Në versionin 8 të MySQL është hequr query_cache. Në të vërtetë, ai ishte që në versionin 5.7, por tani është . Në përputhje me rrethanat, është e nevojshme të hiqen direktivat e lidhura. Ndërsa për ruajtjen e kërkesave, tani mund të përdoren mjete të jashtme - për shembull, .
Po ashtu në konfigurim u gjetën direktiva të vjetruara në lidhje me innodb_file_format. Nëse në MySQL 5.7 kishte mundësi për të zgjedhur formatin InnoDB, versioni 8 tashmë punon .
Përfundimi ynë - heqja e direktivave të mëposhtme:
-
query_cache_type,query_cache_limitdhequery_cache_size; -
innodb_file_formatdheinnodb_file_format_max.
Për verifikimin do të përdorim imazhin Docker të Percona Server. Skedari i serverit do të vendoset në direktorinë mysql_config_test, dhe pranë do të krijojmë direktori për të dhënat dhe logot. Një shembull i testit të konfigurimit 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-centosPërfundimi: ose në logot e Docker-it, ose në direktorinë me logot - në varësi të konfigurimeve tuaja - do të shfaqet një skedar, në të cilin do të përshkruhen direktivat problematike.
Këtu është çfarë patëm ne:
2020-04-03T12:44:19.670831Z 0 [Warning] [MY-011068] [Server] Sintaksa 'expire-logs-days' është e vjetruar dhe do të hiqet në një lëshim të ardhshëm. Ju lutemi përdorni binlog_expire_logs_seconds në vend. Kështu, na nevojitej gjithashtu të merremi me kodimet dhe të zëvendësonim direktivën e vjetruar expire-logs-days.
Pjesa 2: Kontrollimi i instalimeve që funksionojnë
Në dokumentacionin për azhurnimin ka 2 mjete për kontrolle të përputhshmërisë së bazës. Përdorimi i tyre ndihmon administratorin të verifikojë përputhshmërinë e strukturës së të dhënave ekzistuese.
Të fillojmë me mjetin klasik mysqlcheck. Mjafton të ekzekutohet:
mysqlcheck -u root -p --all-databases --check-upgradeNëse nuk zbulohen probleme, mjeti do të përfundojë me kodin 0:
Përveç kësaj, në versionet moderne të MySQL është në dispozicion mjeti (në rastin e Percona, kjo është paketa percona-mysql-shell). Ajo shërben si një zëvendësim për klientin klasik mysql dhe kombinon funksionet e klientit, redaktorit të kodit SQL dhe mjeteve të administratës MySQL. Për të kontrolluar serverin para azhurnimit, mund të realizoni komandën e mëposhtme përmes saj:
mysqlsh -- util check-for-server-upgrade { --user=root --host=1.1.1.1 --port=3306 } --config-path=/etc/mysql/my.cnfDhe ja çfarë vërejtëm:
Në përgjithësi, asgjë kritike - vetëm paralajmërime për kodimet. (shih më poshtë). Rezultati i përgjithshëm i ekzekutimit:
Ne vendosëm se azhurnimi duhet të shkojë pa probleme.
Paralajmërimi mbi paralajmërimet më sipër, tregon probleme me kodimet. Problemi është se UTF-8 në MySQL deri përpara pak kohësh , pasi ruante vetëm 3 byte në vend të 4. Në MySQL 8, kjo përfundimisht : aliasi utf8 shpejt do të çojë në kodimin utf8mb4, dhe kolonat e vjetra në tabela do të bëhen utf8mb3. Në të ardhmen, kodimi utf8mb3 do të hiqet, por jo në këtë lëshim. Prandaj, ne vendosëm të rregullojmë kodimet përpara se të azhurnonim instalimin aktual të DBMS.
Pjesa 3: Azhurnimi i serverëve
ĂfarĂ« mund tĂ« shkojĂ« keq, kur kemi njĂ« plan kaq tĂ« shkĂ«lqyer?... Duke e kuptuar se nuancat gjithmonĂ« ndodhin, eksperimentin e parĂ« e kryem nĂ« klasterin MySQL nĂ« dev.
Si e përmendëm më parë, shpjegon çështjen e azhurnimit të serverëve MySQL me replika. Esenca është që fillimisht duhet të azhurnohen të gjitha replikat (slave), pasi MySQL 8 mund të replikojë nga master në versionin 5.7. Disa vështirësi ndodhin sepse ne përdorim modalitetin master master, kur master-i i largët ndodhet në modalitetin read-only. Kjo do të thotë se trafiku i vërtetë po shkon në një Qendër të Dhënash (DC), ndërsa DC i dytë është rezervë.
Topologjia duket si më poshtë:
Azhurnimi duhet të fillojë me replikat mysql replica dc 2, mysql master dc 2 dhe mysql replica dc 1, dhe të përfundojë me serverin mysql master dc 1. Për më shumë siguri ndaluam makinat virtuale, bëmë snapshot-et e tyre, dhe para azhurnimit ndaluam replikimin me komandën STOP SLAVE. Përndryshe, azhurnimi duket si më poshtë:
- Ădo replikĂ« ri-fillojmĂ«, duke shtuar nĂ« konfigurime 3 opsione:
skip-networking,skip-slave-start,skip-log-bin. Rasti është se azhurnimi i bazës krijon log-et binarë me azhurnimin e tabelave sistemike. Këto drejtime garantuan që në bazë të dhënash nuk do të ketë ndryshim të të dhënave të aplikacionit, dhe informacionet për azhurnimin e tabelave sistemike nuk do të shfaqen në log-et binarë. Kjo do të shmangë probleme gjatë rihapjes së replikimit. - Instalojmë paketën
percona-server-server. ĂshtĂ« e rĂ«ndĂ«sishme tĂ« theksohet se nĂ« versionin MySQL 8 nuk duhet tĂ« ekzekutojmĂ« komandĂ«nmysqlupgradepas azhurnimit tĂ« serverit. - Pas fillimit tĂ« suksesshĂ«m, ri-fillojmĂ« serverin â tashmĂ« pa parametrat qĂ« u shtuan nĂ« pikĂ«n e parĂ«.
- Sigurohemi që replikimi funksionon me sukses: kontrollojmë
SHOW SLAVE STATUSdhe shohim që tabelat me numrat në bazën e aplikacionit po azhurnohen.
Të gjitha këto duken mjaft të thjeshta: azhurnimi i dev ka kaluar me sukses. Ok, mund të planifikojmë paqësisht azhurnimin e natës për prodhimin.
Nuk ishte ndonjĂ« shqetĂ«sim â prodhimi e kemi azhurnuar
Megjithatë, transferimi i përvojës së suksesshme nga dev në prodhim nuk shkoi pa surpriza.
Fatmirësisht, vetë procesi i azhurnimit fillon me replikat, kështu që, duke hasur vështirësi, ndaluam punimet dhe rikuperuam replikën nga snapshot-i. Hetimi i problemeve u shty për mëngjesin e ardhshëm. Në log u gjetën këto të dhëna:
2020-01-14T21:43:21.500563Z 2 [ERROR] [MY-012069] [InnoDB] tabela: t1 ka 19 kolona por fjalori InnoDB ka 20 kolona
2020-01-14T21:43:21.500722Z 2 [ERROR] [MY-010767] [Server] Gabim në rregullimin e të dhënave SE për db1.t1
2020-01-14T21:43:24.208365Z 0 [ERROR] [MY-010022] [Server] Dështoi të Popullojë tabelat DD.
2020-01-14T21:43:24.208658Z 0 [ERROR] [MY-010119] [Server] Duke abortuar Hetimi i arkivave të ndryshëm të njoftimeve në Google çoi në kuptimin se një problem i tillë ndodh për shkak të . Sidoqoftë, kjo më shumë është një bug i mjeteve mysqlcheck dhe mysqlsh.
Kështu, në MySQL kanë ndryshuar mënyrën e përfaqësimit të të dhënave për fushat decimal (int, tinyint etj.), dhe për këtë arsye brenda mysql-server përdoret një metodë tjetër e ruajtjes së tyre. Nëse baza juaj e dhënash ka qenë fillimisht në versionin 5.5 ose 5.1, dhe pastaj keni azhurnuar në 5.7, mund të jetë e nevojshme të kryeni OPTIMIZE për disa tabela. Atëherë MySQL do të azhurnojë skedarët me të dhëna, duke i kaluar në formatin e ruajtjes aktual.
Kjo gjithashtu mund të kontrollohet me mjetin mysqlfrm:
mysqlfrm --diagnostic -vv /var/lib/mysql/db/table.frm
...
'field_length': 8,
'field_type': 246, # formati i fushës
'field_type_name': 'decimal',
'flags': 3,
'flags_extra': 67,
'interval_nr': 0,
'name': 'you_deciaml_column',
... NĂ«se field_type nĂ«se ju Ă«shtĂ« e barabartĂ« me 0, atĂ«herĂ« nĂ« tabelĂ« pĂ«rdoret tipi i vjetĂ«r â duhet kryer OPTIMIZE. SidoqoftĂ«, nĂ«se vlera Ă«shtĂ« 246 â ju tashmĂ« keni tipin e ri. MĂ« shumĂ« rreth tipeve mund tĂ« lexoni nĂ« .
PĂ«r mĂ« tepĂ«r, nĂ« diskutohet njĂ« mundĂ«si tjetĂ«r e dĂ«shtimit, qĂ« na ka kaluar pa u vĂ«nĂ« re, â kjo Ă«shtĂ« mungesa e tabelave InnoDB nĂ« tabelĂ«n sistemike INNODB_SYS_TABLESPACES, nĂ«se ato, tabelat, u krijuan nĂ« versionin 5.1. PĂ«r tĂ« shmangur probleme gjatĂ« azhurnimit, mund tĂ« pĂ«rdorni .
Pse pra nuk kishim kĂ«to probleme nĂ« dev? Baza atje kopjohet periodicisht nga prodhimi â kĂ«shtu, tabelat krijohen sĂ«rish.
Fatkeqësisht, në një B.D. të madhe dhe aktive nuk mund të thoni thjesht të ekzekutoni një OPTIMIZE. Këtu ndihmon percona-toolkit: për operacionin online OPTIMIZE mjeti pt-online-schema-change është shumë i përshtatshëm.
Plani i azhurnuar u bë si më poshtë:
- Të kryejmë optimizimin e të gjitha tabelave.
- Të kryejmë azhurnimin e bazave të të dhënave.
Për ta kontrolluar atë dhe gjithashtu për të zbuluar kohën e azhurnimit, ne ndaluam një nga replikat, dhe për të gjitha tabelat ekzekutuam komandën e mëposhtme:
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=t1Përmirësimi i tabelave bëhet pa bllokime të zgjatura falë faktit se utilitari krijon një tabelë të përkohshme të re, në të cilën kopjon të dhënat nga tabela kryesore. Në momentin kur të dy tabelat janë identike, tabela origjinale bllokohet dhe zëvendësohet me të rejën. Në rastin tonë, testi tregoi se përmirësimi i të gjitha tabelave do të kërkonte rreth një ditë, por kopjimi i të dhënave shkaktonte një ngarkesë shumë të madhe në disqe.
PĂ«r tĂ« shmangur kĂ«tĂ«, nĂ« prodhim shtuam nĂ« komandĂ« argumentin --sleep me vlerĂ«n 10 â ky parametr regullon kohĂ«zgjatjen e pritjes pas transferimit tĂ« njĂ« grupi tĂ« dhĂ«nash nĂ« tabelĂ«n e re. KĂ«shtu mund tĂ« zvogĂ«lojmĂ« ngarkesĂ«n, nĂ«se aplikacioni qĂ« Ă«shtĂ« realisht nĂ« punĂ« Ă«shtĂ« kĂ«rkues ndaj kohĂ«s sĂ« pĂ«rgjigjes.
Pas përfundimit të optimizimit përmirësimi kaloi me sukses.
⊠por jo deri në fund!
Të paktën gjysmë ore pas përmirësimit, klienti erdhi me një problem. Baza punonte shumë çuditshëm: periudhësisht fillonin rëniet e lidhjeve. Kështu dukej në monitorim:
Në ekran duket një grafik i dhëmbëzuar, i lidhur me faktin se disa nga rrjedhat e serverit MySQL periudhësisht binin me një gabim. Në aplikacion shfaqeshin gabime:
[PDOException] SQLSTATE[HY000] [2002] Lidhja u refuzuaNjë inspektim i shpejtë i logave zbuloi se demon mysqld nuk mund të merrte burimet e nevojshme nga sistemi operativ. Duke u marrë me gabimet, zbuluam në sistem dosjet "të pabesueshme" të politikave 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 amd64Këto dosje u krijuan gjatë përmirësimit në MySQL 5.7 disa vite më parë dhe iu takojnë një pakoje të fshirë. Fshirja e dosjeve dhe rinisja e shërbimit apparmor zgjidhi problemin:
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 apparmorNë përfundim
Ădo operacion, edhe mĂ« i thjeshti, mund tĂ« çojĂ« nĂ« probleme tĂ« papritura. Dhe edhe prania e njĂ« plani tĂ« matur nuk garanton gjithmonĂ« rezultatin e pritur. Tani çdo plan pĂ«rmirĂ«simi qĂ« ekipi ynĂ« organzon pĂ«rfshin gjithashtu pastrimin e dosjeve tĂ« panevojshme qĂ« mund tĂ« kenĂ« dalĂ« si rezultat i veprimeve tĂ« fundit.
Me këtë krijimtari jo aq profesionale grafike do të doja të falënderoja kompaninë Percona për produktet e tyre të shkëlqyera!
P.S.
Lexoni gjithashtu në blogun tonë:
- «»;
- «»;
- «»;
- «»;
- «».
Burimi: habr.com
