Pag-update sa MySQL (Percona Server) gikan sa 5.7 hangtod sa 8.0

Ang pag-uswag wala mohunong, mao nga ang mga rason sa pag-upgrade sa pinakabag-o nga bersyon sa MySQL nahimong mas mapugsanon. Dili pa lang dugay, sa usa sa among mga proyekto, panahon na nga i-update ang komportable nga Percona Server 5.7 clusters sa bersyon 8. Kining tanan nahitabo sa Ubuntu Linux 16.04 nga plataporma. Giunsa paghimo ang ingon nga operasyon nga adunay gamay nga downtime ug kung unsang mga problema ang among nasugatan sa panahon sa pag-update - basaha sa kini nga artikulo.

Training

Ang bisan unsang pag-update sa database server lagmit nga nalangkit sa database reconfiguration: mga pagbag-o sa mga kinahanglanon alang sa mga limitasyon sa mga kapanguhaan sa sistema ug pagtul-id sa mga database configs nga kinahanglan nga tangtangon sa mga outdated nga mga direktiba.

Sa wala pa mag-update, siguradong maghisgot kami sa opisyal nga dokumentasyon:

• MySQL 8 nga mga nota sa pagpagawas;
• Giya sa pag-upgrade sa MySQL;
• Giya sa pag-update sa Percona;
• Giya sa MySQL sa pag-update sa mga replika ug master.

Ug maghimo kita og plano sa aksyon:

1. Pagtul-id sa mga file sa pag-configure pinaagi sa pagtangtang sa mga outdated nga direktiba.
2. Susihon ang pagkaangay sa mga utilities.
3. I-update ang mga database sa ulipon pinaagi sa pag-install sa package percona-server-server.
4. I-update ang agalon nga adunay parehas nga pakete.

Atong tan-awon ang matag punto sa plano ug tan-awon kung unsa ang mahimong sayup.

IMPORTANTE! Ang pamaagi alang sa pag-update sa MySQL cluster base sa Galera adunay kaugalingong mga subtleties nga wala gihulagway sa artikulo. Dili nimo kinahanglan gamiton kini nga panudlo sa kini nga kaso.

Bahin 1: Pagsusi sa mga config

Ang MySQL gitangtang sa bersyon 8 query_cache. Sa tinuod siya gideklarar nga obsolete balik sa bersyon 5.7, apan karon hingpit nga natangtang. Tungod niini, kinahanglan nga tangtangon ang mga kauban nga mga direktiba. Ug sa mga hangyo sa cache mahimo nimong gamiton ang mga eksternal nga himan - pananglitan, ProxySQL.

Usab sa config adunay mga outdated nga mga direktiba bahin sa innodb_file_format. Kung sa MySQL 5.7 posible nga mapili ang format sa InnoDB, nan ang ika-8 nga bersyon nagtrabaho na lamang sa Barracuda format.

Ang among resulta mao ang pagtangtang sa mosunod nga mga direktiba:

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

Aron masusi, among gamiton ang Docker nga imahe sa Percona Server. Atong ibutang ang server config sa direktoryo mysql_config_test, ug sunod niini maghimo kami og mga direktoryo alang sa datos ug mga troso. Pananglitan sa pagsulay sa pagsumpo sa 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

Ubos nga linya: bisan sa mga log sa Docker o sa direktoryo nga adunay mga log - depende sa imong mga config - usa ka file ang makita diin ang mga problema nga mga direktiba ihulagway.

Ania ang among nabatonan:

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 ingon, kinahanglan pa namon nga mahibal-an ang mga pag-encode ug ilisan ang karaan nga direktiba expire-logs-days.

Bahin 2: Pagsusi sa nagtrabaho nga mga instalasyon

Ang dokumentasyon sa pag-update adunay 2 nga mga gamit alang sa pagsusi sa database alang sa pagkaangay. Ang ilang paggamit makatabang sa tigdumala sa pagsusi sa pagkaangay sa kasamtangan nga istruktura sa datos.

