MySQL (Percona Server)-ийг 5.7-аас 8.0 болгон шинэчилж байна

Ахиц дэвшил зогсохгүй байгаа тул MySQL-ийн хамгийн сүүлийн хувилбар руу шинэчлэх шалтгаанууд улам бүр анхаарал татаж байна. Тун удалгүй манай төслүүдийн нэгэнд тухтай Percona Server 5.7 кластеруудыг 8 хувилбар болгон шинэчлэх цаг болсон. Энэ бүхэн Ubuntu Linux 16.04 платформ дээр болсон. Ийм ажиллагааг хамгийн бага зогсолтоор хэрхэн хийх, шинэчлэлтийн явцад ямар асуудал тулгарсан талаар энэ нийтлэлээс уншина уу.

Сургалт

Өгөгдлийн сангийн серверийн аливаа шинэчлэлт нь өгөгдлийн сангийн дахин тохиргоотой холбоотой байх магадлалтай: системийн нөөцийн хязгаарлалтад тавигдах шаардлагуудын өөрчлөлт, хуучирсан удирдамжийг арилгах шаардлагатай мэдээллийн сангийн тохиргооны засвар.

Шинэчлэхээсээ өмнө бид албан ёсны баримт бичигт хандах болно.

• MySQL 8 хувилбарын тэмдэглэл;
• MySQL шинэчлэх гарын авлага;
• Percona шинэчлэх гарын авлага;
• Хуулбарууд болон мастеруудыг шинэчлэх MySQL гарын авлага.

Тэгээд үйл ажиллагааны төлөвлөгөө гаргацгаая:

1. Хуучирсан удирдамжийг арилгах замаар тохиргооны файлуудыг засах.
2. Хэрэгслүүдтэй нийцэж байгаа эсэхийг шалгана уу.
3. Багцыг суулгаснаар боол мэдээллийн санг шинэчилнэ үү percona-server-server.
4. Мастерийг ижил багцаар шинэчилнэ үү.

Төлөвлөгөөний цэг бүрийг харцгаая, юу буруу болж болохыг харцгаая.

Анхаарах зүйл! Galera дээр суурилсан MySQL кластерыг шинэчлэх журам нь нийтлэлд дурдаагүй өөрийн гэсэн нарийн шинж чанартай байдаг. Энэ тохиолдолд та энэ зааврыг ашиглах ёсгүй.

1-р хэсэг: Тохиргоог шалгаж байна

MySQL-г 8 хувилбар дээр устгасан query_cache. Үнэндээ тэр байсан хуучирсан гэж зарлав 5.7 хувилбарт буцаж ирсэн, гэхдээ одоо бүрэн устгасан. Үүний дагуу холбогдох зааврыг арилгах шаардлагатай байна. Хүсэлтүүдийг кэш болгохын тулд та одоо гадны хэрэгслийг ашиглаж болно - жишээлбэл, ProxySQL.

Мөн тохиргоонд хуучирсан заавар байсан innodb_file_format. Хэрэв MySQL 5.7 дээр InnoDB форматыг сонгох боломжтой байсан бол 8-р хувилбар аль хэдийн ажиллаж байна. зөвхөн Barracuda форматтай.

Бидний үр дүн бол дараах зааврыг хассан явдал юм.

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

Шалгахын тулд бид Percona серверийн Docker дүрсийг ашиглана. Бид серверийн тохиргоог лавлахад байрлуулна mysql_config_test, мөн түүний хажууд бид өгөгдөл болон бүртгэлийн лавлахуудыг үүсгэх болно. 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

Доод мөрөнд: Docker логууд эсвэл бүртгэлтэй лавлах дотор - таны тохиргооноос хамааран - асуудалтай удирдамжийг тайлбарласан файл гарч ирнэ.

Бидэнд юу байсан бэ:

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.

Тиймээс бид кодчилолуудыг олж, хуучирсан удирдамжийг солих шаардлагатай хэвээр байна expire-logs-days.

2-р хэсэг: Ажлын суурилуулалтыг шалгах

Шинэчлэлийн баримт бичиг нь мэдээллийн баазыг нийцтэй эсэхийг шалгах 2 хэрэгслийг агуулдаг. Тэдгээрийн хэрэглээ нь администраторт одоо байгаа өгөгдлийн бүтцийн нийцтэй байдлыг шалгахад тусалдаг.

