🥇Update MySQL (Percona Server) vun 5.7 op 8.0

De Fortschrëtt steet net nach ëmmer, sou datt d'Grënn fir op déi lescht Versioune vu MySQL ze upgrade ginn ëmmer méi iwwerzeegend. Net viru laanger Zäit, an engem vun eise Projeten, war et Zäit fir déi gemittlech Percona Server 5.7 Cluster op Versioun 8 ze aktualiséieren. All dëst ass geschitt op der Ubuntu Linux 16.04 Plattform. Wéi esou eng Operatioun mat minimalem Ënnerbriechung auszeféieren a wéi eng Problemer mir während dem Update begéint hunn - liest an dësem Artikel.

Virbereedung

All Aktualiséierung vum Datebankserver ass héchstwahrscheinlech mat der Rekonfiguratioun vun der Datebank assoziéiert: Ännerungen an Ufuerderunge fir Limiten op Systemressourcen a Korrektur vun Datebankkonfiguratiounen, déi vun alen Direktiven geläscht musse ginn.

Virun der Aktualiséierung wäerte mir definitiv op déi offiziell Dokumentatioun referenzéieren:

A loosst eis en Aktiounsplang opstellen:

Korrekt Konfiguratiounsdateien andeems Dir verouderte Direktiven ewechhuelt.
Iwwerpréift Kompatibilitéit mat Utilities.
Update Sklavendatenbanken andeems Dir de Package installéiert percona-server-server.
Update de Master mam selwechte Package.

Loosst eis all Punkt vum Plang kucken a kucken wat falsch ka goen.

WICHTEG! D'Prozedur fir d'Aktualiséierung vun engem MySQL Cluster baséiert op Galera huet seng eege Subtletien déi net am Artikel beschriwwe ginn. Dir sollt dës Instruktioun net an dësem Fall benotzen.

Deel 1: Iwwerpréift Configuratioun

MySQL gouf an der Versioun 8 geläscht query_cache. Eigentlech war hien als obsolet deklaréiert zréck an der Versioun 5.7, awer elo komplett geläscht. Deementspriechend ass et néideg déi assoziéiert Direktiven ze läschen. A fir Ufroen ze cache kënnt Dir elo extern Tools benotzen - zum Beispill, ProxySQL.

Och an der Configuratioun goufen et verännert Direktiven iwwer innodb_file_format. Wann am MySQL 5.7 et méiglech war den InnoDB Format ze wielen, da funktionnéiert déi 8. nëmme mat Barracuda Format.

Eist Resultat ass d'Ewechhuele vun de folgenden Direktiven:

query_cache_type, query_cache_limit и query_cache_size;
innodb_file_format и innodb_file_format_max.

Fir ze kontrolléieren, benotze mir den Docker-Bild vum Percona Server. Mir setzen de Serverkonfiguratioun am Verzeechnes mysql_config_test, an nieft et wäerte mir Verzeichnisser fir Daten a Logbicher erstellen. Percona-Server Konfiguratiounstest Beispill:

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: entweder an den Docker Logbicher oder am Verzeechnes mat de Logbicher - ofhängeg vun Äre Konfiguratiounen - erschéngt eng Datei an där déi problematesch Direktiven beschriwwe ginn.

Hei ass wat mir haten:

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.

Also musse mir nach ëmmer d'Kodéierungen erausfannen an déi verännert Direktiv ersetzen expire-logs-days.

Deel 2: Kontroll vun Aarbechtsinstallatiounen

D'Aktualiséierungsdokumentatioun enthält 2 Utilities fir d'Datebank fir Kompatibilitéit ze kontrolléieren. Hir Notzung hëlleft dem Administrateur d'Kompatibilitéit vun der existéierender Datestruktur ze kontrolléieren.

Loosst eis mam klassesche mysqlcheck Utility ufänken. Einfach lafen:

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

Wa keng Probleemer fonnt ginn, geet d'Utility mam Code 0 eraus:

Zousätzlech ass en Utility verfügbar a modern Versioune vu MySQL mysql-shell (am Fall vu Percona ass dëst de Package percona-mysql-shell). Et ass en Ersatz fir de klassesche MySQL Client a kombinéiert d'Funktioune vun engem Client, e SQL Code Editor a MySQL Administratiounsinstrumenter. Fir de Server z'iwwerpréiwen ier Dir aktualiséiert gëtt, kënnt Dir déi folgend Kommandoen duerch lafen:

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

Hei sinn d'Kommentaren déi mir kruten:

Am Allgemengen, näischt kritesch - nëmmen Warnungen iwwer Kodéierungen (kuckt ënnen). Gesamt Ausféierungsresultat:

Mir hunn decidéiert datt den Update ouni Probleemer sollt goen.

