MySQL (Percona Server) 5.7 dan 8.0 gacha yangilanmoqda

Taraqqiyot hali ham to'xtamaydi, shuning uchun MySQL-ning so'nggi versiyalariga yangilanish sabablari tobora kuchayib bormoqda. Yaqinda bizning loyihalarimizdan birida qulay Percona Server 5.7 klasterlarini 8-versiyaga yangilash vaqti keldi. Bularning barchasi Ubuntu Linux 16.04 platformasida sodir bo'ldi. Bunday operatsiyani minimal ishlamay qolish bilan qanday amalga oshirish kerak va yangilanish paytida qanday muammolarga duch keldik - ushbu maqolada o'qing.

o'quv

Ma'lumotlar bazasi serverining har qanday yangilanishi, ehtimol, ma'lumotlar bazasini qayta konfiguratsiya qilish bilan bog'liq: tizim resurslariga cheklovlar talablarini o'zgartirish va eskirgan direktivalardan tozalanishi kerak bo'lgan ma'lumotlar bazasi konfiguratsiyasini tuzatish.

Yangilashdan oldin biz albatta rasmiy hujjatlarga murojaat qilamiz:

• MySQL 8 nashri haqida eslatmalar;
• MySQL-ni yangilash bo'yicha qo'llanma;
• Percona yangilash qo'llanma;
• Replikalar va masterlarni yangilash bo'yicha MySQL qo'llanmasi.

Va keling, harakatlar rejasini tuzamiz:

1. Eskirgan ko'rsatmalarni olib tashlash orqali konfiguratsiya fayllarini to'g'rilang.
2. Utilitlar bilan mosligini tekshiring.
3. Paketni o'rnatish orqali qul ma'lumotlar bazalarini yangilang percona-server-server.
4. Xuddi shu paket bilan masterni yangilang.

Keling, rejaning har bir nuqtasini ko'rib chiqaylik va nima noto'g'ri bo'lishi mumkinligini ko'rib chiqaylik.

MUHIM! Galera-ga asoslangan MySQL klasterini yangilash tartibi maqolada tasvirlanmagan o'ziga xos nozikliklarga ega. Bunday holda siz ushbu ko'rsatmani ishlatmasligingiz kerak.

1-qism: Konfiguratsiyalarni tekshirish

MySQL 8-versiyada olib tashlandi query_cache. Aslida u edi eskirgan deb e'lon qilindi 5.7 versiyasiga qaytdi, lekin hozir butunlay o'chirildi. Shunga ko'ra, tegishli ko'rsatmalarni olib tashlash kerak. Va so'rovlarni keshlash uchun siz endi tashqi vositalardan foydalanishingiz mumkin - masalan, ProxySQL.

Shuningdek, konfiguratsiyada eskirgan ko'rsatmalar mavjud edi innodb_file_format. Agar MySQL 5.7 da InnoDB formatini tanlash mumkin bo'lsa, u holda 8-versiya allaqachon ishlaydi. faqat Barracuda formatida.

Bizning natijamiz quyidagi ko'rsatmalarni olib tashlashdir:

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

Tekshirish uchun biz Percona Serverning Docker tasviridan foydalanamiz. Biz server konfiguratsiyasini katalogga joylashtiramiz mysql_config_test, va uning yonida biz ma'lumotlar va jurnallar uchun kataloglarni yaratamiz. Percona-server konfiguratsiyasi test namunasi:

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

Xulosa: Docker jurnallarida yoki jurnallar bilan katalogda - konfiguratsiyalaringizga qarab - muammoli ko'rsatmalar tasvirlangan fayl paydo bo'ladi.

Mana bizda nima bor edi:

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.

Shunday qilib, biz hali ham kodlashni aniqlashimiz va eskirgan direktivani almashtirishimiz kerak edi expire-logs-days.

2-qism: Ishlaydigan qurilmalarni tekshirish

