🥇Ngamutahirkeun MySQL (Percona Server) tina 5.7 ka 8.0

Kamajuan teu nangtung kénéh, jadi alesan pikeun ngamutahirkeun ka versi panganyarna tina MySQL jadi beuki compelling. Teu lami pisan, dina salah sahiji proyék kami, waktosna pikeun ngapdet klaster Percona Server 5.7 anu nyaman ka versi 8. Sadaya ieu kajantenan dina platform Linux Ubuntu 16.04. Kumaha cara ngalakukeun operasi sapertos kitu kalayan downtime minimal sareng naon masalah anu kami hadapi salami pembaruan - baca dina tulisan ieu.

palatihan

Sagala apdet tina server database paling dipikaresep pakait sareng reconfiguration database: parobahan sarat pikeun wates dina sumberdaya sistem jeung koreksi configs database nu kudu diberesihan tina directives luntur.

Sateuacan ngapdet, urang pasti bakal ningali kana dokuméntasi resmi:

Sareng hayu urang ngadamel rencana aksi:

Koréksi file konfigurasi ku cara ngahapus arahan anu luntur.
Pariksa kasaluyuan sareng utiliti.
Apdet basis data budak ku cara masang pakét percona-server-server.
Apdet master sareng pakét anu sami.

Hayu urang tingali unggal titik rencana sareng tingali naon anu salah.

Penting! Prosedur pikeun ngamutahirkeun klaster MySQL dumasar kana Galera gaduh subtleties sorangan anu henteu dijelaskeun dina tulisan. Anjeun teu kedah nganggo parentah ieu dina hal ieu.

Bagian 1: Mariksa configs

MySQL dihapus dina versi 8 query_cache. Sabenerna manéhna dinyatakeun luntur deui dina versi 5.7, tapi ayeuna sagemblengna dihapus. Sasuai, perlu ngahapus arahan anu aya hubunganana. Sareng pikeun nyuhunkeun cache anjeun ayeuna tiasa nganggo alat éksternal - contona, ProxySQL.

Ogé dina config aya diréktif luntur ngeunaan innodb_file_format. Upami dina MySQL 5.7 tiasa milih format InnoDB, teras versi ka-8 parantos jalan ngan ku format Barracuda.

Hasilna kami nyaéta ngaleungitkeun arahan ieu:

query_cache_type, query_cache_limit и query_cache_size;
innodb_file_format и innodb_file_format_max.

Pikeun pariksa, urang bakal nganggo gambar Docker tina Percona Server. Urang bakal nempatkeun config server dina diréktori mysql_config_test, sareng di gigireunana urang bakal nyiptakeun diréktori pikeun data sareng log. Conto tés konfigurasi 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

Garis handap: boh dina log Docker atanapi dina diréktori kalayan log - gumantung kana configs anjeun - file bakal muncul dimana arahan masalah bakal dijelaskeun.

Ieu naon anu urang gaduh:

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.

Ku kituna, urang masih perlu angka kaluar encodings tur ngaganti diréktif luntur expire-logs-days.

Bagian 2: Mariksa pamasangan jalan

Dokuméntasi update ngandung 2 utiliti pikeun mariksa database pikeun kasaluyuan. Pamakéanna ngabantosan administrator pariksa kasaluyuan struktur data anu tos aya.

Hayu urang mimitian ku utilitas mysqlcheck klasik. Kantun ngajalankeun:

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

Upami teu aya masalah anu kapendak, utilitas bakal kaluar kalayan kode 0:

Salaku tambahan, utilitas sayogi dina vérsi modéren MySQL mysql-cangkang (dina kasus Percona ieu bungkusan percona-mysql-shell). Éta mangrupikeun gaganti pikeun klien mysql klasik sareng ngagabungkeun fungsi klien, pangropéa kode SQL sareng alat administrasi MySQL. Pikeun mariksa server sateuacan ngapdet, anjeun tiasa ngajalankeun paréntah di handap ieu:

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

Ieu koméntar anu kami tampi:

Sacara umum, euweuh kritis - ngan warnings ngeunaan encodings (tingali kahandap). Hasil palaksanaan sakabéh:

Urang mutuskeun yén update kudu indit tanpa masalah.