Сонгодог mysqlcheck хэрэгслээр эхэлцгээе. Зүгээр л ажиллуул:

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

Хэрэв асуудал олдохгүй бол хэрэгсэл нь 0 кодоор гарна:

Нэмж дурдахад хэрэгсэл нь MySQL-ийн орчин үеийн хувилбаруудад байдаг mysql-бүрхүүл (Перконагийн хувьд энэ нь багц юм percona-mysql-shell). Энэ нь сонгодог mysql клиентийг орлох бөгөөд үйлчлүүлэгчийн функц, SQL код засварлагч болон MySQL удирдлагын хэрэгслүүдийг хослуулсан. Серверийг шинэчлэхийн өмнө шалгахын тулд түүгээр дамжуулан дараах тушаалуудыг ажиллуулж болно.

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

Бидний хүлээн авсан сэтгэгдлүүд энд байна:

Ерөнхийдөө чухал зүйл байхгүй - зөвхөн кодчилолын талаархи анхааруулга (доороос үзнэ үү). Гүйцэтгэлийн ерөнхий үр дүн:

Шинэчлэлт нь асуудалгүй явах ёстой гэж бид шийдсэн.

Шифрлэлттэй холбоотой асуудлуудыг харуулсан дээрх анхааруулгын тухай тэмдэглэл. Саяхныг хүртэл MySQL-д UTF-8 байсан нь үнэн юм "үнэн" UTF-8 биш байсан, учир нь энэ нь 3-ийн оронд зөвхөн 4 байт хадгалагдсан. MySQL 8-д энэ нь эцэст нь юм засахаар шийдсэн: бусад нэр utf8 удахгүй кодлоход хүргэнэ utf8mb4, мөн хүснэгтүүд дэх хуучин баганууд болно utf8mb3. Цаашдын кодчилол utf8mb3 устгах болно, гэхдээ энэ хувилбарт байхгүй. Тиймээс бид ажиллаж байгаа DBMS суулгац дээр байгаа кодчилолуудыг шинэчилсний дараа засахаар шийдсэн.

3-р хэсэг: Серверийн шинэчлэлтүүд

Ийм ухаалаг төлөвлөгөө байхад юу нь болохгүй болох вэ?.. Нянгууд үргэлж тохиолддог гэдгийг сайн ойлгож, MySQL dev cluster дээр анхны туршилтыг хийсэн.

Өмнө дурьдсанчлан, албан ёсны баримт бичиг MySQL серверүүдийг хуулбараар шинэчлэх асуудлыг хамардаг. Хамгийн гол нь MySQL 8 нь үндсэн 5.7 хувилбараас хуулбарлах боломжтой тул та эхлээд бүх хуулбарыг (боолуудыг) шинэчлэх хэрэгтэй. Зарим хүндрэл нь бид энэ горимыг ашигладагтай холбоотой юм мастер мастер, алсын удирдлага горимд байх үед зөвхөн унших. Энэ нь үнэн хэрэгтээ байлдааны урсгал нь нэг мэдээллийн төв рүү явдаг, хоёр дахь нь нөөц юм.

Топологи нь дараах байдлаар харагдаж байна.

Шинэчлэлт нь хуулбараас эхлэх ёстой mysql хуулбар dc 2, mysql мастер dc 2 и mysql replica dc 1, мөн mysql master dc 1 серверээр төгсгөнө. Илүү найдвартай байхын тулд бид виртуал машинуудыг зогсоож, тэдгээрийн агшин зуурын зургийг авч, шинэчлэлт хийхээс өмнө тушаалаар хуулбарлахыг зогсоосон. STOP SLAVE. Шинэчлэлийн үлдсэн хэсэг нь дараах байдалтай байна.

