Men sizga 2019 yil boshidan Andrey Borodinning "WAL-G bilan zaxira nusxalari. 2019 yilda nima bor?"
Hammaga salom! Mening ismim Andrey Borodin. Men Yandex-da dasturchiman. Men PostgreSQL-ga 2016 yildan beri qiziqaman, men ishlab chiquvchilar bilan gaplashganimdan so'ng va ular hamma narsa oddiy - siz manba kodini olib, uni yaratasiz, shunda hammasi yaxshi bo'ladi. Va o'shandan beri men to'xtata olmayman - har xil narsalarni yozaman.
Men ustida ishlayotgan narsalardan biri bu zaxira tizimi. . Umuman olganda, Yandex-da biz juda uzoq vaqtdan beri PostgreSQL-da zaxira tizimlari ustida ishlayapmiz. Va siz Internetda biz zaxira tizimlarini qanday yaratishimiz haqida oltita hisobot seriyasini topishingiz mumkin. Va har yili ular biroz rivojlanadi, biroz rivojlanadi va ishonchli bo'ladi.
Ammo bugungi kunda hisobot nafaqat biz nima qilganimiz, balki u qanchalik sodda va nima ekanligi haqida ham. Qanchangiz WAL-G haqidagi hisobotlarimni ko'rgansiz? Ko'p odamlar tomosha qilmagani yaxshi, chunki men eng oddiy narsadan boshlayman.
Agar to'satdan sizda PostgreSQL klasteri bo'lsa va menimcha, hammada ulardan bir nechtasi bo'lsa va to'satdan hali zaxira tizimi yo'q bo'lsa, siz har qanday S3 xotirasi yoki Google Cloud-ga mos xotirani olishingiz kerak.
Masalan, siz bizning stendimizga kelib, S3-ga mos keladigan Yandex Object Storage promo-kodini olishingiz mumkin.
Keyin paqir yarating. Bu shunchaki ma'lumot uchun konteyner.
Xizmat foydalanuvchisini yarating.
Xizmat foydalanuvchisi uchun kirish kalitini yarating: aws-s3-key.
WAL-G ning so'nggi barqaror versiyasini yuklab oling.
Bizning pre-relizlarimiz relizlardan nimasi bilan farq qiladi? Mendan tez-tez erta bo'shatishni so'rashadi. Va agar versiyada etarli vaqt davomida xato bo'lmasa, masalan, bir oy, men uni qo'yib yuboraman. Mana bu nashr noyabr oyida. Va bu shuni anglatadiki, biz har oyda odatda muhim bo'lmagan funktsiyalarda qandaydir xato topdik, ammo biz hali chiqarganimiz yo'q. Oldingi versiya faqat noyabr. Unda bizga ma'lum bo'lgan xatolar yo'q, ya'ni xatoliklar loyihaning rivojlanishi bilan qo'shildi.
WAL-G-ni yuklab olganingizdan so'ng, oddiy "zaxira ro'yxati" buyrug'ini ishga tushirishingiz mumkin, bu esa muhit o'zgaruvchilari ichiga o'tadi. Va u Object Storage-ga ulanadi va sizda qanday zaxiralar borligini aytib beradi. Avvaliga, albatta, sizda zaxira nusxalari bo'lmasligi kerak. Ushbu slaydning maqsadi hamma narsa juda oddiy ekanligini ko'rsatishdir. Bu muhit o'zgaruvchilarini qabul qiluvchi va kichik buyruqlarni bajaradigan konsol buyrug'i.
Shundan so'ng siz birinchi zaxira nusxasini yaratishingiz mumkin. WAL-G-da βzaxira-pushβ deb ayting va WAL-G-da klasteringizning pgdata manzilini belgilang. Va, ehtimol, PostgreSQL sizga, agar sizda zaxira tizimi bo'lmasa, "arxiv rejimi" ni yoqishingiz kerakligini aytadi.
Bu shuni anglatadiki, siz sozlamalarga o'tishingiz va "archive_mode = on" ni yoqishingiz va "archive_command" ni qo'shishingiz kerak, bu ham WAL-G da kichik buyruqdir. Lekin ba'zi sabablarga ko'ra odamlar ko'pincha bu mavzu bo'yicha bar skriptlaridan foydalanadilar va uni WAL-G atrofida o'rab olishadi. Iltimos, buni qilmang. WAL-G-da topilgan funksiyalardan foydalaning. Agar biror narsa etishmayotgan bo'lsa, yozing . WAL-G bu archive_command da ishlaydigan yagona dastur deb hisoblaydi.
Biz WAL-G-dan asosan Yandex ma'lumotlar bazasi boshqaruvida yuqori mavjudlik klasterini yaratish uchun foydalanamiz.
Va u odatda bitta magistr va bir nechta replikatsiyalar topologiyasida qo'llaniladi. Shu bilan birga, u Yandex Object Storage-da zaxira nusxasini yaratadi.
Eng keng tarqalgan stsenariylar vaqtni tiklash nuqtasi yordamida klaster nusxalarini yaratishdir. Ammo bu holda, zaxira tizimining ishlashi biz uchun unchalik muhim emas. Biz faqat zaxiradan yangi klasterni yuklashimiz kerak.
Odatda, yangi tugunni qo'shganda bizga zaxira tizim ishlashi kerak. Nima uchun bu muhim? Odatda odamlar klasterga yangi tugun qo'shadilar, chunki mavjud klaster o'qish yukiga bardosh bera olmaydi. Ular yangi nusxa qo'shishlari kerak. Agar yukni pg_basebackup-dan Master-ga qo'shsak, Master qulashi mumkin. Shuning uchun biz uchun arxivdan yangi tugunni tezda yuklashimiz, Master-ga minimal yuk yaratishimiz juda muhim edi.
Va shunga o'xshash yana bir vaziyat. Bu ulanish yo'qolgan ma'lumotlar markazidan Klaster ustasini almashtirgandan so'ng eski Masterni qayta ishga tushirish zarurati.
- Natijada, nusxa ko'chirish tizimiga qo'yiladigan talablarni shakllantirishda biz pg_basebackup bulutda ishlashda bizga mos kelmasligini tushundik.
- Biz ma'lumotlarimizni siqish imkoniyatiga ega bo'lishni xohladik. Ammo qutiga kiritilganidan tashqari deyarli har qanday zaxira tizimi ma'lumotlarni siqishni ta'minlaydi.
- Biz hamma narsani parallel qilishni xohladik, chunki bulutdagi foydalanuvchi ko'p sonli protsessor yadrolarini sotib oladi. Ammo agar bizda ba'zi operatsiyalarda parallelizm bo'lmasa, unda ko'p sonli yadrolar foydasiz bo'ladi.
- Bizga shifrlash kerak, chunki ko'pincha ma'lumotlar bizniki emas va aniq matnda saqlanmaydi. Aytgancha, WAL-G ga bizning hissamiz shifrlashdan boshlandi. Biz WAL-G-da shifrlashni yakunladik, shundan so'ng bizdan: "Balki bizdan birimiz loyihani ishlab chiqarmiz?" Va o'shandan beri men WAL-G bilan bir yildan ortiq ishlayapman.
- Bizga resurslarni qisqartirish ham kerak edi, chunki vaqt o'tishi bilan bulutdan foydalangan holda, ba'zida odamlar kechasi muhim oziq-ovqat yukiga ega bo'lishlarini va bu yukga aralashib bo'lmasligini aniqladik. Shuning uchun biz resurslarni qisqartirishni qo'shdik.
- Shuningdek, ro'yxatga olish va boshqarish.
- Va tekshirish.
Biz juda ko'p turli xil vositalarni ko'rib chiqdik. Yaxshiyamki, bizda PostgreSQL-da katta tanlov mavjud. Va hamma joyda bizda nimadir etishmayotgan edi, ba'zi bir kichik funksiya, kimdir kichik xususiyat.
Va mavjud tizimlarni o'rganib chiqib, biz WAL-G ni ishlab chiqamiz degan xulosaga keldik. O'shanda bu yangi loyiha edi. Zaxira tizimining bulutli infratuzilmasini rivojlantirishga ta'sir qilish juda oson edi.
Biz amal qiladigan asosiy mafkura shundaki, WAL-G balalaika kabi oddiy bo'lishi kerak.
WAL-G da 4 ta buyruq mavjud. Bu:
WAL-PUSH - milni arxivlash.
WAL-FETCH - milni oling.
BACKUP-PUSH β zaxira nusxasini yaratish.
BACKUP-FETCH β zaxira tizimidan zaxira nusxasini oling.
Darhaqiqat, WAL-G ham ushbu zaxiralarni boshqarishga ega, ya'ni hozirda kerak bo'lmagan tarixdagi yozuvlar va zahiralarni ro'yxatga olish va o'chirish.
Biz uchun muhim funktsiyalardan biri bu delta nusxalarini yaratish funktsiyasidir.
Delta nusxalari biz butun klasterning to'liq zaxira nusxasini yaratmasligimizni anglatadi, lekin faqat klasterdagi o'zgartirilgan fayllarning o'zgartirilgan sahifalari. Funktsional jihatdan bu WAL yordamida tiklash qobiliyatiga juda o'xshaydi. Ammo biz parallel ravishda WAL bitta torli delta zaxira nusxasini yig'ishimiz mumkin. Shunga ko'ra, shanba kuni bizda asosiy zaxira nusxasi bo'lsa, delta har kuni zaxiralanadi va payshanba kuni biz muvaffaqiyatsiz bo'lsak, biz 4 ta delta zaxira nusxasini va 10 soatlik WALni yig'ishimiz kerak. Bu taxminan bir xil vaqtni oladi, chunki delta zaxiralari parallel ravishda aylanadi.
LSN-ga asoslangan deltalar - bu shuni anglatadiki, zaxira nusxasini yaratishda biz har bir sahifani birlashtirishimiz va uning o'zgarganligini tushunish uchun uning LSN-ni oldingi zaxiradagi LSN bilan tekshirishimiz kerak. O'zgartirilgan ma'lumotlarni o'z ichiga olishi mumkin bo'lgan har qanday sahifa delta zaxirasida bo'lishi kerak.
Aytganimdek, parallelizmga juda katta e'tibor berildi.
Ammo PostgreSQL-dagi arxiv API mos keladi. PostgreSQL bitta WAL faylini arxivlaydi va uni qayta tiklashda bitta WAL faylini so'raydi. Ammo ma'lumotlar bazasi "WAL-FETCH" buyrug'i yordamida bitta WAL faylini so'raganda, biz "WAL-PREFETCH" buyrug'ini chaqiramiz, u keyingi 8 ta faylni parallel ravishda ob'ektlar do'konidan ma'lumotlarni olish uchun tayyorlaydi.
Va ma'lumotlar bazasi bizdan bitta faylni arxivlashni so'raganda, biz archive_status ga qaraymiz va boshqa WAL fayllari mavjudligini ko'ramiz. Va biz WALni parallel ravishda yuklab olishga harakat qilyapmiz. Bu sezilarli samaradorlikni ta'minlaydi va arxivlanmagan WALlar sonidagi masofani sezilarli darajada kamaytiradi. Ko'pgina zaxira tizimini ishlab chiquvchilar bu juda xavfli tizim deb hisoblashadi, chunki biz PostgreSQL API bo'lmagan kodning ichki qismi haqidagi bilimimizga tayanamiz. PostgreSQL biz uchun archive_status papkasining mavjudligini kafolatlamaydi va semantikani, WAL fayllari uchun tayyorlik signallarining mavjudligini kafolatlamaydi. Shunga qaramay, biz manba kodini o'rganmoqdamiz, bu shunday ekanligini ko'ramiz va biz undan foydalanishga harakat qilmoqdamiz. Va biz PostgreSQL qaysi yo'nalishda rivojlanayotganini nazorat qilamiz, agar to'satdan bu mexanizm buzilgan bo'lsa, biz undan foydalanishni to'xtatamiz.
O'zining sof ko'rinishida LSN-ga asoslangan WAL delta fayl tizimidagi rejim vaqti oldingi zahiradan beri o'zgargan har qanday klaster faylini o'qishni talab qiladi. Biz bu bilan uzoq vaqt, deyarli bir yil yashadik. Va oxirida bizda WAL deltalari bor degan xulosaga keldik.
Bu shuni anglatadiki, biz har safar WALni Masterda arxivlaganimizda, biz uni nafaqat siqib, shifrlab, tarmoqqa jo'natamiz, balki bir vaqtning o'zida ham o'qiymiz. Undagi yozuvlarni tahlil qilamiz va o'qiymiz. Qaysi bloklar o'zgarganligini tushunamiz va delta fayllarni to'playmiz.
Delta fayl WAL fayllarining ma'lum diapazonini tavsiflaydi, WAL ning ushbu diapazonida qaysi bloklar o'zgartirilganligi haqidagi ma'lumotlarni tavsiflaydi. Va keyin bu delta fayllar ham arxivlanadi.
Bu erda biz hamma narsani juda tez parallellashtirganimiz bilan duch keldik, lekin biz ketma-ket tarixni parallel ravishda o'qiy olmaymiz, chunki ma'lum bir segmentda biz oldingi WAL yozuvining oxiriga duch kelishimiz mumkin, bizda hali bog'lanish uchun hech narsa yo'q, chunki parallel o'qish biz birinchi navbatda o'tmishi bo'lmagan kelajakni tahlil qilishimizga olib keldi.
Natijada, biz tushunarsiz bo'laklarni _delta_partial fayllarga qo'yishimiz kerak edi. Natijada, o'tmishga qaytganimizda, biz WAL yozuvining qismlarini bittaga yopishtiramiz, shundan so'ng biz uni tahlil qilamiz va unda nima o'zgarganini tushunamiz.
Agar bizning milni tahlil qilish tarixida biz nima sodir bo'layotganini tushunmaydigan kamida bitta nuqta bo'lsa, shunga ko'ra, keyingi zaxiralash paytida biz oddiy LSN bilan qilganimiz kabi, butun klasterni yana o'qishga majbur bo'lamiz. - deltaga asoslangan.
Natijada, bizning barcha azob-uqubatlarimiz WAL-G tahlil kutubxonasini ochiq manbaga ega bo'lishimizga olib keldi. Bilishimcha, hozircha hech kim foydalanmayapti, lekin kimdir xohlasa, yozadi va ishlatadi, u hamma uchun ochiq. (Yangilangan havola )
Natijada, barcha axborot oqimlari ancha murakkab ko'rinadi. Bizning ustamiz shaftni arxivlaydi va delta fayllarini arxivlaydi. Zaxira nusxasini yaratadigan replika zaxira nusxalari o'rtasida o'tgan vaqt davomida delta fayllarni qabul qilishi kerak. Bunday holda, tarixning qismlarini ommaviy ravishda qo'shish va tahlil qilish kerak bo'ladi, chunki butun tarix katta segmentlarga to'g'ri kelmaydi. Va shundan keyingina replika to'liq delta zaxira nusxasini arxivlashi mumkin.
Grafiklarda hamma narsa ancha sodda ko'rinadi. Bu bizning haqiqiy klasterlarimizdan biridan yuklab olingan. Bizda LSN asosidagi, bir kunda ishlab chiqarilgan. Va biz LSN-ga asoslangan delta zaxirasi ertalab soat uchdan ertalab beshgacha ishlayotganini ko'ramiz. Bu protsessor yadrolari sonidagi yuk. WAL-delta bizni bu yerda taxminan 20 daqiqa vaqt oldi.Ya'ni u sezilarli darajada tezlashdi, lekin shu bilan birga tarmoq orqali yanada qizg'in almashinuv sodir bo'ldi.
Qaysi bloklar va ma'lumotlar bazasi tarixida qaysi vaqtda o'zgarganligi haqida ma'lumotga ega bo'lganimiz sababli, biz oldinga bordik va funksionallikni - "pg_prefaulter" deb nomlangan PostgreSQL kengaytmasini birlashtirishga qaror qildik.
Bu shuni anglatadiki, kutish bazasi tiklash buyrug'ini bajarganda, u WAL-G ga keyingi WAL faylini olishni aytadi. Biz WALni tiklash jarayoni yaqin kelajakda qaysi ma'lumotlar bloklariga kirishini taxminan tushunamiz va bu bloklarda o'qish jarayonini boshlaydi. Bu SSD kontrollerlarining ishlashini oshirish uchun qilingan. Chunki WAL roligi o'zgartirilishi kerak bo'lgan sahifaga etib boradi. Bu sahifa diskda va sahifa keshida emas. Va u ushbu sahifaning kelishini sinxron tarzda kutadi. Ammo yaqin atrofda WAL-G bor, u keyingi bir necha yuz megabayt WALda bizga ma'lum sahifalar kerakligini biladi va shu bilan birga ularni isitishni boshlaydi. Parallel ravishda bajarilishi uchun bir nechta diskka kirishni boshlaydi. Bu SSD drayvlarida yaxshi ishlaydi, lekin, afsuski, bu qattiq disk uchun mutlaqo qo'llanilmaydi, chunki biz unga faqat ko'rsatmalarimiz bilan aralashamiz.
Bu endi kodda mavjud.
Biz qo'shmoqchi bo'lgan xususiyatlar mavjud.
Ushbu rasm WAL-delta nisbatan qisqa vaqt olishini ko'rsatadi. Va bu kun davomida ma'lumotlar bazasida sodir bo'lgan o'zgarishlarni o'qishdir. Biz WAL-deltani nafaqat tunda qilishimiz mumkin edi, chunki u endi muhim yuk manbai emas. Biz WAL-deltani har daqiqada o'qiy olamiz, chunki u arzon. Bir daqiqada biz klasterda sodir bo'lgan barcha o'zgarishlarni skanerlashimiz mumkin. Va buni "instant WAL-delta" deb atash mumkin.
Gap shundaki, biz klasterni qayta tiklaganimizda, biz ketma-ket yig'ishimiz kerak bo'lgan hikoyalar sonini kamaytiramiz. Ya'ni, PostgreSQL o'tkazadigan WAL miqdori kamayishi kerak, chunki bu katta vaqt talab etadi.
Lekin bu hammasi emas. Agar biz ba'zi bloklar zaxira mustahkamlik nuqtasiga o'zgartirilishini bilsak, uni o'tmishda o'zgartira olmaymiz. Ya'ni, endi bizda WAL-delta yo'nalishini fayl bo'yicha optimallashtirish mavjud. Bu shuni anglatadiki, masalan, seshanba kuni ba'zi jadvallar butunlay o'chirilgan bo'lsa yoki ba'zi fayllar jadvaldan butunlay o'chirilgan bo'lsa, dushanba kuni delta aylantirilganda va shanba kuni pg_basebackup tiklanganda, biz bu ma'lumotlarni hatto yaratmaymiz.
Biz ushbu texnologiyani sahifa darajasiga kengaytirmoqchimiz. Ya'ni, agar faylning ba'zi qismi dushanba kuni o'zgarsa, lekin chorshanba kuni ustiga yozilsa, payshanba kuni bir nuqtaga qayta tiklanganda, biz sahifalarning dastlabki bir nechta versiyalarini diskka yozishimiz shart emas.
Ammo bu hali ham bizning ichimizda faol muhokama qilinayotgan g'oya, lekin u hali kodga etib bormagan.
Biz WAL-G-da yana bir xususiyat yaratmoqchimiz. Biz uni kengaytiriladigan qilishni xohlaymiz, chunki biz turli ma'lumotlar bazalarini qo'llab-quvvatlashimiz kerak va zaxira boshqaruviga xuddi shu tarzda yondashishni xohlaymiz. Ammo muammo shundaki, MySQL API-lari tubdan farq qiladi. MySQL da PITR jismoniy WAL jurnaliga emas, balki binlogga asoslangan. Va bizning MySQL-da ba'zi tashqi tizimlarga ushbu binlog tugaganligini va arxivlanishi kerakligini bildiradigan arxivlash tizimi yo'q. Biz ma'lumotlar bazasi bilan cronda bir joyda turishimiz va tayyor narsa borligini tekshirishimiz kerakmi?
Xuddi shu tarzda, MySQL-ni tiklash paytida, tizimga menga bunday va shunga o'xshash fayllar kerakligini aytadigan hech qanday tiklash buyrug'i yo'q. Klasterni qayta tiklashni boshlashdan oldin, sizga qanday fayllar kerakligini bilishingiz kerak. Sizga qanday fayllar kerakligini o'zingiz taxmin qilishingiz kerak. Ammo bu muammolarni qandaydir tarzda chetlab o'tish mumkin. (Tushuntirish: MySQL allaqachon qo'llab-quvvatlanadi)
Hisobotda men WAL-G sizga mos kelmagan holatlar haqida ham gapirmoqchi edim.
Agar sizda sinxron nusxa bo'lmasa, WAL-G oxirgi segmentning saqlanib qolishiga kafolat bermaydi. Va agar arxivlash tarixning so'nggi bir necha segmentlaridan orqada qolsa, bu xavf tug'diradi. Sinxron replika bo'lmasa, WAL-G dan foydalanishni tavsiya etmayman. Shunday bo'lsa-da, u asosan bulutli o'rnatish uchun mo'ljallangan, bu oxirgi bajarilgan baytlarning xavfsizligi uchun mas'ul bo'lgan sinxron replika bilan yuqori mavjudlik echimini nazarda tutadi.
Men tez-tez odamlarni bir vaqtning o'zida WAL-G va WAL-E ni ishga tushirishga harakat qilayotganlarini ko'raman. Biz WAL-G faylni WAL-E-dan tiklashi va WAL-E-da yaratilgan zaxira nusxasini tiklashi mumkinligi ma'nosida orqaga qarab muvofiqlikni qo'llab-quvvatlaymiz. Ammo bu ikkala tizim ham parallel wal-push ishlatganligi sababli ular bir-biridan fayllarni o'g'irlashni boshlaydilar. Agar biz uni WAL-G da tuzatsak, u hali ham WAL-E da qoladi. WAL-E-da u arxiv holatini ko'rib chiqadi, tayyor fayllarni ko'radi va ularni arxivlaydi, boshqa tizimlar esa bu WAL fayli mavjudligini bilishmaydi, chunki PostgreSQL uni ikkinchi marta arxivlashga urinmaydi.
WAL-G tomonida nimani tuzatamiz? Biz PostgreSQL-ga ushbu fayl parallel ravishda uzatilganligi haqida xabar bermaymiz va PostgreSQL bizdan uni arxivlashni so'raganda, biz ushbu rejim vaqti va md5 bilan bunday fayl allaqachon arxivlanganligini bilib olamiz va biz shunchaki PostgreSQL deb aytamiz - OK, hech narsa qilmasdan hamma narsa tayyor.
Ammo bu muammoni WAL-E tomonida hal qilish dargumon, shuning uchun hozirda faylni WAL-G va WAL-E da arxivlaydigan arxiv buyrug'ini yaratish mumkin emas.
Bundan tashqari, WAL-G hozir siz uchun mos bo'lmagan holatlar mavjud, ammo biz uni albatta tuzatamiz.
Birinchidan, bizda hozirda o'rnatilgan zaxira tekshiruvi mavjud emas. Zaxira nusxalash yoki tiklash vaqtida bizda tekshirish yo'q. Albatta, bu bulutda amalga oshiriladi. Lekin bu shunchaki oldindan tekshirish orqali, shunchaki klasterni tiklash orqali amalga oshiriladi. Men ushbu funksiyani foydalanuvchilarga bermoqchiman. Ammo tekshirish orqali WAL-G da klasterni qayta tiklash va uni ishga tushirish va tutun testlarini o'tkazish mumkin bo'ladi deb o'ylayman: pg_dumpall - /dev/null va amcheck indeksini tekshirish.
Hozirda WAL-G-da WAL-dan bitta zaxira nusxasini kechiktirishning iloji yo'q. Ya'ni, biz ba'zi oynani qo'llab-quvvatlaymiz. Misol uchun, oxirgi etti kunni saqlash, oxirgi o'nta zaxira nusxasini saqlash, oxirgi uchta to'liq zaxira nusxasini saqlash. Ko'pincha odamlar kelib: "Bizga Yangi yilda sodir bo'lgan voqealarning zaxira nusxasi kerak va biz uni abadiy saqlashni xohlaymiz", deyishadi. WAL-G buni qanday qilishni hali bilmaydi. (Eslatma - Bu allaqachon tuzatilgan. Batafsil o'qing - Zaxiralash belgisi opsiyasi )
Va bizda PITRni tekshirishda barcha shaft segmentlari uchun sahifa nazorati summalari va yaxlitlik tekshiruvlari mavjud emas.
Bularning barchasidan men Google Summer of Code loyihasini tuzdim. Agar siz Go'da biror narsa yozishni va "G" harfi bilan bitta kompaniyadan bir necha ming dollar olishni xohlaydigan aqlli talabalarni bilsangiz, ularga loyihamizni tavsiya eting. Men ushbu loyiha uchun murabbiy sifatida ishlayman, ular buni qila oladilar. Agar talabalar bo'lmasa, yozda o'zim olib ketaman.
Va bizda asta-sekin ishlayotgan boshqa ko'plab kichik muammolar mavjud. Va juda g'alati narsalar sodir bo'ladi.
Misol uchun, agar siz WAL-G-ga bo'sh zaxira nusxasini bersangiz, u shunchaki tushadi. Misol uchun, agar siz unga bo'sh papkani zaxiralashi kerakligini aytsangiz. pg_control fayli u erda bo'lmaydi. Va u nimanidir tushunmayapti deb o'ylaydi. Nazariy jihatdan, bu holda siz foydalanuvchiga vositadan qanday foydalanishni tushuntirish uchun oddiy xabar yozishingiz kerak. Ammo bu hatto dasturlashning xususiyati emas, balki yaxshi, tushunarli tilning xususiyati.
Oflayn zaxiralashni qanday qilishni bilmaymiz. Agar ma'lumotlar bazasi yolg'on bo'lsa, biz uni zaxiralay olmaymiz. Ammo bu erda hamma narsa juda oddiy. Biz LSN ishga tushirilganda zaxiralashni chaqiramiz. Asosiy ma'lumotlar bazasining LSN ni nazorat faylidan o'qish kerak. Va bu amalga oshirilmagan xususiyatdir. Ko'pgina zaxira tizimlari asosiy ma'lumotlar bazasini zaxiralashi mumkin. Va bu qulay.
Biz hozirda zaxira bo'sh joy etishmasligini to'g'ri hal qila olmaymiz. Chunki biz odatda uyda katta zaxiralar bilan ishlaymiz. Va ular bunga erisha olishmadi. Ammo agar kimdir hozir Go'da dasturlashmoqchi bo'lsa, paqirga bo'sh joydan tashqari xatolar uchun ishlov berishni qo'shing. Men tortishish so'rovini albatta ko'rib chiqaman.
Va bizni tashvishga soladigan asosiy narsa shundaki, biz turli stsenariylarni tekshiradigan iloji boricha ko'proq docker integratsiya testlarini xohlaymiz. Hozir biz faqat asosiy stsenariylarni sinab ko'rmoqdamiz. Har bir topshiriqda, lekin biz qo'llab-quvvatlagan barcha funktsiyalarni bajarish bo'yicha tekshirishni xohlaymiz. Xususan, masalan, PostgreSQL 9.4-9.5 uchun bizda yetarlicha yordam bo'ladi. Biz ularni qoβllab-quvvatlaymiz, chunki hamjamiyat PostgreSQL-ni qoβllab-quvvatlaydi, lekin hamma narsa buzilmaganligiga ishonch hosil qilish uchun majburiyat boβyicha majburiyatlarni tekshirmaymiz. Va menimcha, bu juda jiddiy xavf.
Bizda Yandex ma'lumotlar bazasi boshqaruvida mingdan ortiq klasterlarda ishlaydigan WAL-G mavjud. Va u har kuni bir necha yuz terabayt ma'lumotlarni zaxiralaydi.
Bizning kodimizda juda ko'p TODO mavjud. Agar siz dasturlashni istasangiz, keling, biz tortishish so'rovlarini kutamiz, biz savollarni kutamiz.
Sizning savollaringiz
Hayrli kech! Rahmat! Mening taxminimcha, agar siz WAL-delta dan foydalanayotgan bo'lsangiz, ehtimol siz to'liq sahifali yozishga ishonasiz. Agar shunday bo'lsa, siz testlarni o'tkazdingizmi? Siz chiroyli grafik ko'rsatdingiz. Agar FPW o'chirilgan bo'lsa, u qanchalik chiroyli bo'ladi?
To'liq sahifali yozish biz uchun yoqilgan, biz uni o'chirishga harakat qilmadik. Ya'ni, men ishlab chiquvchi sifatida uni o'chirishga harakat qilmaganman. Tadqiq qilgan tizim ma'murlari, ehtimol, bu muammoni o'rgangan. Ammo bizga FPW kerak. Deyarli hech kim uni o'chirmaydi, chunki aks holda nusxadan zaxira nusxasini olish mumkin emas.
Hisobot uchun rahmat! Menda ikkita savol bor. Birinchi savol - jadvallar bilan nima sodir bo'ladi?
Biz tortishish so'rovini kutmoqdamiz. Bizning ma'lumotlar bazalarimiz SSD va NMVE disklarida yashaydi va bizga bu xususiyat kerak emas. Men hozir buni yaxshi qilish uchun jiddiy vaqt sarflashga tayyor emasman. Men buni chin dildan qo'llab-quvvatlaymiz. Buni qoβllab-quvvatlaganlar ham bor, lekin oβzlariga mos keladigan tarzda qoβllab-quvvatlaganlar. Ular vilkalar yasadilar, lekin tortish so'rovlarini bajarmaydilar. (0.2.13 versiyasida qo'shilgan)
Va ikkinchi savol. Siz boshida aytdingizki, WAL-G u yolg'iz ishlaydi va hech qanday o'rash kerak emas deb taxmin qiladi. Men o'zim o'ramlardan foydalanaman. Nega ulardan foydalanmaslik kerak?
Biz buni balalayka kabi oddiy bo'lishini xohlaymiz. Bu sizga balalaykadan boshqa hech narsa kerak emasligini anglatadi. Biz tizim oddiy bo'lishini xohlaymiz. Agar sizda skriptda bajarishingiz kerak bo'lgan funksiyangiz bo'lsa, keling va bizga ayting - biz buni Go'da qilamiz.
Hayrli kech! Hisobot uchun rahmat! WAL-G-ni GPG shifrini ochish bilan ishlashga erisha olmadik. U odatdagidek shifrlaydi, lekin parolni ochishni xohlamaydi. Bu biz uchun ishlamagan narsami? Vaziyat tushkunlikka tushadi.
GitHub-da muammo yarating va uni aniqlaymiz.
Ya'ni, siz bunga duch kelmadingizmi?
Xatolik hisobotining o'ziga xos xususiyati borki, WAL-G qanday fayl ekanligini tushunmasa, u: "Balki u shifrlangandir?" Ehtimol, muammo umuman shifrlash emas. Men ushbu mavzu bo'yicha jurnalni yaxshilashni xohlayman. U buni shifrlashi kerak. Hozirda biz ushbu mavzu ustida ishlayapmiz, chunki ochiq va shaxsiy kalitlarni olish tizimi qanday tashkil etilganligi bizga yoqmaydi. Chunki biz tashqi GPG ni chaqiramiz, shunda u bizga kalitlarini beradi. Va keyin biz ushbu kalitlarni olamiz va ularni WAL-G ichida biz uchun tuzilgan ochiq PGP bo'lgan ichki GPG-ga o'tkazamiz va u erda biz shifrlashni chaqiramiz. Shu munosabat bilan biz tizimni takomillashtirishni xohlaymiz va Libsodium shifrlashni qo'llab-quvvatlamoqchimiz (0.2.15 versiyasida qo'shilgan). Albatta, dekodlash ishlashi kerak, keling, buni aniqlaylik - sizga bir necha so'zdan ko'ra ko'proq alomat kerak. Siz qachondir ma'ruzachi xonasiga yig'ilib, tizimga qarashingiz mumkin. (Tashqi GPGsiz PGP shifrlash - v0.2.9)
Salom! Hisobot uchun rahmat! Menda ikkita savol bor. Menda ikkita provayderda pg_basebackup va WAL logini qilish g'alati istagi bor, ya'ni men bitta bulutni va boshqasini qilishni xohlayman. Buni qilishning biron bir usuli bormi?
Bu hozir mavjud emas, lekin bu qiziq fikr.
Men bitta provayderga ishonmayman, boshqasida ham xuddi shunday bo'lishini xohlayman.
Fikr qiziq. Texnik jihatdan, buni amalga oshirish unchalik qiyin emas. G'oyaning yo'qolishiga yo'l qo'ymaslik uchun sizdan GitHub-da muammo yaratishingizni so'raymanmi?
Ha albatta.
Va keyin, talabalar Google Summer of Code dasturiga kelganlarida, biz ulardan ko'proq foyda olish uchun ko'proq ish bo'lishi uchun ularni loyihaga qo'shamiz.
Va ikkinchi savol. GitHub-da muammo bor. Menimcha, u allaqachon yopilgan. Qayta tiklash vaqtida vahima bor. Va uni mag'lub qilish uchun siz alohida yig'ilish qildingiz. Bu masalalarda to'g'ri. Va bitta ipda o'zgaruvchan muhitni qilish imkoniyati mavjud. Va shuning uchun u juda sekin ishlaydi. Va biz bu muammoga duch keldik va u hali tuzatilgani yo'q.
Muammo shundaki, ba'zi sabablarga ko'ra saqlash (CEPH) biz unga yuqori parallellik bilan kelganimizda ulanishni tiklaydi. Bu borada nima qilish mumkin? Qayta urinish mantig'i shunday ko'rinadi. Faylni yana yuklab olishga harakat qilyapmiz. Bitta o'tishda bizda yuklab olinmagan bir nechta fayllar bor edi, biz tizimga kirmaganlar uchun ikkinchisini qilamiz. Va har bir iteratsiya uchun kamida bitta fayl yuklangan ekan, biz takrorlaymiz va takrorlaymiz va takrorlaymiz. Biz qayta urinish mantig'ini yaxshiladik - eksponensial orqaga qaytish. Ammo saqlash tizimi tomonida ulanishning oddiygina uzilishi bilan nima qilish kerakligi to'liq aniq emas. Ya'ni, biz bitta oqimga yuklaganimizda, bu ulanishlarni buzmaydi. Bu erda nimani yaxshilashimiz mumkin? Bizda tarmoqni qisqartirish mavjud, biz har bir ulanishni yuboradigan baytlar soni bilan cheklashimiz mumkin. Aks holda, ob'ektni saqlash bizga parallel ravishda yuklab olish yoki yuklab olish imkonini bermasligi bilan qanday kurashishni bilmayman.
SLA yo'qmi? Ular uchun qanday qilib o'zlarini qiynashlariga yo'l qo'yishlari yozilgan emasmi?
Gap shundaki, bu savol bilan kelgan odamlar odatda o'z omboriga ega. Ya'ni, Amazon yoki Google Cloud yoki Yandex Object Storage'dan hech kim kelmaydi.
Balki savol endi siz uchun emasdir?
Bu holatda bu erda savol kim uchun muhim emas. Agar buni qanday hal qilish bo'yicha har qanday g'oyalar mavjud bo'lsa, keling, buni WAL-Gda qilaylik. Ammo hozircha men buni qanday hal qilish haqida yaxshi fikrga ega emasman. Ro'yxatning zaxira nusxalarini boshqacha qo'llab-quvvatlaydigan ba'zi Ob'ektlarni saqlash joylari mavjud. Siz ulardan ob'ektlar ro'yxatini so'raysiz va ular u erga papkani qo'shadilar. WAL-G bundan qo'rqadi - bu erda fayl emas, qandaydir narsa bor, men uni qayta tiklay olmayman, demak, zaxira qayta tiklanmagan. Ya'ni, aslida sizda butunlay tiklangan klaster bor, lekin u sizga noto'g'ri holatni qaytaradi, chunki Object Storage to'liq tushunmagan g'alati ma'lumotlarni qaytardi.
Bu Pochta bulutida sodir bo'ladigan narsa.
Agar siz reproduktsiyani yarata olsangiz ...
U doimiy ravishda takrorlanadi ...
Agar takrorlash mavjud bo'lsa, menimcha, biz qayta urinib ko'rish strategiyalari bilan tajriba o'tkazamiz va qanday qilib qayta urinib ko'rishimiz va bulut bizdan nimani talab qilishini tushunamiz. Ehtimol, bu biz uchun uchta ulanishda barqaror bo'ladi va aloqani buzmaydi, keyin ehtiyotkorlik bilan uchtaga etib boramiz. Chunki endi biz ulanishni juda tez to'xtatamiz, ya'ni agar biz 16 ta ip bilan tiklashni ishga tushirgan bo'lsak, unda birinchi qayta urinishdan keyin 8 ta ip, 4 ta ip, 2 ta ip va bitta bo'ladi. Va keyin u faylni bitta oqimga tortadi. Agar sehrli qiymatlar mavjud bo'lsa, masalan, 7,5 ip nasos uchun eng yaxshisi, biz ular ustida to'xtalib, yana 7,5 ip yasashga harakat qilamiz. Mana bir fikr.
Hisobot uchun rahmat! WAL-G bilan ishlash uchun to'liq ish jarayoni qanday ko'rinadi? Misol uchun, sahifalar bo'ylab delta bo'lmagan ahmoqona holatda. Va biz dastlabki zahirani olib, olib tashlaymiz, so'ngra yuzimiz ko'k bo'lmaguncha milni arxivlaymiz. Bu erda, men tushunganimdek, buzilish mavjud. Bir nuqtada siz sahifalarning delta zahirasini yaratishingiz kerak, ya'ni ba'zi tashqi jarayon buni boshqaradi yoki bu qanday sodir bo'ladi?
Delta zaxira API juda oddiy. U erda raqam bor - maksimal delta qadamlari, bu shunday deyiladi. U standart nolga teng. Bu shuni anglatadiki, siz har safar zaxira nusxasini yuklaganingizda, u to'liq zaxira nusxasini yuklab oladi. Agar siz uni biron-bir ijobiy raqamga o'zgartirsangiz, masalan, 3, keyin keyingi safar zaxira-pushni amalga oshirganingizda, u avvalgi zaxiralar tarixiga qaraydi. U sizni 3 delta zanjiridan oshmaganingizni ko'radi va delta qiladi.
Ya'ni, biz har safar WAL-G-ni ishga tushirganimizda, u to'liq zaxira nusxasini yaratishga harakat qiladimi?
Yo'q, biz WAL-G-ni ishga tushiramiz va agar sizning siyosatingiz ruxsat bersa, u delta yaratishga harakat qiladi.
Taxminan aytganda, agar siz uni har safar nol bilan ishlatsangiz, u pg_basebackup kabi harakat qiladimi?
Yo'q, u hali ham tezroq ishlaydi, chunki u siqish va parallelizmdan foydalanadi. Pg_basebackup milni yoningizga qo'yadi. WAL-G siz arxivlash sozlangan deb hisoblaydi. Va agar u sozlanmagan bo'lsa, u ogohlantirish beradi.
Pg_basebackup vallarsiz ishga tushirilishi mumkin.
Ha, keyin ular deyarli bir xil yo'l tutishadi. Pg_basebackup fayl tizimiga nusxa ko'chiradi. Aytgancha, biz eslatishni unutgan yangi xususiyatga egamiz. Endi biz pg_basebackup-dan fayl tizimiga zaxiralashimiz mumkin. Bu nima uchun kerakligini bilmayman, lekin u erda.
Masalan, CephFS-da. Hamma ham Ob'ektni saqlashni sozlashni xohlamaydi.
Ha, ehtimol shuning uchun ular biz buni qila olishimiz uchun ushbu xususiyat haqida savol berishdi. Va biz buni qildik.
Hisobot uchun rahmat! Fayl tizimiga nusxa ko'chirish haqida faqat savol bor. Endi siz masofaviy xotiraga nusxalashni qo'llab-quvvatlaysizmi, masalan, ma'lumotlar markazida javon yoki boshqa biror narsa bo'lsa?
Ushbu formulada bu qiyin savol. Ha, biz qo'llab-quvvatlaymiz, ammo bu funksiya hali hech qanday versiyaga kiritilmagan. Ya'ni, barcha pre-relizlar buni qo'llab-quvvatlaydi, ammo reliz versiyalari buni qo'llab-quvvatlamaydi. Ushbu funksiya 0.2 versiyasida qo'shilgan. Ma'lum bo'lgan barcha xatolarni tuzatganimizdan so'ng, u albatta tez orada chiqariladi. Ammo hozir buni faqat pre-relizda qilish mumkin. Pre-relizda ikkita xato bor. WAL-E-ni tiklash bilan bog'liq muammo, biz uni tuzatmadik. Va oxirgi versiyada delta-zaxira haqida xato qo'shildi. Shuning uchun biz hammaga reliz versiyalaridan foydalanishni tavsiya qilamiz. Pre-relizda boshqa xatoliklar yo'qligi bilanoq, biz Google Cloud, S3-ga mos keladigan narsalarni va fayllarni saqlashni qo'llab-quvvatlaymiz, deb ayta olamiz.
Salom, hisobot uchun rahmat. Men tushunganimdek, WAL-G barmen kabi markazlashtirilgan tizim emasmi? Ushbu yo'nalishda harakat qilishni rejalashtiryapsizmi?
Muammo shundaki, biz bu yo'nalishdan uzoqlashdik. WAL-G asosiy xostda, klaster xostida va klasterdagi barcha xostlarda yashaydi. Biz bir necha ming klasterga ko'chib o'tganimizda, bizda ko'plab barmenlar o'rnatildi. Va har safar ularda biror narsa parchalanib ketganda, bu katta muammoga aylanadi. Ularni ta'mirlash kerakligi sababli, hozir qaysi klasterlarning zaxira nusxalari yo'qligini tushunishingiz kerak. Men WAL-G-ni zaxira tizimlari uchun jismoniy apparat yo'nalishida ishlab chiqishni rejalashtirmayman. Agar hamjamiyat bu yerda qandaydir funksionallikni xohlasa, men bunga qarshi emasman.
Bizda saqlash uchun mas'ul bo'lgan guruhlar mavjud. Va biz o'zimizni juda yaxshi his qilamizki, bu biz emas, chunki bizning fayllarimizni xavfsiz joyga qo'yadigan maxsus odamlar bor. Ular ma'lum miqdordagi fayllarning yo'qolishiga qarshi turish uchun u erda har qanday aqlli kodlashni amalga oshiradilar. Ular tarmoqning o'tkazish qobiliyati uchun javobgardir. Agar sizda bufetchi bo'lsa, siz to'satdan bir xil serverda juda ko'p trafikka ega bo'lgan kichik ma'lumotlar bazalari to'planganligini bilib olishingiz mumkin. Sizda juda ko'p joy borga o'xshaydi, lekin negadir hamma narsa tarmoq orqali mos kelmaydi. Bu aksincha bo'lishi mumkin. U erda juda ko'p tarmoqlar mavjud, protsessor yadrolari bor, lekin bu erda disklar yo'q. Va biz nimanidir o'ynash zaruratidan charchadik va biz ma'lumotlarni saqlash alohida xizmat ekanligiga o'tdik, buning uchun alohida maxsus odamlar javobgardir.
P.S. Yangi versiya chiqdi , unda siz sukut bo'yicha postgres uy katalogida joylashgan .walg.json konfiguratsiya faylidan foydalanishingiz mumkin. Siz bash skriptlaridan voz kechishingiz mumkin. .walg.json misoli bu nashrda
Video:
Manba: www.habr.com