🥇Ĝisdatigante MySQL (Percona Server) de 5.7 al 8.0

Progreso ne haltas, do la kialoj por ĝisdatigi al la plej novaj versioj de MySQL fariĝas ĉiam pli konvinkaj. Antaŭ nelonge, en unu el niaj projektoj, estis tempo ĝisdatigi la komfortajn grupojn de Percona Server 5.7 al versio 8. Ĉio ĉi okazis sur la platformo Ubuntu Linukso 16.04. Kiel fari tian operacion kun minimuma malfunkcio kaj kiajn problemojn ni renkontis dum la ĝisdatigo - legu en ĉi tiu artikolo.

Trejnado

Ajna ĝisdatigo de la datumbaza servilo estas plej verŝajne rilata al datumbaza reagordo: ŝanĝoj en postuloj por limoj de sistemaj rimedoj kaj korekto de datumbazaj agordoj, kiuj devas esti forigitaj de malmodernaj direktivoj.

Antaŭ ĝisdatigo, ni certe raportos al la oficiala dokumentaro:

Kaj ni ellaboru agadplanon:

Korektu agordajn dosierojn forigante malmodernajn direktivojn.
Kontrolu kongruon kun utilecoj.
Ĝisdatigu sklavajn datumbazojn instalante la pakaĵon percona-server-server.
Ĝisdatigu la majstron per la sama pako.

Ni rigardu ĉiun punkton de la plano kaj vidu kio povus misfunkcii.

GRAVA! La proceduro por ĝisdatigi MySQL-grupon bazitan sur Galera havas siajn proprajn subtilaĵojn, kiuj ne estas priskribitaj en la artikolo. Vi ne devus uzi ĉi tiun instrukcion en ĉi tiu kazo.

Parto 1: Kontrolante agordojn

MySQL estis forigita en versio 8 query_cache. Efektive li estis deklarita malnoviĝinta reen en versio 5.7, sed nun tute forigita. Sekve, estas necese forigi la rilatajn direktivojn. Kaj por konservi petojn vi nun povas uzi eksterajn ilojn - ekzemple, ProxySQL.

Ankaŭ en la agordo estis malnoviĝintaj direktivoj pri innodb_file_format. Se en MySQL 5.7 eblis elekti la InnoDB-formaton, tiam jam funkcias la 8-a versio nur kun formato Barracuda.

Nia rezulto estas la forigo de la sekvaj direktivoj:

query_cache_type, query_cache_limit и query_cache_size;
innodb_file_format и innodb_file_format_max.

Por kontroli, ni uzos la Docker-bildon de Percona Server. Ni metos la servilon agordon en la dosierujon mysql_config_test, kaj apud ĝi ni kreos dosierujojn por datumoj kaj protokoloj. Ekzemplo de prova agordo de Percona-servilo:

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

Malsupra linio: ĉu en la Docker-protokoloj aŭ en la dosierujo kun la protokoloj - depende de viaj agordoj - aperos dosiero en kiu la problemaj direktivoj estos priskribitaj.

Jen kion ni havis:

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.

Tiel, ni ankoraŭ bezonis eltrovi la kodadojn kaj anstataŭigi la malmodernan direktivon expire-logs-days.

Parto 2: Kontrolado de funkciaj instalaĵoj

La ĝisdatiga dokumentaro enhavas 2 ilojn por kontroli la datumbazon por kongruo. Ilia uzo helpas la administranton kontroli la kongruon de la ekzistanta datumstrukturo.

Ni komencu per la klasika mysqlcheck ilo. Simple kuru:

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

Se neniuj problemoj estas trovitaj, la ilo eliros kun kodo 0:

Krome, ilo disponeblas en modernaj versioj de MySQL mysql-ŝelo (en la kazo de Percona ĉi tio estas la pakaĵo percona-mysql-shell). Ĝi estas anstataŭaĵo por la klasika mysql-kliento kaj kombinas la funkciojn de kliento, SQL-kodredaktilo kaj MySQL-administrado-iloj. Por kontroli la servilon antaŭ ĝisdatigi, vi povas ruli la jenajn komandojn per ĝi:

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

Jen la komentoj, kiujn ni ricevis:

Ĝenerale, nenio kritika - nur avertoj pri kodigoj (Vidu suben). Totala ekzekutrezulto:

Ni decidis, ke la ĝisdatigo estu senprobleme.