1. Бид тохиргоонд 3 сонголтыг нэмж хуулбар бүрийг дахин эхлүүлнэ: skip-networking, skip-slave-start, skip-log-bin. Баримт нь мэдээллийн санг шинэчлэх нь системийн хүснэгтүүдийн шинэчлэлт бүхий хоёртын бүртгэлийг үүсгэдэг. Эдгээр удирдамж нь мэдээллийн сан дахь програмын өгөгдөлд өөрчлөлт оруулахгүй байх баталгаа бөгөөд системийн хүснэгтүүдийг шинэчлэх тухай мэдээлэл хоёртын бүртгэлд орохгүй. Энэ нь хуулбарлах ажлыг үргэлжлүүлэхэд асуудал гарахаас зайлсхийх болно.
2. Багцыг суулгаж байна percona-server-server. MySQL хувилбар 8 дээр гэдгийг анхаарах нь чухал үгүй та тушаалыг ажиллуулах хэрэгтэй mysqlupgrade серверийн шинэчлэлтийн дараа.
3. Амжилттай эхлүүлсний дараа бид серверийг дахин эхлүүлнэ - эхний догол мөрөнд нэмсэн параметрүүдгүйгээр.
4. Бид хуулбарлах нь амжилттай ажиллаж байгаа эсэхийг шалгана: шалгах SHOW SLAVE STATUS мөн програмын мэдээллийн сан дахь тоолууртай хүснэгтүүд шинэчлэгдсэнийг харна уу.

Энэ бүхэн маш энгийн харагдаж байна: dev шинэчлэл амжилттай болсон. За, та үйлдвэрлэлийн шөнийн шинэчлэлтийг аюулгүйгээр төлөвлөж болно.

Ямар ч уйтгар гуниг байсангүй - бид бүтээгдэхүүнийг шинэчилсэн

Гэсэн хэдий ч амжилттай хөгжүүлэлтийн туршлагыг үйлдвэрлэлд шилжүүлэх нь гэнэтийн зүйл биш байсан.

Аз болоход, шинэчлэлтийн процесс өөрөө хуулбараас эхэлдэг тул хүндрэлтэй тулгарах үед бид ажлыг зогсоож, хормын хувилбараас хуулбарыг сэргээсэн. Асуудлыг шалгах ажлыг маргааш өглөө болтол хойшлуулав. Бүртгэлд дараах бичилтүүд орсон байна.

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

Google дээрх янз бүрийн захидлын жагсаалтын архивыг судалснаар энэ асуудал дараах шалтгааны улмаас үүсдэг гэж ойлгоход хүргэсэн. MySQL алдаа. Хэдийгээр энэ нь хэрэглээний алдаа байж магадгүй юм mysqlcheck и mysqlsh.

MySQL нь аравтын талбарт (int, tinyint гэх мэт) өгөгдлийг илэрхийлэх хэлбэрийг өөрчилсөн тул mysql-сервер нь тэдгээрийг хадгалах өөр аргыг ашигладаг. Хэрэв таны мэдээллийн сан анхнаасаа 5.5 эсвэл 5.1 хувилбар дээр байсан бөгөөд дараа нь та 5.7 болгож шинэчилсэн бол хийх шаардлагатай байж магадгүй юм. OPTIMIZE зарим ширээний хувьд. Дараа нь MySQL нь өгөгдлийн файлуудыг шинэчилж, одоогийн хадгалах формат руу шилжүүлнэ.

Та үүнийг мөн хэрэгсэл ашиглан шалгаж болно 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',
...

бол field_type Хэрэв та 0-тэй тэнцүү бол хуучин төрлийг хүснэгтэд ашигласан болно - та үүнийг хийх хэрэгтэй OPTIMIZE. Гэсэн хэдий ч, хэрэв утга нь 246 бол танд шинэ төрөл байна. Төрөл бүрийн талаар дэлгэрэнгүй мэдээллийг эндээс авах боломжтой код.

Түүнээс гадна, дотор энэ алдаа Биднийг тойрч гарсан хоёр дахь боломжит шалтгааныг бид авч үзэж байна: системийн хүснэгтэд InnoDB хүснэгт байхгүй байна. INNODB_SYS_TABLESPACES, хэрэв тэдгээр нь хүснэгтүүд 5.1 хувилбар дээр үүсгэгдсэн бол. Шинэчлэх үед асуудал гарахаас зайлсхийхийн тулд та ашиглаж болно хавсаргасан SQL скрипт.

Бид яагаад dev дээр ийм асуудал гаргаагүй юм бэ? Мэдээллийн санг үйлдвэрлэлээс үе үе хуулж авдаг. хүснэгтүүдийг дахин бүтээдэг.

Харамсалтай нь, үнэхээр ажиллаж байгаа том мэдээллийн сан дээр та зүгээр л бүх нийтийн программыг авч, ажиллуулах боломжгүй болно. OPTIMIZE. percona-toolkit энд туслах болно: pt-online-schema-change хэрэгсэл нь онлайн OPTIMIZE үйл ажиллагаанд маш сайн.

