Progresi nuk ndalet, prandaj arsyet për t'u përditësuar në versionet më të fundit të MySQL po bëhen gjithnjë e më të rëndësishme. Nuk është shumë kohë që në një nga projektet tona erdhi koha të përditësojmë klasterët e rehatshëm të Percona Server 5.7 në versionin 8. Të gjitha këto ndodhën në platformën Ubuntu Linux 16.04. Si ta kryejmë një operacion të tillë me minimumin e ndërprerjeve dhe me cilat probleme u përballëm gjatë përditësimit - lexoni në këtë artikull.
PĂ«rgatitja
Ădo pĂ«rditĂ«sim i serverit tĂ« bazĂ«s sĂ« tĂ« dhĂ«nave ndoshta lidhet me rikonfigurimin e bazĂ«s: ndryshim tĂ« kĂ«rkesave pĂ«r kufijtĂ« e burimeve sistemore dhe rregullimin e konfigurimeve tĂ« bazĂ«s, tĂ« cilat duhet tĂ« pastrohen nga direktivat e vjetruara.
Para përditësimit ne do t'u drejtohemi patjetër dokumentacionit zyrtar:
- ;
- ;
- ;
- .
Dhe do të hartojmë një plan veprimi:
- Të korrigjohen skedarët e konfigurimit, duke hequr direktivat e vjetruara.
- TĂ« kontrollohet kompatibiliteti me mjete.
- Të përditësohen bazat slave, duke instaluar paketën
percona-server-server. - Të përditësohet maestro, duke instaluar të njëjtën paketë.
Le të shqyrtojmë çdo pikë në plan dhe të shohim se çfarë mund të shkojë gabim.
E RĂNDĂSISHME! Procedura e pĂ«rditĂ«simit tĂ« klasterit MySQL mbi bazĂ«n e Galera ka nuanca tĂ« veta, tĂ« cilat nuk pĂ«rmenden nĂ« kĂ«tĂ« artikull. Nuk Ă«shtĂ« e rekomanduar tĂ« pĂ«rdorim kĂ«tĂ« udhĂ«zues nĂ« kĂ«tĂ« rast.
Pjesa 1: Kontrolli 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ë . Si pasojë, është e nevojshme të hiqen direktivat e lidhura. Dhe për kërkimet tani mund të përdoren mjete të jashtme - për shembull, .
Po ashtu në konfigurim u gjetën direktiva të vjetruara për innodb_file_format. Nëse në MySQL 5.7 kishte mundësi për të zgjedhur formatin InnoDB, versioni 8 tani funksionon .
Përmbledhja jonë - heqja e direktivave të mëposhtme:
-
query_cache_type,query_cache_limitdhequery_cache_size; -
innodb_file_formatdheinnodb_file_format_max.
Për kontroll do të përdorim një imazh Docker të Percona Server. Konfigurimi i serverit do të vendoset në drejtorinë mysql_config_test, dhe pranë do të krijojmë drejtoritë për të dhënat dhe logët. 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Ă«rfundim: ose nĂ« logun e Docker, ose nĂ« direktorinĂ« e logĂ«ve â nĂ« varĂ«si tĂ« konfigurimeve tuaja â do tĂ« shfaqet njĂ« skedar qĂ« pĂ«rshkruan direktivat problematike.
Këtu është ajo që kishim:
2020-04-03T12:44:19.670831Z 0 [Kujdes] [MY-011068] [Server] Sintaksa 'expire-logs-days' është e vjetruar dhe do të hiqet në një version të ardhshëm. Ju lutemi përdorni binlog_expire_logs_seconds në vend të saj.
2020-04-03T12:44:19.671678Z 0 [Kujdes] [MY-013242] [Server] --character-set-server: 'utf8' aktualisht është një alias për grupin e karaktereve UTF8MB3, por do të jetë një alias për UTF8MB4 në një version të ardhshëm. Ju lutemi shqyrtoni përdorimin e UTF8MB4 për të qenë të qartë.
2020-04-03T12:44:19.671682Z 0 [Kujdes] [MY-013244] [Server] --collation-server: 'utf8_general_ci' është një renditje e grupit të karaktereve të vjetruar UTF8MB3. Ju lutemi shqyrtoni përdorimin e UTF8MB4 me një renditje të përshtatshme në vend të saj. Prandaj, na nevojitej të merreshim edhe me kodimet dhe të zëvendësonim direktivën e vjetruar expire-logs-days.
Pjesa 2: Kontrollimi i instalimeve që punojnë
Në dokumentacionin për përditësimin ka 2 utilitete për të kontrolluar përputhshmërinë e bazës. Përdorimi i tyre ndihmon administratorin të verifikojë përputhshmërinë e strukturës ekzistuese të të dhënave.
Le të fillojmë me utilitetin klasik mysqlcheck. Mjafton ta ekzekutoni:
mysqlcheck -u root -p --all-databases --check-upgradeNëse nuk shqetësohen probleme, utiliteti do të përfundojë me kodin 0:
Për më tepër, në versionet moderne të MySQL është në dispozicion utiliteti (në rastin e Percona kjo është paketa percona-mysql-shell). Ai është një zëvendësim për klientin klasik mysql dhe kombinon funksionet e klientit, redaktorit të kodit SQL dhe mjeteve të administrimit të MySQL. Për kontrollin e serverit para përditësimit, mund të ekzekutoni komandën e mëposhtme përmes tij:
mysqlsh -- util check-for-server-upgrade { --user=root --host=1.1.1.1 --port=3306 } --config-path=\/etc\/mysql\/my.cnfDhe këto janë vërejtjet që morëm:
NĂ« pĂ«rgjithĂ«si, asgjĂ« kritike â vetĂ«m paralajmĂ«rime pĂ«r kodet e karaktereve (shih mĂ« poshtĂ«). Rezultati i pĂ«rgjithshĂ«m i ekzekutimit:
Ne vendosëm se përditësimi duhet të kalojë pa probleme.
Vërejtja për paralajmërimet e mësipërme, që tregojnë probleme me kodet e karaktereve. E vërteta është se UTF-8 në MySQL deri kohët e fundit , pasi ruante vetëm 3 byte në vend të 4. Në MySQL 8 kjo më në fund : alias utf8 shumë shpejt do të çojë në kodimin utf8mb4, ndërsa kolonat e vjetra në tabelat do të bëhen utf8mb3. Në të ardhmen, kodimi utf8mb3 do të hiqet, por jo në këtë version. Prandaj, ne vendosëm të rregullojmë kodimet në një instalim të funksionshëm të DBMS, pas përditësimit të saj.
Pjesa 3: Përditësimi i serverëve
ĂfarĂ« mund tĂ« shkojĂ« keq, kur kemi njĂ« plan kaq tĂ« shkĂ«lqyer?.. Duke kuptuar mirĂ« se nuancat ndodhin gjithmonĂ«, eksperimentin e parĂ« e kryem nĂ« klasterin dev tĂ« MySQL.
Siç u përmend tashmë, shpjegon çështjen e përditësimit të serverëve MySQL me replika. Thelbi i çështjes është se së pari duhet përditësuar të gjitha replikat (slave), pasi MySQL 8 mund të replikojë nga masteri versioni 5.7. Disa vështirësi qëndrojnë në faktin se ne përdorim modin master master, kur masteri i largët është në modalitetin read-only. Kështu, fakti është që trafiku operativ shkon në një Qendër të Dhënash, ndërsa e dyta është rezervë.
Topologjia duket si në vijim:
Përditësimi 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 sigurinë e shtuar, ndaluam makinat virtuale, bëmë snapshotet dhe para përditësimit ndaluam replikimin me komandën STOP SLAVE. Përndryshe, përditësimi duket kështu:
- Ădo replikĂ« rinisim, duke shtuar nĂ« konfigurimet 3 opsione:
skip-networking,skip-slave-start,skip-log-bin. ĂĂ«shtja Ă«shtĂ« se pĂ«rditĂ«simi i bazĂ«s gjeneron logje binarĂ« me pĂ«rditĂ«simin e tabelave sistematike. KĂ«to direktiva garantojnĂ« qĂ« nĂ« bazĂ« tĂ« dhĂ«nash nuk do tĂ« ketĂ« ndryshime tĂ« tĂ« dhĂ«nave tĂ« aplikacionit, dhe informacioni pĂ«r pĂ«rditĂ«simin e tabelave sistematike nuk do tĂ« ketĂ« nĂ« logjet binarĂ«. Kjo do tĂ« ndihmojĂ« nĂ« shmangien e problemeve gjatĂ« rinisjes sĂ« replikimit. - InstalojmĂ« paketĂ«n
percona-server-server. ĂshtĂ« e rĂ«ndĂ«sishme tĂ« theksohet se nĂ« versionin MySQL 8 jo duhet tĂ« ekzekutojmĂ« komandĂ«nmysqlupgradepas pĂ«rditĂ«simit tĂ« serverit. - Pas nisjes me sukses, e rinisim serverin - tashmĂ« pa parametrat, qĂ« u shtuan nĂ« pikĂ«n e parĂ«.
- Sigurohemi që replikimi funksionon me sukses: kontrollojmë
SHOW SLAVE STATUSdhe shikojmë se tabelat me numërues në bazën e aplikacionit përditësohen.
Të gjitha këto duken mjaft të thjeshta: përditësimi i dev kaloi me sukses. Mirë, mund të planenim qetësisht përditësimin e natës për production.
Nuk pati mërzitje - prodhim ne përditësuam
Megjithatë, transferimi i eksperiencës së suksesshme nga dev në production nuk kaloi pa surpriza.
Fatmirësisht, vetë procesi i përditësimit fillon me replikat, prandaj, duke u përballur me vështirësi, ndaluam punën dhe rikthyem replikën nga snapshot-i. Hulumtimi i problemeve u tejkalua deri në mëngjesin e nesërm. Në logje u gjetën këto regjistra:
2020-01-14T21:43:21.500563Z 2 [ERROR] [MY-012069] [InnoDB] tabela: t1 ka 19 kolona, por InnoDB dictionary 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 në mbushjen e tabelave DD.
2020-01-14T21:43:24.208658Z 0 [ERROR] [MY-010119] [Server] Po abortohet Hetimi i arkivave të ndryshme të dërgesave me postë në Google ka çuar në kuptimin se ky problem ndodh për shkak të . Megjithatë, ndoshta është edhe një gabim i mjeteve mysqlcheck dhe mysqlsh.
Duket se në MySQL është ndryshuar mënyra e paraqitjes së të dhënave për fushat dekimale (int, tinyint etj.), prandaj brenda mysql-server përdoret një mënyrë tjetër e ruajtjes së tyre. Nëse databaza juaj fillimisht ka qenë në versionin 5.5 ose 5.1, dhe pastaj jeni azhurnuar në 5.7, atëherë ndoshta duhet të bëni OPTIMIZE për disa tabela. Atëherë MySQL do të përditësojë skedarët me të dhëna, duke i transferuar ato në formatin aktual të ruajtjes.
Gjithashtu, kjo mund të kontrollohet me mjete 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 Ă«shtĂ« 0, atĂ«herĂ« tabela pĂ«rdor tipin e vjetĂ«r â duhet tĂ« kryhen OPTIMIZE. MegjithatĂ«, nĂ«se vlera Ă«shtĂ« 246 â ju tani keni tipin e ri. MĂ« shumĂ« rreth tipeve mund tĂ« gjendet nĂ« .
PĂ«r mĂ« tepĂ«r, nĂ« diskutohet njĂ« shkak tjetĂ«r i mundshĂ«m, qĂ« na ka anashkaluar, â Ă«shtĂ« mungesa e tabelave InnoDB nĂ« tabelĂ«n sistematike INNODB_SYS_TABLESPACES, nĂ«se ato, tabelat, janĂ« krijuar nĂ« versionin 5.1. PĂ«r tĂ« shmangur probleme gjatĂ« azhurnimit, mund tĂ« pĂ«rdorni .
Pse nuk nashtur probleme tĂ« tilla nĂ« dev? Baza aty kopjohet periodikisht nga prodhimi â kĂ«shtu, tabelat rindĂ«rtohen.
Fatkeqësisht, në një DB të madhe që është në funksion, nuk do të funksionojë thjesht të merrni dhe të kryeni një OPTIMIZE. Këtu ndihmon percona-toolkit: për operacionin online OPTIMIZE, mjeti pt-online-schema-change është krejt i përshtatshëm.
Plani i përditësuar u krijua si vijon:
- Kryeni optimizimin e të gjithë tabelave.
- Kryeni përditësimin e databazave.
Për ta testuar dhe për njëkohësisht për të zbuluar kohën e përditësimit, kemi fikur një nga replikat, dhe për të gjitha tabelat e kemi ekzekutuar 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ërditësimi i tabelave bëhet pa bllokime të gjata falë faktit se utilitarja krijon një tabelë përkohësore 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 atë të re. Në rastin tonë, testi tregoi se për të përditësuar të gjitha tabelat do të nevojiten rreth një ditë, por në këtë mënyrë kopjimi i të dhënave shkaktonte një ngarkesë shumë të madhe në disqe.
Për ta shmangur këtë, në produkcion kemi shtuar argumentin e komandës --sleep me vlerën 10 - ky parametr rregullon kohëzgjatjen e pritjes pas transferimit të një grupi të dhënash në tabelën e re. Kështu mund të reduktohet ngarkesa, nëse aplikacioni aktual është kërkesës kërkuese për kohën e përgjigjës.
Pas përfundimit të optimizimit, përditësimi shkoi me sukses.
⊠por jo deri në fund!
Këtu, vetëm gjysmë ore pas përditësimit, klienti erdhi me një problem. Baza po punonte shumë çuditshëm: periodikisht fillonin rëniet e lidhjeve. Kështu dukej në monitorim:
Në screenshot përmendet një grafik me formë sawtooth, i lidhur me faktin se një pjesë e rrjedhave të serverit MySQL rënin periodikisht me gabim. U shfaqën gabime në aplikacion:
[PDOException] SQLSTATE[HY000] [2002] Lidhja u refuzuaNjë shqyrtim i shpejtë i logeve zbuloi se demon mysqld nuk mund të merrte burimet e nevojshme nga sistemi operativ. Duke u marrë me gabimet, zbuluam në sistem skedarë të politikave apparmor "të braktisura":
# 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ëta skedarë u formuan gjatë përditësimit në MySQL 5.7 para disa vitesh dhe i përkasin një pakete të hequr. Fshirja e skedarëve 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, madje edhe ai mĂ« i thjeshtĂ«, mund tĂ« shkaktojĂ« probleme tĂ« papritura. Dhe madje edhe prania e njĂ« plani tĂ« menduar nuk garanton gjithmonĂ« rezultatet e pritura. Tani, nĂ« çdo plan pĂ«rditĂ«simi, ekipi ynĂ« pĂ«rfshin gjithashtu pastrimin e skedarĂ«ve tĂ« panevojshĂ«m qĂ« mund tĂ« jenĂ« shfaqur si rezultat i veprimeve tĂ« fundit.
Dhe me këtë krijimtari të paprofesionalit do të doja të shprehja një falënderim të madh kompanisë Percona për produktet e tyre të shkëlqyera!
P.S.
Lexoni gjithashtu në blogun tonë:
- «»;
- «»;
- «»;
- «»;
- «».
Burimi: habr.com