Magsugod kita sa klasiko nga mysqlcheck utility. Pagdagan lang:

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

Kung walay mga problema nga makit-an, ang utility mogawas nga adunay code 0:

Dugang pa, ang usa ka utility anaa sa modernong mga bersyon sa MySQL mysql-shell (sa kaso sa Percona kini ang pakete percona-mysql-shell). Kini usa ka puli sa klasiko nga mysql nga kliyente ug gihiusa ang mga gimbuhaton sa usa ka kliyente, usa ka editor sa code sa SQL ug mga gamit sa pagdumala sa MySQL. Aron masusi ang server sa dili pa mag-update, mahimo nimong ipadagan ang mosunod nga mga sugo pinaagi niini:

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

Ania ang mga komento nga among nadawat:

Sa kinatibuk-an, walay kritikal - mga pasidaan lamang bahin sa mga pag-encode (Tan-awa sa ubos). Kinatibuk-ang resulta sa pagpatuman:

Nakahukom kami nga ang pag-update kinahanglan nga wala’y mga problema.

Usa ka nota bahin sa mga pasidaan sa ibabaw nga nagpakita sa mga problema sa mga pag-encode. Ang kamatuoran mao nga ang UTF-8 sa MySQL hangtod karon dili "tinuod" nga UTF-8, tungod kay kini nagtipig lamang sa 3 ka bytes imbes nga 4. Sa MySQL 8 kini sa katapusan nakahukom sa pag-ayo niini: alyas utf8 sa dili madugay mosangpot sa coding utf8mb4, ug ang daan nga mga kolum sa mga lamesa mahimong utf8mb3. Dugang nga pag-encode utf8mb3 tangtangon, apan dili niini nga pagpagawas. Busa, nakahukom kami nga tul-iron ang mga pag-encode nga anaa na sa pag-instalar sa DBMS, human kini ma-update.

Bahin 3: Mga Update sa Server

Unsa man ang mahimong sayup kung adunay ingon usa ka maalamon nga plano?.. Sa hingpit nga pagsabut nga ang mga nuances kanunay nga mahitabo, among gihimo ang una nga eksperimento sa usa ka MySQL dev cluster.

Sama sa nahisgutan na, opisyal nga dokumentasyon naglangkob sa isyu sa pag-update sa MySQL server nga adunay mga replika. Ang hinungdan mao nga kinahanglan nimo una nga i-update ang tanan nga mga replika (mga ulipon), tungod kay ang MySQL 8 mahimo’g kopyahon gikan sa usa ka master nga bersyon 5.7. Ang pipila ka kalisud anaa sa kamatuoran nga atong gigamit ang mode agalon <-> agalon, kung ang hilit nga agalon naa sa mode read-only. Kana, sa tinuud, ang trapiko sa kombat moadto sa usa ka sentro sa datos, ug ang ikaduha usa ka backup.

Ang topology ingon niini:

Ang pag-update kinahanglan magsugod sa mga replika mysql replica dc 2, mysql master dc 2 и mysql replica dc 1, ug tapuson ang mysql master dc 1 server. Aron mahimong mas kasaligan, gipahunong namo ang mga virtual machine, gikuha ang mga snapshot niini, ug diha-diha dayon sa wala pa ang pag-update mihunong sa pagkopya sa sugo STOP SLAVE. Ang nahabilin nga pag-update ingon niini:

1. Gisugdan namon pag-usab ang matag kopya pinaagi sa pagdugang sa 3 nga mga kapilian sa mga config: skip-networking, skip-slave-start, skip-log-bin. Ang kamatuoran mao nga ang pag-update sa database makamugna og binary logs nga adunay mga update sa system tables. Kini nga mga direktiba naggarantiya nga wala’y mga pagbag-o sa data sa aplikasyon sa database, ug ang kasayuran bahin sa pag-update sa mga lamesa sa sistema dili iapil sa mga binary log. Makalikay kini sa mga problema kung ipadayon ang pagkopya.
2. Pag-instalar sa package percona-server-server. Importante nga matikdan nga sa MySQL version 8 dili kinahanglan nimo nga ipadagan ang mando mysqlupgrade pagkahuman sa pag-update sa server.
3. Pagkahuman sa usa ka malampuson nga pagsugod, gi-restart namon ang server - kung wala ang mga parameter nga gidugang sa una nga parapo.
4. Among gisiguro nga malampuson ang pagkopya: check SHOW SLAVE STATUS ug tan-awa nga ang mga lamesa nga adunay mga counter sa database sa aplikasyon gi-update.

Ang tanan morag yano ra: ang pag-update sa dev nagmalampuson. Ok, mahimo nimong luwas nga mag-iskedyul og usa ka gabii nga pag-update alang sa produksiyon.

Walay kaguol - gi-update namo ang prod

Bisan pa, ang pagbalhin sa malampuson nga kasinatian sa dev sa produksiyon dili kung wala’y mga sorpresa.

Maayo na lang, ang proseso sa pag-update mismo nagsugod sa mga replika, mao nga kung nakasugat kami mga kalisud, gipahunong namon ang trabaho ug gipahiuli ang replika gikan sa snapshot. Ang imbestigasyon sa mga problema gi-postpone hangtod sa sunod nga buntag. Ang mga log naglangkob sa mosunod nga mga entry:

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

Ang pagsiksik sa mga archive sa lain-laing mga mailing list sa Google mitultol sa pagsabot nga kini nga problema mahitabo tungod sa MySQL bug. Bisan kung kini lagmit usa ka bug sa utility mysqlcheck и mysqlsh.

Kini nahimo nga ang MySQL nagbag-o sa paagi nga sila nagrepresentar sa datos alang sa mga natad sa decimal (int, tinyint, ug uban pa), mao nga ang mysql-server naggamit ug lahi nga paagi sa pagtipig niini. Kung ang imong database sa sinugdan naa sa bersyon 5.5 o 5.1, ug unya gi-update nimo sa 5.7, nan kinahanglan nimo nga buhaton OPTIMIZE alang sa pipila ka mga lamesa. Unya ang MySQL mag-update sa mga file sa datos, ibalhin kini sa kasamtangan nga format sa pagtipig.

Mahimo usab nimo kini susihon gamit ang utility 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',
...

kon field_type Kung naa nimo kini katumbas sa 0, nan ang daan nga tipo gigamit sa lamesa - kinahanglan nimo nga buhaton OPTIMIZE. Bisan pa, kung ang kantidad mao ang 246, ikaw adunay bag-ong tipo. Dugang nga kasayuran bahin sa mga tipo makita sa Code.

Dugang pa, sa kini nga bug Gikonsiderar namon ang ikaduha nga posible nga hinungdan, nga nakalapas kanamo: ang pagkawala sa mga lamesa sa InnoDB sa lamesa sa sistema INNODB_SYS_TABLESPACES, kung sila, mga lamesa, gihimo sa bersyon 5.1. Aron malikayan ang mga problema kung mag-update, mahimo nimong gamiton gilakip nga SQL script.

Ngano nga wala kami adunay ingon nga mga problema sa dev? Ang database matag karon ug unya gikopya gikan sa produksiyon - sa ingon, ang mga lamesa gimugna pag-usab.

Ikasubo, sa usa ka tinuud nga nagtrabaho nga dako nga database, dili nimo makuha ug ipatuman ang usa ka unibersal OPTIMIZE. percona-toolkit makatabang dinhi: ang pt-online-schema-change utility maayo kaayo alang sa online OPTIMIZE nga operasyon.

Ang gi-update nga plano ingon niini:

1. I-optimize ang tanan nga mga lamesa.
2. I-update ang mga database.

