Nganyari MySQL (Percona Server) saka 5.7 kanggo 8.0

Kemajuan ora mandheg, mula alasan kanggo nganyarke menyang versi paling anyar saka MySQL dadi tambah akeh. Ora suwe, ing salah sawijining proyek, wektune kanggo nganyari kluster Percona Server 5.7 sing nyaman menyang versi 8. Kabeh iki kedadeyan ing platform Ubuntu Linux 16.04. Cara nindakake operasi kasebut kanthi downtime minimal lan masalah apa sing kita temoni sajrone nganyari - maca ing artikel iki.

Latihan

Sembarang nganyari saka server database paling kamungkinan digandhengake karo reconfiguration database: owah-owahan ing syarat kanggo watesan ing sumber daya sistem lan koreksi konfigurasi database sing kudu dibusak saka arahan outdated.

Sadurunge nganyari, kita mesthi bakal ngrujuk menyang dokumentasi resmi:

• cathetan release MySQL 8;
• Pandhuan upgrade MySQL;
• Pandhuan nganyari Percona;
• Pandhuan MySQL kanggo nganyari replika lan master.

Lan ayo gawe rencana aksi:

1. Mbenerake file konfigurasi kanthi mbusak arahan sing wis lawas.
2. Priksa kompatibilitas karo keperluan.
3. Nganyari database budak kanthi nginstal paket kasebut percona-server-server.
4. Nganyari master kanthi paket sing padha.

Ayo ndeleng saben titik rencana lan ndeleng apa sing bisa salah.

PENTING! Prosedur kanggo nganyari cluster MySQL adhedhasar Galera duwe subtleties dhewe sing ora diterangake ing artikel. Sampeyan ora kudu nggunakake pandhuan iki ing kasus iki.

Part 1: Priksa configs

MySQL wis dibusak ing versi 8 query_cache. Bener dheweke nyatakake lungse bali ing versi 5.7, nanging saiki rampung dibusak. Mulane, perlu mbusak arahan sing gegandhengan. Lan kanggo panjalukan cache saiki sampeyan bisa nggunakake piranti eksternal - contone, ProxySQL.

Uga ing config ana arahan outdated babagan innodb_file_format. Yen ing MySQL 5.7 bisa milih format InnoDB, mula versi kaping 8 wis bisa digunakake mung karo format Barracuda.

Asil kita yaiku mbusak arahan ing ngisor iki:

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

Kanggo mriksa, kita bakal nggunakake gambar Docker saka Percona Server. Kita bakal nyelehake konfigurasi server ing direktori mysql_config_test, lan ing jejere kita bakal nggawe direktori kanggo data lan log. Conto tes konfigurasi server Percona:

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

Ing ngisor iki: ing log Docker utawa ing direktori kanthi log - gumantung saka konfigurasi sampeyan - file bakal katon ing ngendi arahan masalah bakal diterangake.

Punika ingkang kita gadhahi:

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.

Dadi, kita isih kudu ngerteni enkoding lan ngganti arahan sing wis lawas expire-logs-days.

Bagean 2: Priksa instalasi sing digunakake

Dokumentasi nganyari ngemot 2 utilitas kanggo mriksa kompatibilitas database. Panggunaan kasebut mbantu administrator mriksa kompatibilitas struktur data sing ana.

Ayo dadi miwiti karo utilitas mysqlcheck klasik. Cukup mbukak:

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

Yen ora ana masalah, utilitas bakal metu nganggo kode 0:

Kajaba iku, sarana kasedhiya ing versi modern MySQL mysql-shell (ing kasus Percona iki paket percona-mysql-shell). Iki minangka panggantos kanggo klien mysql klasik lan nggabungake fungsi klien, editor kode SQL lan alat administrasi MySQL. Kanggo mriksa server sadurunge nganyari, sampeyan bisa mbukak printah ing ngisor iki:

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

Mangkene komentar sing ditampa:

Umumé, ora ana sing kritis - mung peringatan babagan enkoding (ndeleng ngisor). Hasil eksekusi total:

Kita mutusake manawa nganyari kudu ditindakake tanpa masalah.