Noto pri la supraj avertoj indikante problemojn kun kodigoj. La fakto estas, ke UTF-8 en MySQL ĝis lastatempe ne estis "vera" UTF-8, ĉar ĝi stokis nur 3 bajtojn anstataŭ 4. En MySQL 8 tio estas finfine decidis ripari ĝin: kaŝnomo utf8 baldaŭ kondukos al kodigo utf8mb4, kaj la malnovaj kolumnoj en la tabeloj fariĝos utf8mb3. Plia kodado utf8mb3 estos forigita, sed ne en ĉi tiu eldono. Tial ni decidis korekti la kodadojn jam sur la funkcianta DBMS-instalaĵo, post ĝisdatigi ĝin.

Parto 3: Servilaj Ĝisdatigoj

Kio povus misfunkcii kiam ekzistas tia inteligenta plano?... Komprenante bone, ke nuancoj ĉiam okazas, ni faris la unuan eksperimenton pri MySQL-dev-grupo.

Kiel jam menciite, oficiala dokumentaro kovras la aferon de ĝisdatigo de MySQL-serviloj per kopioj. La fundo estas, ke vi unue devas ĝisdatigi ĉiujn kopiojn (sklavoj), ĉar MySQL 8 povas reprodukti de majstra versio 5.7. Iu malfacilaĵo kuŝas en la fakto, ke ni uzas la reĝimon majstro <-> majstro, kiam la fora majstro estas en reĝimo nurlegebla. Tio estas, fakte, bataltrafiko iras al unu datumcentro, kaj la dua estas rezerva.

La topologio aspektas jene:

La ĝisdatigo devas komenciĝi per kopioj mysql kopio dc 2, mysql majstro dc 2 и mysql replica dc 1, kaj finiĝas per la servilo mysql master dc 1. Por esti pli fidindaj, ni haltigis la virtualajn maŝinojn, prenis momentfotojn de ili, kaj tuj antaŭ la ĝisdatigo ĉesis reproduktadon per la komando. STOP SLAVE. La resto de la ĝisdatigo aspektas jene:

Ni rekomencas ĉiun kopion aldonante 3 opciojn al la agordoj: skip-networking, skip-slave-start, skip-log-bin. La fakto estas, ke ĝisdatigi la datumbazon generas binarajn protokolojn kun ĝisdatigoj al sistemaj tabeloj. Ĉi tiuj direktivoj garantias, ke ne estos ŝanĝoj al aplikaj datumoj en la datumbazo, kaj informoj pri ĝisdatigo de sistemaj tabeloj ne estos inkluzivitaj en la binaraj protokoloj. Ĉi tio evitos problemojn dum rekomencado de reproduktado.
Instalante la pakaĵon percona-server-server. Gravas noti, ke en MySQL-versio 8 ne vi devas ruli la komandon mysqlupgrade post servila ĝisdatigo.
Post sukcesa komenco, ni rekomencas la servilon - sen la parametroj aldonitaj en la unua alineo.
Ni certigas, ke reproduktado funkcias sukcese: kontrolu SHOW SLAVE STATUS kaj vidu, ke la tabeloj kun nombriloj en la aplika datumbazo estas ĝisdatigitaj.

Ĉio aspektas sufiĉe simpla: la dev-ĝisdatigo sukcesis. Bone, vi povas sekure plani noktan ĝisdatigon por produktado.

Ne estis malĝojo - ni ĝisdatigis la prod

Tamen, la translokigo de sukcesa dev-sperto al produktado ne estis sen surprizoj.

Feliĉe, la ĝisdatiga procezo mem komenciĝas per kopioj, do kiam ni renkontis malfacilaĵojn, ni ĉesigis la laboron kaj restarigis la kopion de la momentfoto. La esploro de la problemoj estis prokrastita ĝis la sekva mateno. La protokoloj enhavis la sekvajn enskribojn:

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

Esplorado de la arkivoj de diversaj dissendolistoj en Guglo kondukis al la kompreno, ke ĉi tiu problemo okazas pro MySQL-cimo. Kvankam ĉi tio estas pli verŝajne utila cimo mysqlcheck и mysqlsh.

Montriĝas, ke MySQL ŝanĝis la manieron kiel ili reprezentas datumojn por dekumaj kampoj (int, tinyint, ktp.), do mysql-servilo uzas alian manieron konservi ilin. Se via datumbazo komence estis en versio 5.5 aŭ 5.1, kaj tiam vi ĝisdatigis al 5.7, tiam vi eble devos fari OPTIMIZE por kelkaj tabloj. Tiam MySQL ĝisdatigos la datumdosierojn, transdonante ilin al la nuna stoka formato.

