🥇 MySQL (Percona Server) bywurkje fan 5.7 nei 8.0

De foarútgong stiet net stil, dus de redenen om te upgrade nei de lêste ferzjes fan MySQL wurde hieltyd twingender. Net lang lyn, yn ien fan ús projekten, wie it tiid om de gesellige Percona Server 5.7-klusters te aktualisearjen nei ferzje 8. Dit alles barde op it Ubuntu Linux 16.04-platfoarm. Hoe kinne jo sa'n operaasje útfiere mei minimale downtime en hokker problemen wy tsjinkamen tidens de fernijing - lês yn dit artikel.

Tarieding fan

Elke fernijing fan 'e databanktsjinner is nei alle gedachten ferbûn mei databank-rekonfiguraasje: feroarings yn easken foar grinzen op systeemboarnen en korreksje fan databankkonfiguraasjes dy't moatte wurde wiske fan ferâldere rjochtlinen.

Foardat jo bywurkje, sille wy perfoarst ferwize nei de offisjele dokumintaasje:

En lit ús in aksjeplan opstelle:

Korrekte konfiguraasjebestannen troch ferâldere rjochtlinen te ferwiderjen.
Kontrolearje kompatibiliteit mei nutsbedriuwen.
Update slave-databases troch it pakket te ynstallearjen percona-server-server.
Update de master mei itselde pakket.

Litte wy nei elk punt fan it plan sjen en sjen wat der mis kin gean.

WICHTich! De proseduere foar it bywurkjen fan in MySQL-kluster basearre op Galera hat syn eigen subtiliteiten dy't net yn it artikel beskreaun wurde. Jo moatte dizze ynstruksje net brûke yn dit gefal.

Diel 1: Konfiguraasjes kontrolearje

MySQL waard fuortsmiten yn ferzje 8 query_cache. Eins wie hy ferâldere ferklearre werom yn ferzje 5.7, mar no folslein wiske. Dêrtroch is it nedich om de byhearrende rjochtlinen te ferwiderjen. En om fersiken te cache kinne jo no eksterne ark brûke - bygelyks, ProxySQL.

Ek yn 'e konfiguraasje wiene ferâldere rjochtlinen oer innodb_file_format. As yn MySQL 5.7 it mooglik wie om it InnoDB-formaat te selektearjen, dan wurket de 8ste ferzje al allinnich mei Barracuda opmaak.

Us resultaat is it fuortheljen fan de folgjende rjochtlinen:

query_cache_type, query_cache_limit и query_cache_size;
innodb_file_format и innodb_file_format_max.

Om te kontrolearjen, sille wy de Docker-ôfbylding fan Percona Server brûke. Wy pleatse de tsjinner konfiguraasje yn 'e map mysql_config_test, en njonken it sille wy mappen meitsje foar gegevens en logs. Percona-tsjinner konfiguraasje test foarbyld:

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

Bottom line: itsij yn 'e Docker-logs of yn' e map mei de logs - ôfhinklik fan jo konfiguraasjes - sil in bestân ferskine wêryn de problematyske rjochtlinen wurde beskreaun.

Hjir is wat wy hiene:

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.

Sa moasten wy noch de kodearrings útfine en de ferâldere rjochtline ferfange expire-logs-days.

Diel 2: Kontrolearje wurkjende ynstallaasjes

De updatedokumintaasje befettet 2 nutsfoarsjenningen foar it kontrolearjen fan de databank op kompatibiliteit. Har gebrûk helpt de behearder om de kompatibiliteit fan 'e besteande gegevensstruktuer te kontrolearjen.

Litte wy begjinne mei it klassike mysqlcheck-hulpprogramma. Gewoan rinne:

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

As der gjin problemen wurde fûn, sil it hulpprogramma útgean mei koade 0:

Derneist is in hulpprogramma beskikber yn moderne ferzjes fan MySQL mysql-shell (yn it gefal fan Percona is dit it pakket percona-mysql-shell). It is in ferfanging foar de klassike mysql-kliïnt en kombinearret de funksjes fan in kliïnt, in SQL-koade-bewurker en MySQL-administraasje-ark. Om de tsjinner te kontrolearjen foardat jo bywurkje, kinne jo de folgjende kommando's dêrtroch útfiere:

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

Hjir binne de opmerkingen dy't wy krigen:

Yn 't algemien is neat kritysk - allinich warskôgingen oer kodearrings (Sjoch hjirûnder). Algemiene útfieringsresultaat:

Wy besletten dat de fernijing soe gean sûnder problemen.

In notysje oer de boppesteande warskôgings dy't problemen mei kodearring oanjaan. It feit is dat UTF-8 yn MySQL oant koartlyn wie net "wier" UTF-8, sûnt it bewarre mar 3 bytes ynstee fan 4. Yn MySQL 8 dit is úteinlik besletten om it te reparearjen: alias utf8 sil gau liede ta kodearring utf8mb4, en de âlde kolommen yn 'e tabellen wurde utf8mb3. Fierder kodearring utf8mb3 sil fuortsmiten wurde, mar net yn dizze release. Dêrom hawwe wy besletten om de kodearrings al te korrigearjen op 'e rinnende DBMS-ynstallaasje, nei it bywurkjen fan it.

Diel 3: Server Updates

Wat kin der mis gean as d'r sa'n tûk plan is? .. Begryp goed dat nuânses altyd foarkomme, hawwe wy it earste eksperimint útfierd op in MySQL-ûntwikkelingskluster.

Lykas al neamd, offisjele dokumintaasje beslacht it probleem fan it bywurkjen fan MySQL-tsjinners mei replika's. De ûnderste rigel is dat jo earst alle replika's (slaven) moatte bywurkje, om't MySQL 8 kin replikearje fan in masterferzje 5.7. Guon muoite leit yn it feit dat wy de modus brûke master <-> master, as de master op ôfstân yn modus is allinnich lêze. Dat is, yn feite, fjochtsferkear giet nei ien datasintrum, en de twadde is in reservekopy.

De topology sjocht der sa út:

De fernijing moat begjinne mei replika's mysql replika dc 2, mysql master dc 2 и mysql replica dc 1, en einigje mei de mysql master dc 1-tsjinner. Om mear betrouber te wêzen, stopje wy de firtuele masines, namen snapshots fan har, en fuortendaliks foar de fernijing stoppe replikaasje mei it kommando STOP SLAVE. De rest fan 'e fernijing sjocht der sa út:

Wy begjinne elke replika opnij troch 3 opsjes ta te foegjen oan de konfiguraasjes: skip-networking, skip-slave-start, skip-log-bin. It feit is dat it bywurkjen fan de databank genereart binêre logs mei updates foar systeemtabellen. Dizze rjochtlinen garandearje dat der gjin wizigingen sille wêze oan applikaasjegegevens yn 'e databank, en ynformaasje oer it bywurkjen fan systeemtabellen sil net opnommen wurde yn' e binêre logs. Dit sil problemen foarkomme by it hervatten fan replikaasje.
It ynstallearjen fan it pakket percona-server-server. It is wichtich om te notearjen dat yn MySQL ferzje 8 net jo moatte it kommando útfiere mysqlupgrade neidat tsjinner update.
Nei in suksesfolle start starte wy de tsjinner wer op 'e nij - sûnder de parameters dy't yn 'e earste alinea binne tafoege.
Wy soargje derfoar dat replikaasje mei sukses wurket: kontrolearje SHOW SLAVE STATUS en sjoch dat de tabellen mei tellers yn de applikaasje databank wurde bywurke.

It liket allegear frij simpel: de dev-fernijing wie suksesfol. Ok, jo kinne feilich in nachtlike update planne foar produksje.

D'r wie gjin fertriet - wy hawwe de prod bywurke

De oerdracht fan suksesfolle dev-ûnderfining nei produksje wie lykwols net sûnder ferrassingen.

Gelokkich begjint it fernijingsproses sels mei replika's, dus doe't wy swierrichheden tsjinkamen, stoppe wy it wurk en restaurearre de replika fan 'e momintopname. It ûndersyk nei de problemen waard útsteld oant de oare moarns. De logs befette de folgjende yngongen:

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

Undersyk nei de argiven fan ferskate mailinglisten op Google late ta it begryp dat dit probleem optreedt fanwegen MySQL bug. Hoewol dit wierskynliker in nutsbedriuw is mysqlcheck и mysqlsh.

It docht bliken dat MySQL de manier feroare wêrop se gegevens foar desimale fjilden fertsjintwurdigje (int, tinyint, ensfh.), Dus mysql-tsjinner brûkt in oare manier om se op te slaan. As jo databank ynearsten wie yn ferzje 5.5 of 5.1, en dan hawwe jo bywurke nei 5.7, dan moatte jo miskien dwaan OPTIMIZE foar guon tabellen. Dan sil MySQL de gegevensbestannen bywurkje, se oerdrage nei it hjoeddeistige opslachformaat.