Cathetan babagan bebaya ing ndhuwur sing nuduhake masalah karo enkoding. Kasunyatane yaiku UTF-8 ing MySQL nganti saiki ora "bener" UTF-8, wiwit disimpen mung 3 bita tinimbang 4. Ing MySQL 8 iki pungkasanipun bisa mutusake kanggo ndandani: alias utf8 bakal enggal mimpin kanggo coding utf8mb4, lan kolom lawas ing tabel bakal dadi utf8mb3. Encoding luwih utf8mb3 bakal dibusak, nanging ora ing release iki. Mulane, kita mutusake kanggo mbenerake enkoding sing wis ana ing instalasi DBMS sing mlaku, sawise nganyari.

Part 3: Nganyari Server

Apa bisa dadi salah nalika ana rencana pinter kuwi?.. Understanding lengkap uga sing nuansa tansah kelakon, kita conducted eksprimen pisanan ing MySQL dev cluster.

Kaya sing wis kasebut, dokumentasi resmi nyakup masalah nganyari server MySQL kanthi replika. Ing ngisor iki sampeyan kudu nganyari kabeh replika (budak), amarga MySQL 8 bisa niru saka versi master 5.7. Sawetara kangelan dumunung ing kasunyatan sing kita nggunakake mode master master, nalika master remot ing mode maca-mung. Sing, nyatane, lalu lintas pertempuran menyang siji pusat data, lan sing nomer loro minangka cadangan.

Topologi katon kaya iki:

Nganyari kudu diwiwiti kanthi replika mysql replika dc 2, mysql master dc 2 и mysql replica dc 1, lan dipungkasi karo server mysql master dc 1. Supaya luwih dipercaya, kita mandhegake mesin virtual, njupuk jepretan mau, lan sanalika sadurunge nganyari mandheg replikasi kanthi prentah. STOP SLAVE. Sisa nganyari katon kaya iki:

1. Kita miwiti maneh saben replika kanthi nambahake 3 opsi menyang konfigurasi: skip-networking, skip-slave-start, skip-log-bin. Kasunyatane yaiku nganyari database ngasilake log binar kanthi nganyari tabel sistem. Petunjuk iki njamin ora ana owah-owahan ing data aplikasi ing basis data, lan informasi babagan nganyari tabel sistem ora bakal dilebokake ing log binar. Iki bakal nyegah masalah nalika nerusake replikasi.
2. Nginstal paket percona-server-server. Penting kanggo dicathet yen ing MySQL versi 8 ora sampeyan kudu mbukak printah mysqlupgrade sawise nganyari server.
3. Sawise wiwitan sukses, kita miwiti maneh server - tanpa parameter sing ditambahake ing paragraf pisanan.
4. Kita priksa manawa réplikasi bisa sukses: mriksa SHOW SLAVE STATUS lan ndeleng sing tabel karo counters ing database aplikasi dianyari.

Kabeh katon cukup prasaja: nganyari dev sukses. Ok, sampeyan bisa kanthi aman gawe jadwal nganyari saben wengi kanggo produksi.

Ora ana sumelang - kita nganyari prod

Nanging, transfer pengalaman dev sing sukses menyang produksi ora tanpa kejutan.

Begjanipun, proses nganyari dhewe wiwit karo replika, supaya nalika kita nemokke kangelan, kita mungkasi karya lan mulihake tiron saka gambar asli. Penyelidikan masalah kasebut ditundha nganti esuk. Log kasebut ngemot entri ing ngisor iki:

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

Nliti arsip saka macem-macem milis ing Google mimpin kanggo pangerten sing masalah iki dumadi amarga bug MySQL. Senajan iki luwih kamungkinan bug sarana mysqlcheck и mysqlsh.

Pranyata MySQL ngganti cara makili data kanggo kolom desimal (int, tinyint, lan sapiturute), mula mysql-server nggunakake cara sing beda kanggo nyimpen. Yen database sampeyan wiwitan ana ing versi 5.5 utawa 5.1, banjur sampeyan nganyari menyang 5.7, sampeyan bisa uga kudu nindakake. OPTIMIZE kanggo sawetara tabel. Banjur MySQL bakal nganyari file data, nransfer menyang format panyimpenan saiki.

Sampeyan uga bisa mriksa iki karo sarana 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',
...