Yangilash hujjatlarida ma'lumotlar bazasini muvofiqligini tekshirish uchun 2 ta yordamchi dastur mavjud. Ulardan foydalanish ma'murga mavjud ma'lumotlar strukturasining mosligini tekshirishga yordam beradi.

Klassik mysqlcheck yordam dasturidan boshlaylik. Shunchaki ishga tushiring:

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

Hech qanday muammo topilmasa, yordamchi dastur 0 kodi bilan chiqadi:

Bundan tashqari, MySQL ning zamonaviy versiyalarida yordamchi dastur mavjud mysql-shell (Percona holatida bu paket percona-mysql-shell). Bu klassik MySQL mijozining o'rnini bosuvchi vosita bo'lib, mijoz, SQL kod muharriri va MySQL boshqaruv vositalarining funktsiyalarini birlashtiradi. Serverni yangilashdan oldin tekshirish uchun u orqali quyidagi buyruqlarni bajarishingiz mumkin:

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

Mana biz olgan sharhlar:

Umuman olganda, hech qanday muhim narsa yo'q - faqat kodlash haqida ogohlantirishlar (pastga qarang). Umumiy bajarilish natijasi:

Yangilanish muammosiz o'tishi kerak deb qaror qildik.

Kodlash bilan bog'liq muammolarni ko'rsatadigan yuqoridagi ogohlantirishlar haqida eslatma. Gap shundaki, yaqin vaqtgacha MySQL-da UTF-8 UTF-8 "haqiqiy" emas edi, chunki u 3 o'rniga atigi 4 baytni saqlagan. MySQL 8 da bu nihoyat tuzatishga qaror qildi: taxallus utf8 tez orada kodlashga olib keladi utf8mb4, va jadvallardagi eski ustunlar bo'ladi utf8mb3. Qo'shimcha kodlash utf8mb3 olib tashlanadi, lekin bu versiyada emas. Shuning uchun, biz uni yangilaganimizdan so'ng, ishlayotgan DBMS o'rnatilishida kodlashlarni tuzatishga qaror qildik.

3-qism: Server yangilanishlari

Bunday aqlli reja mavjud bo'lganda nima noto'g'ri bo'lishi mumkin?.. Nuanslar har doim sodir bo'lishini yaxshi tushunib, biz MySQL dev klasterida birinchi tajribani o'tkazdik.

Yuqorida aytib o'tilganidek, rasmiy hujjatlar MySQL serverlarini replikalar bilan yangilash masalasini qamrab oladi. Xulosa shuki, siz avval barcha replikalarni (qullarni) yangilashingiz kerak, chunki MySQL 8 asosiy 5.7 versiyasidan nusxa ko'chirishi mumkin. Ba'zi qiyinchiliklar biz rejimdan foydalanishimiz bilan bog'liq usta usta, masofaviy master rejimida bo'lganda faqat o'qish uchun. Ya'ni, aslida, jangovar trafik bitta ma'lumot markaziga o'tadi, ikkinchisi esa zaxiradir.

Topologiya quyidagicha ko'rinadi:

Yangilanish replikalardan boshlanishi kerak mysql replika dc 2, mysql master dc 2 и mysql replica dc 1, va mysql master dc 1 serveri bilan yakunlang.Ishonchliroq bo'lish uchun biz virtual mashinalarni to'xtatdik, ularning suratlarini oldik va yangilanishdan oldin darhol buyruq bilan replikatsiyani to'xtatdik. STOP SLAVE. Yangilanishning qolgan qismi quyidagicha ko'rinadi:

1. Konfiguratsiyalarga 3 ta variantni qo'shish orqali har bir nusxani qayta ishga tushiramiz: skip-networking, skip-slave-start, skip-log-bin. Gap shundaki, ma'lumotlar bazasini yangilash tizim jadvallarini yangilash bilan ikkilik jurnallarni yaratadi. Ushbu direktivalar ma'lumotlar bazasidagi dastur ma'lumotlariga hech qanday o'zgarishlar bo'lmasligini kafolatlaydi va tizim jadvallarini yangilash haqidagi ma'lumotlar ikkilik jurnallarga kiritilmaydi. Bu replikatsiyani davom ettirishda muammolardan qochadi.
2. Paketni o'rnatish percona-server-server. Shuni ta'kidlash kerakki, MySQL 8-versiyasida yo'q buyruqni bajarishingiz kerak mysqlupgrade server yangilanganidan keyin.
3. Muvaffaqiyatli ishga tushirilgandan so'ng, biz serverni qayta ishga tushiramiz - birinchi xatboshida qo'shilgan parametrlarsiz.
4. Biz replikatsiya muvaffaqiyatli ishlashiga ishonch hosil qilamiz: tekshiring SHOW SLAVE STATUS va ilova ma'lumotlar bazasidagi hisoblagichlar bilan jadvallar yangilanganligini ko'ring.

Hammasi juda oddiy ko'rinadi: dev yangilanishi muvaffaqiyatli bo'ldi. OK, ishlab chiqarish uchun tungi yangilanishni xavfsiz rejalashtirishingiz mumkin.

Hech qanday qayg'u yo'q edi - biz mahsulotni yangiladik

Biroq, muvaffaqiyatli ishlab chiqarish tajribasini ishlab chiqarishga o'tkazish kutilmagan hodisalardan holi emas edi.

Yaxshiyamki, yangilash jarayonining o'zi replikalardan boshlanadi, shuning uchun biz qiyinchiliklarga duch kelganimizda, biz ishni to'xtatdik va oniy tasvirdan nusxani tikladik. Muammolarni tekshirish ertasi kuni ertalabgacha qoldirildi. Jurnallarda quyidagi yozuvlar mavjud edi:

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-da turli xil pochta ro'yxatlarining arxivlarini o'rganish ushbu muammo tufayli yuzaga kelishini tushunishga olib keldi. MySQL xatosi. Garchi bu yordamchi dastur xatosi bo'lsa ham mysqlcheck и mysqlsh.

Ma'lum bo'lishicha, MySQL o'nlik maydonlar (int, tinyint va boshqalar) uchun ma'lumotlarni taqdim etish usulini o'zgartirgan, shuning uchun MySQL-server ularni saqlashning boshqa usulidan foydalanadi. Agar ma'lumotlar bazasi dastlab 5.5 yoki 5.1 versiyada edi va keyin siz 5.7 ga yangiladingiz, keyin buni qilishingiz kerak bo'lishi mumkin OPTIMIZE Ba'zi jadvallar uchun. Keyin MySQL ma'lumotlar fayllarini yangilaydi va ularni joriy saqlash formatiga o'tkazadi.

Buni yordamchi dastur yordamida ham tekshirishingiz mumkin 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',
...

agar field_type Agar sizda 0 ga teng bo'lsa, jadvalda eski tur ishlatiladi - siz bajarishingiz kerak OPTIMIZE. Biroq, agar qiymat 246 bo'lsa, sizda allaqachon yangi tur mavjud. Turlar haqida ko'proq ma'lumotni maqolada topishingiz mumkin kod.

Bundan tashqari, ichida bu xato Bizni chetlab o'tgan ikkinchi mumkin bo'lgan sababni ko'rib chiqmoqdamiz: tizim jadvalida InnoDB jadvallarining yo'qligi INNODB_SYS_TABLESPACES, agar ular, jadvallar 5.1 versiyasida yaratilgan bo'lsa. Yangilashda muammolarni oldini olish uchun siz foydalanishingiz mumkin biriktirilgan SQL skripti.

Nega bizda bunday muammolar ishlab chiqmadi? Ma'lumotlar bazasi vaqti-vaqti bilan ishlab chiqarishdan ko'chiriladi - shuning uchun jadvallar qayta tiklanadi.

Afsuski, haqiqatan ham ishlaydigan katta ma'lumotlar bazasida siz shunchaki universal ma'lumotni olib, bajara olmaysiz. OPTIMIZE. Bu erda percona-toolkit yordam beradi: pt-online-schema-change yordam dasturi onlayn OPTIMIZE operatsiyasi uchun juda yaxshi.