Шинэчлэгдсэн төлөвлөгөө нь дараах байдалтай байв.

1. Бүх хүснэгтийг оновчтой болгох.
2. Өгөгдлийн санг шинэчлэх.

Үүнийг шалгаж, шинэчлэх цагийг мэдэхийн тулд бид хуулбаруудын аль нэгийг идэвхгүй болгож, бүх хүснэгтэд дараах тушаалыг ажиллуулав.

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

Хэрэгсэл нь үндсэн хүснэгтээс өгөгдлийг хуулах шинэ түр хүснэгт үүсгэдэг тул хүснэгтүүдийг урт түгжээгүйгээр шинэчилдэг. Хоёр хүснэгт ижил байх үед анхны хүснэгтийг түгжиж, шинээр сольсон байна. Манай тохиолдолд туршилтын ажиллагаа нь бүх хүснэгтийг шинэчлэхэд нэг өдөр шаардагдахыг харуулсан боловч өгөгдлийг хуулах нь дискэнд хэт их ачаалал өгөхөд хүргэсэн.

Үүнээс зайлсхийхийн тулд үйлдвэрлэлд бид аргументыг тушаалд нэмсэн --sleep 10 утгатай - энэ параметр нь багц өгөгдлийг шинэ хүснэгтэд шилжүүлсний дараа хүлээх хугацааг тохируулдаг. Бодит ажиллаж байгаа програм нь хариу өгөх хугацаа шаардсан тохиолдолд та ачааллыг бууруулж чадна.

Оновчлолыг хийсний дараа шинэчлэлт амжилттай болсон.

... гэхдээ бүрэн биш!

Шинэчлэгдсэнээс хойш хагас цагийн дотор үйлчлүүлэгч асуудалтай тулгарсан. Мэдээллийн сан нь маш хачирхалтай ажилладаг байсан: үе үе эхэлдэг холболтыг дахин тохируулна. Мониторинг хийхэд иймэрхүү харагдсан:

Дэлгэцийн агшинд MySQL серверийн зарим утаснууд үе үе алдаатай гацдаг тул хөрөөний шүдний графикийг харуулж байна. Аппликешнд алдаа гарсан:

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

Бүртгэлүүдийг хурдан шалгаж үзэхэд mysqld дэмон нь үйлдлийн системээс шаардлагатай нөөцийг авч чадахгүй байгаа нь тогтоогдсон. Алдааг цэгцлэх явцад бид системээс олж мэдсэн "өнчин" 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

Эдгээр файлууд нь хэдэн жилийн өмнө MySQL 5.7 руу шинэчлэх үед үүсгэгдсэн бөгөөд устгагдсан багцад багтдаг. Файлуудыг устгаж, apparmor үйлчилгээг дахин эхлүүлснээр асуудлыг шийдсэн:

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

Эцэст нь хэлэхэд

Аливаа, тэр ч байтугай хамгийн энгийн ажиллагаа нь гэнэтийн асуудалд хүргэж болзошгүй юм. Мөн сайтар бодож боловсруулсан төлөвлөгөөтэй байх нь хүлээгдэж буй үр дүнг үргэлж баталгаажуулдаггүй. Одоо манай багийн шинэчлэлийн төлөвлөгөөнд сүүлийн үеийн үйлдлүүдийн үр дүнд гарч ирсэн шаардлагагүй файлуудыг заавал цэвэрлэх ажлыг багтаасан болно.

Энэ нь тийм ч мэргэжлийн бус график бүтээлч байдлын хувьд би Перконад маш сайн бүтээгдэхүүнүүддээ маш их баярлалаа гэж хэлмээр байна!

PS

Мөн манай блог дээрээс уншина уу:

• «Өгөгдлийн сан ба Кубернетес (хяналт, видео тайлан)";
• «Kubernetes зөвлөмж ба заль мэх: том өгөгдлийн сангийн ачааллыг хурдасгах";
• «Бидний SRE-ийн өдөр тутмын амьдралын 6 практик түүх";
• «K8s дээрх Redis оператортой хийсэн нэг түүх, энэ мэдээллийн сангаас өгөгдөлд дүн шинжилгээ хийх хэрэгслүүдийн талаархи бяцхан тойм.";
• «MongoDB-г Kubernetes руу саадгүй шилжүүлэх".

Эх сурвалж: www.habr.com