Eng Notiz iwwer d'Warnungen hei uewen, déi Problemer mat Kodéierungen uginn. De Fakt ass datt UTF-8 a MySQL bis viru kuerzem war net "richteg" UTF-8, well et nëmmen 3 Bytes gelagert huet amplaz 4. Am MySQL 8 ass dat endlech decidéiert et ze fixéieren: alias utf8 wäert geschwënn zu coding féieren utf8mb4, an déi al Kolonnen an den Dëscher ginn utf8mb3. Weider Kodéierung utf8mb3 wäert geläscht ginn, awer net an dëser Verëffentlechung. Dofir hu mir décidéiert d'Kodéierungen schonn op der lafender DBMS Installatioun ze korrigéieren, nodeems se se aktualiséiert goufen.

Deel 3: Server Aktualiséierungen

Wat kéint falsch goen wann et esou e Smart Plang ass? .. Ganz gutt ze verstoen datt Nuancen ëmmer geschéien, hu mir dat éischt Experiment op engem MySQL Dev Cluster gemaach.

Wéi scho gesot, offiziell Dokumentatioun deckt d'Thema vun der Aktualiséierung vun MySQL Server mat Repliken. Déi ënnescht Linn ass datt Dir als éischt all Repliken (Sklaven) sollt aktualiséieren, well MySQL 8 kann aus enger Masterversioun 5.7 replizéieren. E puer Schwieregkeete läit an der Tatsaach datt mir de Modus benotzen Meeschter <-> Meeschter, wann de Remote Master am Modus ass nëmme liesen. Dat ass, tatsächlech, de Kampfverkéier geet an een Datenzenter, an déi zweet ass e Backup.

D'Topologie gesäit esou aus:

Den Update muss mat Repliken ufänken mysql replica dc 2, mysql master dc 2 и mysql replica dc 1, an Enn mam mysql master dc 1 Server.Fir méi zouverlässeg ze sinn, hu mir d'virtuelle Maschinnen gestoppt, Snapshots vun hinnen gemaach an direkt virum Update gestoppt Replikatioun mam Kommando STOP SLAVE. De Rescht vum Update gesäit esou aus:

Mir starten all Replika nei andeems Dir 3 Optiounen un d'Konfiguratioun bäidréit: skip-networking, skip-slave-start, skip-log-bin. D'Tatsaach ass datt d'Aktualiséierung vun der Datebank binär Logbicher generéiert mat Updates op Systemtabellen. Dës Direktiven garantéieren datt et keng Ännerunge fir Applikatiounsdaten an der Datebank gëtt, an Informatioun iwwer d'Aktualiséierung vum Systemtabellen gëtt net an de binäre Logbicher abegraff. Dëst wäert Probleemer vermeiden wann Dir Replikatioun erëmfënnt.
Installatioun vum Package percona-server-server. Et ass wichteg ze notéieren datt an MySQL Versioun 8 Net Dir musst de Kommando lafen mysqlupgrade no Server Update.
No engem erfollegräiche Start, restarte mir de Server erëm - ouni d'Parameteren, déi am éischte Paragraph bäigefüügt goufen.
Mir suergen datt d'Replikatioun erfollegräich funktionnéiert: kontrolléiert SHOW SLAVE STATUS a gesinn, datt d'Dëscher mat counters an der Applikatioun Datebank aktualiséiert ginn.

Et gesäit alles ganz einfach aus: den Dev Update war erfollegräich. Ok, Dir kënnt sécher en Nightly Update fir d'Produktioun plangen.

Et war keng Trauregkeet - mir hunn de Prod aktualiséiert

Wéi och ëmmer, den Transfer vun der erfollegräicher Entwécklererfahrung op d'Produktioun war net ouni Iwwerraschungen.

Glécklecherweis fänkt den Updateprozess selwer mat Repliken un, also wa mir Schwieregkeeten erlieft hunn, hu mir d'Aarbecht gestoppt an d'Replika vum Snapshot restauréiert. D'Enquête vun de Problemer gouf bis den nächste Moien verluecht. D'Logbicher enthalen déi folgend Entréen:

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

D'Recherche vun den Archiven vu verschiddenen Mailinglëschten op Google huet zum Verständnis gefouert datt dëse Problem geschitt wéinst MySQL Feeler. Och wann dëst méi wahrscheinlech en Utility-Bug ass mysqlcheck и mysqlsh.

Et stellt sech eraus datt MySQL de Wee geännert huet wéi se Daten fir Dezimalfelder representéieren (int, tinyint, etc.), sou datt de mysql-Server en anere Wee benotzt fir se ze späicheren. Wann Är Datebank am Ufank war an der Versioun 5.5 oder 5.1, an dann hutt Dir op 5.7 aktualiséiert, da musst Dir vläicht maachen OPTIMIZE fir e puer Dëscher. Da wäert MySQL d'Datedateien aktualiséieren, se an dat aktuellt Späicherformat transferéieren.