Yangilangan reja quyidagicha ko'rinish oldi:

1. Barcha jadvallarni optimallashtirish.
2. Ma'lumotlar bazalarini yangilang.

Uni tekshirish va shu bilan birga yangilanish vaqtini bilish uchun biz replikalardan birini o'chirib qo'ydik va barcha jadvallar uchun quyidagi buyruqni bajardik:

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

Yordamchi dastur asosiy jadvaldan ma'lumotlarni ko'chiradigan yangi vaqtinchalik jadval yaratganligi sababli jadvallar uzoq qulflarsiz yangilanadi. Har ikkala jadval bir xil bo'lsa, asl jadval qulflanadi va yangisi bilan almashtiriladi. Bizning holatlarimizda test sinovi shuni ko'rsatdiki, barcha jadvallarni yangilash uchun taxminan bir kun kerak bo'ladi, ammo ma'lumotlarni nusxalash disklarga juda ko'p yuk olib keldi.

Bunga yo'l qo'ymaslik uchun ishlab chiqarishda biz argumentni buyruqqa qo'shdik --sleep 10 qiymati bilan - bu parametr ma'lumotlar to'plamini yangi jadvalga o'tkazgandan so'ng kutish uzunligini moslashtiradi. Haqiqiy ishlaydigan dastur javob vaqtini talab qilsa, shu tarzda siz yukni kamaytirishingiz mumkin.

Optimallashtirishni amalga oshirgandan so'ng, yangilanish muvaffaqiyatli bo'ldi.

... lekin to'liq emas!

Yangilanishdan keyin yarim soat ichida mijoz muammoga duch keldi. Ma'lumotlar bazasi juda g'alati ishladi: vaqti-vaqti bilan ular boshlandi ulanishni tiklash. Bu monitoringda shunday ko'rinardi:

Skrinshotda MySQL serverining ba'zi iplari vaqti-vaqti bilan xatolik bilan ishdan chiqqanligi sababli arra tishli grafik ko'rsatilgan. Ilovada xatolar paydo bo'ldi:

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

Jurnallarni tezkor tekshirish mysqld demoni operatsion tizimdan kerakli resurslarni ololmasligini aniqladi. Xatolarni saralashda biz tizimda topdik "etim" apparmor siyosat fayllari:

# 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

Ushbu fayllar bir necha yil oldin MySQL 5.7 ga yangilanganda yaratilgan va olib tashlangan paketga tegishli. Fayllarni o'chirish va apparmor xizmatini qayta ishga tushirish muammoni hal qildi:

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

Xulosa

Har qanday, hatto eng oddiy operatsiya ham kutilmagan muammolarga olib kelishi mumkin. Va hatto yaxshi o'ylangan rejaga ega bo'lish har doim ham kutilgan natijani kafolatlamaydi. Endi, bizning jamoamizning har qanday yangilash rejalari, shuningdek, so'nggi harakatlar natijasida paydo bo'lishi mumkin bo'lgan keraksiz fayllarni majburiy tozalashni ham o'z ichiga oladi.

Va bu unchalik professional bo'lmagan grafik ijodkorlik bilan, men Perconaga ajoyib mahsulotlari uchun katta rahmat aytmoqchiman!

PS

Shuningdek, bizning blogimizda o'qing:

• «Ma'lumotlar bazalari va Kubernetes (ko'rib chiqish va video hisobot)";
• «Kubernetes maslahatlari va fokuslari: katta ma'lumotlar bazalari uchun yuklashni tezlashtirish";
• «Bizning SRE kundalik hayotimizdan 6 ta amaliy hikoyalar";
• «K8-dagi Redis operatori bilan bitta hikoya va ushbu ma'lumotlar bazasidan ma'lumotlarni tahlil qilish uchun yordamchi dasturlarni mini-ko'rib chiqish";
• «MongoDB-ning Kubernetes-ga uzluksiz ko'chishi".

Manba: www.habr.com