ProHoster > Blogs > Administrācija > MySQL (Percona Server) atjaunināŔana no 5.7 uz 8.0

MySQL (Percona Server) atjaunināŔana no 5.7 uz 8.0

MySQL (Percona Server) atjaunināŔana no 5.7 uz 8.0

Progress nestāv uz vietas, tāpēc iemesli jaunināŔanai uz jaunākajām MySQL versijām kļūst arvien pārliecinoŔāki. Pirms neilga laika vienā no mÅ«su projektiem bija pienācis laiks atjaunināt mājÄ«gos Percona Server 5.7 klasterus uz 8. versiju. Tas viss notika Ubuntu Linux 16.04 platformā. Kā veikt Ŕādu darbÄ«bu ar minimālu dÄ«kstāvi un ar kādām problēmām saskārāmies atjaunināŔanas laikā - lasiet Å”ajā rakstā.

TreniņŔ

JebkurÅ” datu bāzes servera atjauninājums, visticamāk, ir saistÄ«ts ar datu bāzes pārkonfigurāciju: izmaiņām sistēmas resursu ierobežojumu prasÄ«bās un datu bāzes konfigurāciju laboÅ”anu, kas jāatbrÄ«vo no novecojuŔām direktÄ«vām.

Pirms atjaunināŔanas mēs noteikti atsauksimies uz oficiālo dokumentāciju:

Un sastādīsim rīcības plānu:

  1. Labojiet konfigurācijas failus, noņemot novecojuÅ”as direktÄ«vas.
  2. Pārbaudiet saderību ar komunālajiem pakalpojumiem.
  3. Atjauniniet vergu datu bāzes, instalējot pakotni percona-server-server.
  4. Atjauniniet galveno, izmantojot to paŔu pakotni.

Apskatīsim katru plāna punktu un redzēsim, kas varētu noiet greizi.

SVARÄŖGI! Uz Galera balstÄ«ta MySQL klastera atjaunināŔanas procedÅ«rai ir savi smalkumi, kas rakstā nav aprakstÄ«ti. Å ajā gadÄ«jumā jums nevajadzētu izmantot Å”o instrukciju.

1. daļa: konfigurāciju pārbaude

MySQL tika noņemts 8. versijā query_cache. PatiesÄ«bā viņŔ bija pasludināts par novecojuÅ”u atpakaļ versijā 5.7, bet tagad pilnÄ«bā izdzēsts. AttiecÄ«gi ir jāsvÄ«tro saistÄ«tās direktÄ«vas. Un pieprasÄ«jumu saglabāŔanai keÅ”atmiņā tagad varat izmantot ārējos rÄ«kus, piemēram, ProxySQL.

ArÄ« konfigurācijā bija novecojuÅ”as direktÄ«vas par innodb_file_format. Ja MySQL 5.7 bija iespēja izvēlēties InnoDB formātu, tad jau darbojas 8. versija tikai ar Barracuda formātu.

MÅ«su rezultāts ir Ŕādu direktÄ«vu noņemÅ”ana:

  • query_cache_type, query_cache_limit Šø query_cache_size;
  • innodb_file_format Šø innodb_file_format_max.

Lai pārbaudītu, mēs izmantosim Percona Server Docker attēlu. Mēs ievietosim servera konfigurāciju direktorijā mysql_config_test, un blakus izveidosim datu un žurnālu katalogus. Percona servera konfigurācijas testa piemērs:

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

ApakŔējā rinda: vai nu Docker žurnālos, vai direktorijā ar žurnāliem ā€” atkarÄ«bā no jÅ«su konfigurācijām ā€” tiks parādÄ«ts fails, kurā tiks aprakstÄ«tas problemātiskās direktÄ«vas.

LÅ«k, kas mums bija:

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.

Tādējādi mums joprojām bija jāizdomā kodējumi un jāaizstāj novecojusi direktīva expire-logs-days.

2. daļa: Darba instalāciju pārbaude

AtjaunināŔanas dokumentācijā ir 2 utilītas datu bāzes saderības pārbaudei. To izmantoŔana palīdz administratoram pārbaudīt esoŔās datu struktūras saderību.

Sāksim ar klasisko mysqlcheck utilītu. VienkārŔi palaist:

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

Ja problēmas netiek atrastas, utilīta tiks aizvērta ar kodu 0:

MySQL (Percona Server) atjaunināŔana no 5.7 uz 8.0

Turklāt modernajās MySQL versijās ir pieejama utilÄ«ta mysql-shell (Percona gadÄ«jumā tas ir iepakojums percona-mysql-shell). Tas aizstāj klasisko mysql klientu un apvieno klienta funkcijas, SQL koda redaktoru un MySQL administrÄ“Å”anas rÄ«kus. Lai pārbaudÄ«tu serveri pirms atjaunināŔanas, caur to varat palaist Ŕādas komandas:

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

Šeit ir saņemtie komentāri:

MySQL (Percona Server) atjaunināŔana no 5.7 uz 8.0

Vispār nekas kritisks - tikai brīdinājumi par kodējumiem (Skatīt zemāk). Kopējais izpildes rezultāts:

MySQL (Percona Server) atjaunināŔana no 5.7 uz 8.0

Mēs nolēmām, ka atjauninājumam vajadzētu notikt bez problēmām.

PiezÄ«me par iepriekÅ” minētajiem brÄ«dinājumiem, kas norāda uz problēmām ar kodējumu. Fakts ir tāds, ka MySQL UTF-8 vēl nesen nebija "patiess" UTF-8, jo tajā tika saglabāti tikai 3 baiti, nevis 4. MySQL 8 tas beidzot ir nolēma to salabot: aizstājvārds utf8 drÄ«z novedÄ«s pie kodÄ“Å”anas utf8mb4, un vecās kolonnas tabulās kļūs utf8mb3. Tālāka kodÄ“Å”ana utf8mb3 tiks noņemts, bet ne Å”ajā laidienā. Tāpēc mēs nolēmām labot kodējumus jau darboÅ”ajā DBVS instalācijā pēc tās atjaunināŔanas.

3. daļa: Serveru atjauninājumi

Kas var noiet greizi, ja ir tik gudrs plāns?.. Labi saprotot, ka nianses vienmēr notiek, mēs veicām pirmo eksperimentu MySQL izstrādātāju klasterī.

Kā jau minēts, oficiālā dokumentācija attiecas uz MySQL serveru atjaunināŔanu ar replikām. BÅ«tÄ«ba ir tāda, ka vispirms ir jāatjaunina visas kopijas (vergu), jo MySQL 8 var replicēt no galvenās versijas 5.7. Dažas grÅ«tÄ«bas rada fakts, ka mēs izmantojam režīmu meistars <-> meistars, kad tālvadÄ«bas pults ir režīmā tikai lasāms. Tas ir, faktiski kaujas trafika iet uz vienu datu centru, bet otrais ir rezerves.

Topoloģija izskatās Ŕādi:

MySQL (Percona Server) atjaunināŔana no 5.7 uz 8.0

AtjaunināŔanai jāsākas ar replikām mysql replica dc 2, mysql master dc 2 Šø mysql replica dc 1, un beidzas ar mysql master dc 1 serveri. Lai nodroÅ”inātu lielāku uzticamÄ«bu, mēs apturējām virtuālās maŔīnas, uzņēmām to momentuzņēmumus un tieÅ”i pirms atjaunināŔanas apturējām replikāciju ar komandu STOP SLAVE. Pārējais atjauninājums izskatās Ŕādi:

  1. Mēs restartējam katru reprodukciju, pievienojot 3 opcijas konfigurācijām: skip-networking, skip-slave-start, skip-log-bin. Fakts ir tāds, ka datu bāzes atjaunināŔana Ä£enerē bināros žurnālus ar sistēmas tabulu atjauninājumiem. Å Ä«s direktÄ«vas garantē, ka datu bāzē netiks veiktas izmaiņas lietojumprogrammu datos, un informācija par sistēmas tabulu atjaunināŔanu netiks iekļauta binārajos žurnālos. Tas ļaus izvairÄ«ties no problēmām, atsākot replikāciju.
  2. Pakotnes instalÄ“Å”ana percona-server-server. Ir svarÄ«gi atzÄ«mēt, ka MySQL versijā 8 nē jums ir jāpalaiž komanda mysqlupgrade pēc servera atjaunināŔanas.
  3. Pēc veiksmÄ«ga starta mēs restartējam serveri vēlreiz ā€“ bez tiem parametriem, kas tika pievienoti pirmajā rindkopā.
  4. Mēs pārliecināmies, ka replikācija darbojas veiksmīgi: pārbaudiet SHOW SLAVE STATUS un redzēt, ka tiek atjauninātas tabulas ar skaitītājiem lietojumprogrammu datubāzē.

Viss izskatās pavisam vienkārŔi: izstrādātāja atjauninājums bija veiksmīgs. Labi, varat droŔi ieplānot ikvakara atjauninājumu ražoŔanai.

Nebija skumjas - mēs atjauninājām prod

Tomēr veiksmÄ«gas izstrādes pieredzes nodoÅ”ana ražoÅ”anā nebija bez pārsteigumiem.

Par laimi, pats atjaunināŔanas process sākas ar replikām, tāpēc, kad radās grÅ«tÄ«bas, mēs pārtraucām darbu un atjaunojām kopiju no momentuzņēmuma. Problēmu izmeklÄ“Å”ana tika atlikta lÄ«dz nākamajam rÄ«tam. Žurnālos bija Ŕādi ieraksti:

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

Pētot dažādu adresātu sarakstu arhÄ«vus Google tÄ«klā, tika saprasts, ka Ŕī problēma rodas tādēļ MySQL kļūda. Lai gan Ŕī, visticamāk, ir utilÄ«tas kļūda mysqlcheck Šø mysqlsh.

Izrādās, ka MySQL mainÄ«ja veidu, kādā tie attēlo decimāldaļu datus (int, tinyint utt.), tāpēc mysql-server izmanto citu veidu, kā tos uzglabāt. Ja jÅ«su datu bāze sākotnēji bija versijā 5.5 vai 5.1, un pēc tam atjauninājāt uz 5.7, iespējams, tas bÅ«s jādara OPTIMIZE dažiem galdiem. Pēc tam MySQL atjauninās datu failus, pārsÅ«tot tos uz paÅ”reizējo uzglabāŔanas formātu.