Vi ankaŭ povas kontroli ĉi tion per la ilo 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',
...

se field_type Se vi havas ĝin egala al 0, tiam la malnova tipo estas uzata en la tabelo - vi devas plenumi OPTIMIZE. Tamen, se la valoro estas 246, vi jam havas novan tipon. Pliaj informoj pri la tipoj troveblas en kodo.

Cetere en ĉi tiu cimo Ni pripensas la duan eblan kialon, kiu preteriris nin: la foresto de InnoDB-tabeloj en la sistema tablo. INNODB_SYS_TABLESPACES, se ili, tabeloj, estis kreitaj en versio 5.1. Por eviti problemojn dum ĝisdatigo, vi povas uzi ligita SQL-skripto.

Kial ni ne havis tiajn problemojn ĉe dev? La datumbazo estas periode kopiita tie de produktado - tiel, tabloj estas rekreitaj.

Bedaŭrinde, sur vere funkcianta granda datumbazo, vi ne povos simple preni kaj efektivigi universalan OPTIMIZE. percona-toolkit helpos ĉi tie: la ilo pt-online-schema-change estas bonega por la interreta operacio OPTIMIZE.

La ĝisdatigita plano aspektis jene:

Optimumigu ĉiujn tabelojn.
Ĝisdatigu la datumbazojn.

Por kontroli ĝin kaj samtempe ekscii la ĝisdatigon, ni malŝaltis unu el la kopioj kaj kuris la jenan komandon por ĉiuj tabeloj:

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

Tabeloj estas ĝisdatigitaj sen longaj seruroj pro la fakto ke la ilo kreas novan provizoran tabelon en kiun ĝi kopias datumojn de la ĉefa tabelo. En la momento kiam ambaŭ tabloj estas identaj, la origina tablo estas ŝlosita kaj anstataŭigita per la nova. En nia kazo, prova ekzekuto montris, ke necesas ĉirkaŭ unu tago por ĝisdatigi ĉiujn tabelojn, sed kopii datumojn kaŭzis tro da ŝarĝo sur la diskoj.

Por eviti ĉi tion, en produktado ni aldonis la argumenton al la komando --sleep kun valoro de 10 - ĉi tiu parametro ĝustigas la atendan longon post translokigo de aro da datumoj al nova tablo. Tiel vi povas redukti la ŝarĝon se la efektiva funkcianta aplikaĵo postulas respondan tempon.

Post plenumi la optimumigon, la ĝisdatigo sukcesis.

... sed ne tute!

Ene de duonhoro post la ĝisdatigo, la kliento venis kun problemo. La datumbazo funkciis tre strange: periode ili komenciĝis konekto rekomenciĝas. Jen kiel ĝi aspektis en monitorado:

La ekrankopio montras segildentan grafikon pro la fakto, ke iuj el la MySQL-servilaj fadenoj periode kraŝis pro eraro. Eraroj aperis en la aplikaĵo:

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

Rapida inspektado de la protokoloj malkaŝis, ke la mysqld-demono ne povis akiri la postulatajn rimedojn de la operaciumo. Dum ordigo de eraroj, ni malkovris en la sistemo "orfaj" aparadaj politikaj dosieroj:

# 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

Ĉi tiuj dosieroj estis kreitaj dum ĝisdatigo al MySQL 5.7 antaŭ kelkaj jaroj kaj apartenas al forigita pako. Forigi la dosierojn kaj rekomenci la apparmor-servon solvis la problemon:

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

En konkludo

Ajna, eĉ la plej simpla operacio, povas konduki al neatenditaj problemoj. Kaj eĉ havi bone pripensitan planon ne ĉiam garantias la atendatan rezulton. Nun, ĉiuj ĝisdatigaj planoj kiujn nia teamo havas ankaŭ inkluzivas la devigan purigadon de nenecesaj dosieroj, kiuj povus aperi kiel rezulto de lastatempaj agoj.

Kaj kun ĉi tiu ne tre profesia grafika kreivo, mi ŝatus diri grandegan dankon al Percona pro iliaj bonegaj produktoj!

PS

Legu ankaŭ en nia blogo:

fonto: www.habr.com

Ĝisdatigante MySQL (Percona Server) de 5.7 ĝis 8.0