Catetan ngeunaan peringatan di luhur nunjukkeun masalah sareng encodings. Kanyataanna nyaéta UTF-8 dina MySQL dugi ka ayeuna éta teu "leres" UTF-8, Kusabab eta disimpen ukur 3 bait tinimbang 4. Dina MySQL 8 ieu tungtungna mutuskeun pikeun ngalereskeun eta: alias utf8 baris geura-giru ngakibatkeun coding utf8mb4, sarta kolom heubeul dina tabel bakal jadi utf8mb3. Encoding salajengna utf8mb3 bakal dihapus, tapi teu di release ieu. Ku alatan éta, urang mutuskeun pikeun ngabenerkeun encodings geus dina ngajalankeun instalasi DBMS, sanggeus ngamutahirkeun eta.

Bagian 3: Apdet Server

Naon bisa balik salah lamun aya kitu rencana pinter? .. Ngarti pinuh ogé nuances salawasna lumangsung, urang ngalaksanakeun percobaan munggaran dina MySQL dev cluster.

Sakumaha anu parantos didadarkeun, dokuméntasi resmi nyertakeun masalah ngamutahirkeun server MySQL sareng réplika. Intina nyaéta yén anjeun kedah ngapdet heula sadaya réplika (budak), sabab MySQL 8 tiasa ngayakeun réplikasi tina versi master 5.7. Sababaraha kasusah aya dina kanyataan yén kami nganggo modeu tuan tuan, lamun master jauh dina modeu maca ukur. Nyaéta, kanyataanna, lalu lintas tempur nuju ka hiji pusat data, sareng anu kadua mangrupikeun cadangan.

Topologi kasampak kawas kieu:

Pembaruan kedah dimimitian ku réplika replika mysql dc 2, mysql master dc 2 и mysql replica dc 1, sareng ditungtungan ku server mysql master dc 1. Pikeun langkung dipercaya, urang ngeureunkeun mesin virtual, nyandak snapshot di antarana, sareng langsung sateuacan pembaruan ngeureunkeun réplikasi kalayan paréntah. STOP SLAVE. Sesa pembaruan sapertos kieu:

Urang balikan deui unggal réplika ku nambihan 3 pilihan kana konfigurasi: skip-networking, skip-slave-start, skip-log-bin. Nyatana yén ngamutahirkeun pangkalan data ngahasilkeun log binér kalayan apdet kana tabel sistem. Diréktif ieu ngajamin yén moal aya parobihan kana data aplikasi dina pangkalan data, sareng inpormasi ngeunaan ngamutahirkeun tabel sistem moal dilebetkeun kana log binér. Ieu bakal ngahindarkeun masalah nalika neruskeun réplikasi.
Masang pakét percona-server-server. Kadé dicatet yén dina MySQL versi 8 teu anjeun kedah ngajalankeun paréntah mysqlupgrade sanggeus update server.
Saatos ngamimitian anu suksés, urang ngabalikan deui server - tanpa parameter anu ditambihan dina paragraf kahiji.
Urang mastikeun yén réplikasi jalan suksés: cék SHOW SLAVE STATUS tur tingal yén tabel kalawan counters dina database aplikasi diropéa.

Éta sadayana katingalina saderhana: pembaruan dev suksés. Ok, anjeun aman tiasa ngajadwalkeun update nightly pikeun produksi.

Teu aya kasedih - urang ngamutahirkeun prod

Nanging, transfer pangalaman dev anu suksés ka produksi sanés kejutan.

Untungna, prosés update sorangan dimimitian ku réplika, jadi lamun urang encountered kasusah, urang dieureunkeun karya jeung malikkeun replika ti snapshot nu. Panalungtikan ngeunaan masalah ditunda nepi ka isuk salajengna. Log ngandung éntri di handap ieu:

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

Nalungtik arsip rupa-rupa milis di Google ngarah ka pamahaman yén masalah ieu lumangsung alatan bug MySQL. Sanajan ieu leuwih gampang bug utiliti mysqlcheck и mysqlsh.

Tétéla yén MySQL ngarobah cara ngagambarkeun data pikeun widang decimal (int, tinyint, jsb), jadi mysql-server ngagunakeun cara béda pikeun nyimpen aranjeunna. Lamun database Anjeun mimitina aya dina versi 5.5 atanapi 5.1, teras anjeun diropéa ka 5.7, teras anjeun kedah ngalakukeun OPTIMIZE pikeun sababaraha tabel. Lajeng MySQL bakal ngamutahirkeun file data, mindahkeun kana format gudang ayeuna.