Jo kinne dit ek kontrolearje mei it hulpprogramma 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',
...

as field_type As jo it gelyk hawwe oan 0, dan wurdt it âlde type brûkt yn 'e tabel - jo moatte útfiere OPTIMIZE. As de wearde lykwols 246 is, hawwe jo al in nij type. Mear ynformaasje oer de soarten is te finen yn koade.

Boppedat, yn dizze bug Wy beskôgje de twadde mooglike reden, dy't ús omgie: it ûntbrekken fan InnoDB-tabellen yn 'e systeemtabel INNODB_SYS_TABLESPACES, as se, tabellen, waarden makke yn ferzje 5.1. Om problemen te foarkommen by it bywurkjen, kinne jo gebrûk meitsje taheakke SQL skript.

Wêrom hawwe wy gjin sokke problemen op dev? De databank wurdt dêr periodyk kopiearre út produksje - dus, tabellen wurde opnij oanmakke.

Spitigernôch, op in echt wurkjende grutte databank, do silst net by steat wêze om gewoan nimme en útfiere in universele OPTIMIZE. percona-toolkit sil hjir helpe: it pt-online-schema-feroaringsprogramma is poerbêst foar de online OPTIMIZE-operaasje.

It bywurke plan seach der sa út:

Optimalisearje alle tabellen.
Update de databases.

Om it te kontrolearjen en tagelyk de fernijingstiid út te finen, hawwe wy ien fan 'e replika's útskeakele en it folgjende kommando útfierd foar alle tabellen:

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

Tabellen wurde bywurke sûnder lange slûzen fanwegen it feit dat it hulpprogramma in nije tydlike tabel makket wêryn it gegevens fan 'e haadtabel kopiearret. Op it momint dat beide tabellen binne identyk, de oarspronklike tafel is beskoattele en ferfongen troch de nije. Yn ús gefal hat in testrun sjen litten dat it sawat in dei duorje soe om alle tabellen te aktualisearjen, mar it kopiearjen fan gegevens feroarsake tefolle lêst op 'e skiven.

Om dit te foarkommen, hawwe wy yn produksje it argumint tafoege oan it kommando --sleep mei in wearde fan 10 - dizze parameter past de wachtlingte oan nei it oerbringen fan in batch gegevens nei in nije tabel. Op dizze manier kinne jo de lading ferminderje as de eigentlike rinnende applikaasje easket op reaksjetiid.

Nei it útfieren fan de optimalisaasje wie de fernijing suksesfol.

... mar net hielendal!

Binnen in healoere nei de fernijing kaam de klant mei in probleem. De databank wurke hiel nuver: periodyk begûnen se ferbining weromsette. Dit is hoe't it der útseach yn tafersjoch:

De skermôfbylding lit in sawtooth-grafyk sjen fanwege it feit dat guon fan 'e MySQL-tsjinner threads periodyk ferûngelokke binne mei in flater. Flaters ferskynden yn 'e applikaasje:

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

In rappe ynspeksje fan 'e logs die bliken dat de mysqld-daemon de fereaske boarnen net fan it bestjoeringssysteem koe krije. By it sortearjen fan flaters, ûntdutsen wy yn it systeem "wees" apparmor belied triemmen:

# 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

Dizze bestannen binne makke by it opwurdearjen nei MySQL 5.7 in pear jier lyn en hearre ta in fuortsmiten pakket. It wiskjen fan de bestannen en it opnij starte fan de apparmor-tsjinst lost it probleem op:

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

Yn ôfsluting

Elke, sels de ienfâldichste operaasje, kin liede ta ûnferwachte problemen. En sels it hawwen fan in goed trochtocht plan garandearret net altyd it ferwachte resultaat. No, alle updateplannen dy't ús team hat ek de ferplichte skjinmeitsjen fan ûnnedige bestannen dy't koe hawwe ferskynd as gefolch fan resinte aksjes.

En mei dizze net heul profesjonele grafyske kreativiteit wol ik Percona in grutte tank sizze foar har treflike produkten!

PS

Lês ek op ús blog:

Boarne: www.habr.com

MySQL (Percona Server) bywurkje fan 5.7 nei 8.0