Dir kënnt dëst och mat dem Utility kontrolléieren 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',
...

wann field_type Wann Dir et gläich wéi 0 hutt, da gëtt den alen Typ an der Tabell benotzt - Dir musst ausféieren OPTIMIZE. Wéi och ëmmer, wann de Wäert 246 ass, hutt Dir schonn en neien Typ. Méi Informatioun iwwer d'Typen fannt Dir an Code.

Ausserdeem, an dëse Käfer Mir betruechten den zweete méigleche Grond, deen eis ëmgaang ass: d'Feele vun InnoDB Dëscher an der Systemtabelle INNODB_SYS_TABLESPACES, wa se, Dëscher, an der Versioun 5.1 erstallt goufen. Fir Problemer beim Update ze vermeiden, kënnt Dir benotzen befestegt SQL Skript.

Firwat hu mir net esou Problemer op Dev? D'Datebank gëtt periodesch do aus der Produktioun kopéiert - also, Dëscher ginn nei erstallt.

Leider, op enger wierklech funktionéierender grousser Datebank, kënnt Dir net nëmmen en Universal huelen an ausféieren OPTIMIZE. percona-toolkit hëlleft hei: d'pt-online-schema-change Utility ass exzellent fir d'Online OPTIMIZE Operatioun.

Den aktualiséierten Plang huet esou ausgesinn:

Optimiséieren all Dëscher.
Update d'Datenbanken.

Fir et z'iwwerpréiwen a gläichzäiteg d'Aktualiséierungszäit erauszefannen, hu mir ee vun de Repliken deaktivéiert an de folgende Kommando fir all Dëscher ausgefouert:

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

Dëscher ginn ouni laang Spär aktualiséiert wéinst der Tatsaach, datt d'Utility eng nei temporär Dësch erstellt, an deem se Daten aus der Haapttabell kopéiert. Am Moment wou béid Dëscher identesch sinn, gëtt den ursprénglechen Dësch gespaart an duerch den neien ersat. An eisem Fall huet e Testrun gewisen datt et ongeféier engem Dag dauert fir all Dëscher ze aktualiséieren, awer d'Kopie vun Daten verursaacht ze vill Belaaschtung op den Disken.

Fir dëst ze vermeiden, hu mir an der Produktioun d'Argument zum Kommando bäigefüügt --sleep mat engem Wäert vun 10 - dëse Parameter passt d'Waardelängt no der Transfert vun enger Partie Daten op en neien Dësch. Op dës Manéier kënnt Dir d'Laascht reduzéieren wann déi aktuell lafend Applikatioun op d'Äntwertzäit verlaangt.

Nodeems d'Optimiséierung duerchgefouert gouf, war den Update erfollegräich.

... awer net ganz!

Bannent enger hallwer Stonn nom Update koum de Client mat engem Problem. D'Datebank huet ganz komesch geschafft: periodesch hunn se ugefaang Verbindung zréckgesat. Dëst ass wéi et bei der Iwwerwaachung ausgesinn huet:

De Screenshot weist e Sawtooth-Grafik wéinst der Tatsaach, datt e puer vun de MySQL-Server-Threads periodesch mat engem Feeler erofgefall sinn. Feeler erschéngen an der Applikatioun:

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

Eng séier Inspektioun vun de Logbicher huet opgedeckt datt de mysqld-Daemon net déi erfuerderlech Ressourcen aus dem Betribssystem konnt kréien. Beim Sortéiere vu Feeler, hu mir am System entdeckt "Orphan" Apparmor Politik Dateien:

# 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

Dës Dateie goufen erstallt beim Upgrade op MySQL 5.7 virun e puer Joer a gehéieren zu engem ewechgeholl Package. D'Dateien läschen an den Apparmor Service nei starten hunn de Problem geléist:

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

Conclusioun

All, och déi einfachst Operatioun, kann zu onerwaarte Probleemer féieren. An och e gutt duerchduechte Plang ze hunn garantéiert net ëmmer dat erwaart Resultat. Elo, all Update Pläng eis Team huet och déi obligatoresch Botzen vun onnéideg Dateien enthalen déi als Resultat vun rezenten Aktiounen erschéngen kéinten.

A mat dëser net ganz professioneller graphescher Kreativitéit, wëll ech dem Percona e grousse Merci soen fir hir exzellent Produkter!

PS

Liest och op eisem Blog:

Source: will.com

Update MySQL (Percona Server) vu 5.7 op 8.0