Aron masusi kini ug sa samang higayon mahibal-an ang oras sa pag-update, gipugngan namon ang usa sa mga replika ug gipadagan ang mosunud nga mando alang sa tanan nga mga lamesa:

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

Ang mga lamesa gi-update nga walay taas nga mga kandado tungod sa kamatuoran nga ang utility nagmugna og bag-ong temporaryo nga lamesa diin kini nagkopya sa datos gikan sa main table. Sa higayon nga ang duha ka lamesa managsama, ang orihinal nga lamesa gi-lock ug gipulihan sa bag-o. Sa among kaso, gipakita sa usa ka pagsulay nga pagdagan nga hapit usa ka adlaw aron ma-update ang tanan nga mga lamesa, apan ang pagkopya sa datos hinungdan sa daghang pagkarga sa mga disk.

Aron malikayan kini, sa produksiyon gidugang namo ang argumento sa sugo --sleep nga adunay kantidad nga 10 - kini nga parameter nag-adjust sa gitas-on sa paghulat pagkahuman sa pagbalhin sa usa ka batch sa data sa usa ka bag-ong lamesa. Niining paagiha mahimo nimong makunhuran ang load kung ang aktuwal nga nagdagan nga aplikasyon nangayo sa oras sa pagtubag.

Pagkahuman sa paghimo sa pag-optimize, malampuson ang pag-update.

... apan dili hingpit!

Sulod sa tunga sa oras pagkahuman sa pag-update, ang kliyente adunay problema. Ang database nagtrabaho nga talagsaon kaayo: matag karon ug unya nagsugod sila pag-reset sa koneksyon. Mao kini ang hitsura sa pagmonitor:

Ang screenshot nagpakita sa usa ka sawtooth graph tungod sa kamatuoran nga ang pipila sa MySQL server hilo matag karon ug unya nahagsa uban sa usa ka sayop. Ang mga sayup nagpakita sa aplikasyon:

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

Ang usa ka dali nga pagsusi sa mga troso nagpadayag nga ang mysqld daemon dili makakuha sa gikinahanglan nga mga kapanguhaan gikan sa operating system. Samtang naghan-ay sa mga kasaypanan, among nadiskobrehan sa sistema "orphan" apparmor policy files:

# 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

Kini nga mga file gihimo sa dihang nag-upgrade sa MySQL 5.7 pipila ka tuig na ang milabay ug nahisakop sa usa ka gikuha nga pakete. Ang pagtangtang sa mga file ug pag-restart sa serbisyo sa apparmor nakasulbad sa problema:

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

Sa konklusyon

Bisan unsa, bisan ang pinakasimple nga operasyon, mahimong mosangpot sa wala damha nga mga problema. Ug bisan ang pagbaton ug maayong pagkahunahuna nga plano dili kanunay nga garantiya sa gipaabot nga resulta. Karon, ang bisan unsang mga plano sa pag-update gilakip usab sa among team ang mandatory nga paglimpyo sa wala kinahanglana nga mga file nga mahimo’g nagpakita ingon usa ka sangputanan sa bag-ong mga aksyon.

Ug uban niining dili kaayo propesyonal nga graphic nga pagkamamugnaon, gusto nakong isulti ang usa ka dako nga salamat sa Percona alang sa ilang maayo kaayo nga mga produkto!

PS

Basaha usab sa among blog:

• «Mga Database ug Kubernetes (pagsusi ug taho sa video)";
• «Mga tip ug trick sa Kubernetes: pagpadali sa bootstrap alang sa dagkong mga database";
• «6 praktikal nga mga istorya gikan sa among SRE matag adlaw nga kinabuhi";
• «Usa ka istorya sa Redis operator sa K8s ug usa ka mini-review sa mga utilities alang sa pag-analisar sa datos gikan niini nga database";
• «Seamless nga paglalin sa MongoDB ngadto sa Kubernetes".

Source: www.habr.com