To var pārbaudīt arī ar utilītu 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',
...

Ja field_type Ja jums tas ir vienāds ar 0, tad tabulā tiek izmantots vecais veids - jums ir jāveic OPTIMIZE. Tomēr, ja vērtÄ«ba ir 246, jums jau ir jauns veids. PlaŔāku informāciju par veidiem var atrast kods.

Turklāt iekŔā Ŕī kļūda Mēs apsveram otro iespējamo iemeslu, kas mÅ«s apieta: InnoDB tabulu neesamÄ«ba sistēmas tabulā INNODB_SYS_TABLESPACES, ja tās, tabulas, tika izveidotas versijā 5.1. Lai izvairÄ«tos no problēmām atjaunināŔanas laikā, varat izmantot pievienots SQL skripts.

Kāpēc mums nebija Ŕādu problēmu izstrādātājā? Datubāze tur periodiski tiek kopēta no ražoÅ”anas, tādējādi, tabulas tiek izveidotas no jauna.

Diemžēl lielajā datu bāzē, kas patieŔām darbojas, jÅ«s nevarēsit vienkārÅ”i paņemt un izpildÄ«t universālu OPTIMIZE. Å eit palÄ«dzēs percona-toolkit: pt-online-schema-change utilÄ«ta ir lieliska tieÅ”saistes OPTIMIZĒŠANAS darbÄ«bai.

Atjauninātais plāns izskatījās Ŕādi:

  1. Optimizējiet visas tabulas.
  2. Atjauniniet datu bāzes.

Lai to pārbaudÄ«tu un tajā paŔā laikā uzzinātu atjaunināŔanas laiku, mēs atspējojām vienu no replikām un palaidām Ŕādu komandu visām tabulām:

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

Tabulas tiek atjauninātas bez ilgstoŔām bloÄ·Ä“Å”anām, jo ā€‹ā€‹utilÄ«ta izveido jaunu pagaidu tabulu, kurā tā kopē datus no galvenās tabulas. BrÄ«dÄ«, kad abi galdi ir identiski, oriÄ£inālais galds tiek bloķēts un aizstāts ar jaunu. MÅ«su gadÄ«jumā testa palaiÅ”ana parādÄ«ja, ka visu tabulu atjaunināŔana prasÄ«s apmēram dienu, taču datu kopÄ“Å”ana radÄ«ja pārāk lielu slodzi uz diskiem.

Lai no tā izvairÄ«tos, ražoÅ”anā komandai pievienojām argumentu --sleep ar vērtÄ«bu 10 - Å”is parametrs pielāgo gaidÄ«Å”anas ilgumu pēc datu partijas pārsÅ«tÄ«Å”anas uz jaunu tabulu. Tādā veidā jÅ«s varat samazināt slodzi, ja faktiski darbojas lietojumprogramma prasa atbildes laiku.

Pēc optimizācijas atjaunināŔana bija veiksmÄ«ga.

... bet ne pilnībā!

Pusstundas laikā pēc atjaunināŔanas klientam radās problēma. Datubāze darbojās ļoti dÄ«vaini: periodiski tās sākās savienojuma atiestatÄ«Å”ana. UzraudzÄ«bā tas izskatÄ«jās Ŕādi:

MySQL (Percona Server) atjaunināŔana no 5.7 uz 8.0

Ekrānuzņēmumā ir redzams zāģa zoba grafiks, jo daži MySQL servera pavedieni periodiski avarēja ar kļūdu. Lietojumprogrammā parādījās kļūdas:

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

Ātra žurnālu pārbaude atklāja, ka mysqld dēmons nevarēja iegÅ«t nepiecieÅ”amos resursus no operētājsistēmas. Å Ä·irojot kļūdas, mēs atklājām sistēmā "bāreņu" apparmor politikas faili:

# 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

Å ie faili tika izveidoti, pirms pāris gadiem jauninot uz MySQL 5.7, un tie pieder noņemtajai pakotnei. Failu dzÄ“Å”ana un apparmor pakalpojuma restartÄ“Å”ana atrisināja problēmu:

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

Noslēgumā

Jebkura, pat visvienkārŔākā darbÄ«ba, var radÄ«t neparedzētas problēmas. Un pat pārdomāts plāns ne vienmēr garantē gaidÄ«to rezultātu. Tagad visos mÅ«su komandas atjaunināŔanas plānos ir iekļauta arÄ« obligātā nevajadzÄ«go failu tÄ«rÄ«Å”ana, kas varētu bÅ«t parādÄ«juÅ”ies neseno darbÄ«bu rezultātā.

Un, ņemot vērā Å”o ne pārāk profesionālo grafisko jaunradi, es vēlos teikt milzÄ«gu paldies Percona par izcilajiem produktiem!

MySQL (Percona Server) atjaunināŔana no 5.7 uz 8.0

PS

Lasi arī mūsu emuārā:

Avots: www.habr.com

Pievieno komentāru