Anjeun oge bisa pariksa ieu kalawan utiliti 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',
...

upami field_type Upami anjeun gaduh éta sami sareng 0, maka jinis lami dianggo dina méja - anjeun kedah ngalaksanakeun OPTIMIZE. Nanging, upami nilaina 246, anjeun parantos ngagaduhan jinis énggal. Inpo nu leuwih lengkep tentang jenis bisa kapanggih dina kode.

Sumawona, di bug ieu Kami nganggap alesan kadua anu mungkin, anu ngalangkungan kami: henteuna tabel InnoDB dina tabel sistem INNODB_SYS_TABLESPACES, lamun aranjeunna, tabél, dijieun dina versi 5.1. Pikeun ngahindarkeun masalah nalika ngamutahirkeun, anjeun tiasa nganggo skrip SQL napel.

Naha urang henteu ngagaduhan masalah sapertos dina dev? Database ieu périodik disalin ti produksi - sahingga, tabél dijieun deui.

Hanjakalna, dina database ageung anu leres-leres damel, anjeun moal tiasa ngan ukur nyandak sareng ngaéksekusi universal OPTIMIZE. percona-toolkit bakal ngabantosan di dieu: pt-online-schema-change utiliti anu saé pikeun operasi OPTIMIZE online.

Rencana anu diropéa sapertos kieu:

Optimalkeun sadaya tabel.
Ngamutahirkeun basis data.

Pikeun mariksa éta sareng dina waktos anu sami milari waktos pembaruan, kami nganonaktipkeun salah sahiji réplika sareng ngajalankeun paréntah di handap ieu pikeun sadaya tabel:

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

Tabél diropéa tanpa konci anu panjang kusabab kanyataan yén utilitas nyiptakeun méja samentawis énggal dimana éta nyalin data tina méja utama. Dina momen nalika duanana tabel idéntik, tabel aslina dikonci sarta diganti ku nu anyar. Dina kasus urang, uji coba nunjukkeun yén éta bakal peryogi sadinten pikeun ngapdet sadaya tabel, tapi nyalin data nyababkeun seueur beban dina disk.

Pikeun ngahindarkeun ieu, dina produksi kami nambihan argumen kana paréntah --sleep kalawan nilai 10 - parameter ieu nyaluyukeun panjang ngantosan sanggeus mindahkeun bets data ka méja anyar. Ku cara kieu anjeun tiasa ngirangan beban upami aplikasi anu ngajalankeun saleresna nungtut waktos réspon.

Saatos ngalaksanakeun optimasi, apdet éta suksés.

... tapi teu sagemblengna!

Dina satengah jam sanggeus apdet, klien datang jeung masalah. pangkalan data digawé pisan ahéngna: périodik aranjeunna dimimitian sambungan resets. Ieu sapertos dina ngawaskeun:

Potret layar nembongkeun grafik sawtooth alatan kanyataan yén sababaraha threads server MySQL périodik nabrak kalawan kasalahan. Kasalahan muncul dina aplikasi:

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

Pamariksaan gancang tina log ngungkabkeun yén daemon mysqld henteu tiasa nampi sumber daya anu diperyogikeun tina sistem operasi. Nalika nyortir kasalahan, urang mendakan dina sistem "yatim" file kawijakan 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

Berkas ieu diciptakeun nalika ningkatkeun ka MySQL 5.7 sababaraha taun ka pengker sareng kalebet kana pakét anu dihapus. Ngahapus file sareng ngabalikan deui jasa apparmor ngarengsekeun masalah:

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

dina kacindekan

Naon waé, bahkan operasi pangbasajanna, tiasa nyababkeun masalah anu teu kaduga. Sareng gaduh rencana anu dipikiran saé henteu salawasna ngajamin hasil anu dipiharep. Ayeuna, naon waé pembaruan rencana tim kami ogé kalebet ngabersihkeun wajib file anu teu dipikabutuh anu tiasa muncul salaku hasil tina tindakan panganyarna.

Tur kalawan kreativitas grafis teu pisan profésional ieu, Abdi hoyong nyebutkeun hiji badag hatur nuhun ka Percona pikeun produk unggulan maranéhanana!

PS

Baca ogé dina blog urang:

sumber: www.habr.com

Ngamutahirkeun MySQL (Percona Server) tina 5.7 ka 8.0