yen field_type Yen sampeyan duwe padha karo 0, banjur jinis lawas digunakake ing meja - sampeyan kudu nindakake OPTIMIZE. Nanging, yen nilai 246, sampeyan wis duwe jinis anyar. Informasi liyane babagan jinis bisa ditemokake ing kode.

Menapa malih, ing bug iki Kita nimbang alasan liya sing bisa dilewati: ora ana tabel InnoDB ing tabel sistem INNODB_SYS_TABLESPACES, yen padha, tabel, digawe ing versi 5.1. Kanggo ngindhari masalah nalika nganyari, sampeyan bisa nggunakake skrip SQL sing dilampirake.

Napa kita ora duwe masalah kaya ing dev? Basis data disalin kanthi periodik saka produksi - mula, tabel digawe maneh.

Sayange, ing database gedhe tenan digunakake, sampeyan ora bakal bisa mung njupuk lan nglakokaké universal OPTIMIZE. percona-toolkit bakal mbantu ing kene: sarana pt-online-schema-change apik banget kanggo operasi OPTIMIZE online.

Rencana sing dianyari katon kaya iki:

1. Ngoptimalake kabeh tabel.
2. Nganyari database.

Kanggo mriksa lan ing wektu sing padha ngerteni wektu nganyari, kita mateni salah sawijining replika lan nglakokake perintah ing ngisor iki kanggo kabeh 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

Tabel dianyari tanpa kunci sing dawa amarga kasunyatane alat kasebut nggawe tabel sauntara anyar kanggo nyalin data saka tabel utama. Ing wayahe nalika loro tabel identik, Tabel asli dikunci lan diganti karo anyar. Ing kasus kita, uji coba nuduhake manawa butuh sedina kanggo nganyari kabeh tabel, nanging nyalin data nyebabake akeh beban ing disk.

Kanggo ngindhari iki, ing produksi kita nambahake argumentasi menyang perintah kasebut --sleep karo nilai 10 - parameter iki nyetel dawa nunggu sawise nransfer kumpulan data menyang meja anyar. Kanthi cara iki, sampeyan bisa nyuda beban yen aplikasi sing mlaku mbutuhake wektu nanggepi.

Sawise nindakake optimasi, nganyari sukses.

... nanging ora rampung!

Ing setengah jam sawise nganyari, klien teka karo masalah. Database makarya banget aneh: periodik padha miwiti sambungan ngreset. Iki katon kaya ing pemantauan:

Gambar kasebut nuduhake grafik sawtooth amarga kasunyatane sawetara utas server MySQL sacara periodik nabrak kanthi kesalahan. Kesalahan katon ing aplikasi:

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

Pemriksaan cepet saka log kasebut nuduhake manawa daemon mysqld ora bisa entuk sumber daya sing dibutuhake saka sistem operasi. Nalika ngurutake kesalahan, kita nemokake ing sistem kasebut "orphan" file kabijakan 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

File-file kasebut digawe nalika nganyarke menyang MySQL 5.7 sawetara taun kepungkur lan kalebu paket sing wis dibusak. Mbusak file lan miwiti maneh layanan apparmor ngrampungake 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

Ing kesimpulan

Apa wae, sanajan operasi sing paling gampang, bisa nyebabake masalah sing ora dikarepake. Lan sanajan duwe rencana sing dipikirake kanthi apik ora mesthi njamin asil sing dikarepake. Saiki, rencana nganyari apa wae, tim kita uga kalebu reresik wajib file sing ora perlu sing bisa uga katon minangka asil saka tumindak anyar.

Lan kanthi kreatifitas grafis sing ora profesional banget iki, aku arep ngucapake matur nuwun banget kanggo Percona kanggo produk sing apik banget!

PS

Waca uga ing blog kita:

• «Database lan Kubernetes (ringkesan lan laporan video)";
• «Tip & trik Kubernetes: nyepetake bootstrap kanggo database gedhe";
• «6 crita praktis saka urip saben dina SRE";
• «Siji crita karo operator Redis ing K8s lan mini-review keperluan kanggo nganalisa data saka database iki";
• «Migrasi lancar MongoDB menyang Kubernetes".

Source: www.habr.com