Men sizga 2016 yil boshidan Andrey Salnikovning "Postgresql-da shishirishga olib keladigan ilovalardagi odatiy xatolar" hisobotining transkriptini o'qishni taklif qilaman.
Ushbu hisobotda men dastur kodini loyihalash va yozish bosqichida yuzaga keladigan ilovalardagi asosiy xatolarni tahlil qilaman. Va men faqat Postgresql-da shishishga olib keladigan xatolarni olaman. Qoidaga ko'ra, bu butun tizimingizning ishlashi tugashining boshlanishi, garchi dastlab buning uchun hech qanday shartlar ko'rinmas edi.
Barchani tabriklashdan xursandman! Ushbu hisobot mening hamkasbimning oldingi hisoboti kabi texnik emas. Ushbu hisobot asosan tizimni ishlab chiquvchilarga qaratilgan, chunki bizda juda ko'p mijozlar bor. Va ularning barchasi bir xil xatolarga yo'l qo'yishadi. Men sizga ular haqida aytib beraman. Men bu xatolar qanday halokatli va yomon narsalarga olib kelishini tushuntiraman.
Nima uchun xatolarga yo'l qo'yiladi? Ular ikkita sababga ko'ra amalga oshiriladi: tasodifiy, ehtimol u ishlab chiqiladi va ma'lumotlar bazasi va dastur o'rtasidagi darajada, shuningdek ma'lumotlar bazasining o'zida yuzaga keladigan ba'zi mexanizmlarni bilmaslik tufayli.
Men sizga yomon narsalarning dahshatli suratlari bilan uchta misol keltiraman. Men sizga u erda sodir bo'ladigan mexanizm haqida qisqacha aytib beraman. Va ular bilan qanday kurashish kerak, ular qachon sodir bo'lgan va xatolarni oldini olish uchun qanday profilaktika usullaridan foydalanish kerak. Men sizga yordamchi vositalar haqida gapirib beraman va foydali havolalar beraman.
Men ikkita jadvalga ega bo'lgan test ma'lumotlar bazasidan foydalandim. Bir plastinkada mijozlar hisoblari, ikkinchisida esa ushbu hisoblar bo'yicha operatsiyalar mavjud. Va ma'lum bir chastota bilan biz ushbu hisoblardagi qoldiqlarni yangilaymiz.
Plastinaning dastlabki ma'lumotlari: u juda kichik, 2 MB. Ma'lumotlar bazasi va ayniqsa, belgi uchun javob vaqti ham juda yaxshi. Va juda yaxshi yuk - plastinkaga ko'ra soniyada 2 operatsiya.
Va bu hisobot orqali men sizga nima bo'layotganini aniq tushunishingiz uchun grafiklarni ko'rsataman. Har doim grafiklar bilan 2 ta slayd bo'ladi. Birinchi slayd - bu serverda nima sodir bo'lishi.
Va bu vaziyatda biz haqiqatan ham kichik bir belgi borligini ko'ramiz. Indeks kichik, 2 MB. Bu chapdagi birinchi grafik.
Serverdagi o'rtacha javob vaqti ham barqaror va qisqa. Bu yuqori o'ngdagi grafik.
Pastki chap grafik eng uzun operatsiyalarni ko'rsatadi. Biz tranzaktsiyalar tezda yakunlanganini ko'ramiz. Va bu erda avtovakuum hali ishlamaydi, chunki bu boshlang'ich sinov edi. U ishlashda davom etadi va biz uchun foydali bo'ladi.
Ikkinchi slayd har doim sinovdan o'tgan plastinkaga bag'ishlangan bo'ladi. Bunday vaziyatda biz doimiy ravishda mijozning hisob balansini yangilab turamiz. Va biz yangilash operatsiyasi uchun o'rtacha javob vaqti juda yaxshi ekanligini ko'ramiz, bir millisekunddan kamroq. Biz protsessor resurslari (bu yuqori o'ng grafik) ham teng va juda kichik iste'mol qilinishini ko'ramiz.
Pastki o'ng grafik biz kerakli qatorni yangilashdan oldin qidirishda qancha operatsion va disk xotirasidan o'tishimizni ko'rsatadi. Belgiga ko'ra operatsiyalar soni esa boshida aytganimdek sekundiga 2 ta.
Va endi bizda fojia bor. Negadir uzoq vaqt unutilgan tranzaksiya mavjud. Sabablari odatda oddiy:
- Eng keng tarqalganlaridan biri shundaki, biz dastur kodida tashqi xizmatga kirishni boshladik. Va bu xizmat bizga javob bermaydi. Ya'ni biz tranzaksiya ochdik, ma'lumotlar bazasiga o'zgartirish kiritdik va ilovadan pochtani o'qishga yoki infratuzilmamiz ichidagi boshqa xizmatga o'tdik va negadir u bizga javob bermaydi. Sessiyamiz esa qachon hal etilishi nomaβlum holatda qolib ketdi.
- Ikkinchi holat, ba'zi sabablarga ko'ra bizning kodimizda istisno sodir bo'lganida. Va bundan mustasno, biz tranzaktsiyani yopishni qayta ishlamadik. Va biz ochiq bitim bilan osilgan sessiya bilan yakunlandik.
- Va oxirgisi ham juda keng tarqalgan holat. Bu past sifatli kod. Ba'zi ramkalar tranzaksiyani ochadi. U osilib turadi va siz ilovada osilganligini bilmasligingiz mumkin.
Bunday narsalar qayerga olib keladi?
Bizning jadvallarimiz va indekslarimiz keskin shishib keta boshlaydi. Bu xuddi shunday shishiradi. Ma'lumotlar bazasi uchun bu ma'lumotlar bazasiga javob berish vaqti juda keskin oshadi va ma'lumotlar bazasi serveriga yuk ko'tariladi. Va natijada bizning arizamiz zarar ko'radi. Chunki agar siz kodingizda ma'lumotlar bazasiga so'rovga 10 millisekund, mantiqingizga 10 millisekund sarflagan bo'lsangiz, u holda funksiyangizni bajarish uchun 20 millisekund kerak bo'ldi. Va endi sizning ahvolingiz juda achinarli bo'ladi.
Va keling, nima bo'lishini ko'rib chiqaylik. Pastki chap grafik bizda uzoq davom etgan tranzaksiyamiz borligini ko'rsatadi. Va agar biz yuqori chap grafikni ko'rib chiqsak, stolimiz hajmi birdan ikki megabaytdan 300 megabaytgacha ko'tarilganini ko'ramiz. Shu bilan birga, jadvaldagi ma'lumotlar miqdori o'zgarmadi, ya'ni u erda juda katta miqdordagi axlat mavjud.
Serverning o'rtacha javob vaqti bilan bog'liq umumiy vaziyat ham bir necha darajaga o'zgargan. Ya'ni, serverdagi barcha so'rovlar butunlay tushib keta boshladi. Va shu bilan birga, biror narsa qilishga harakat qiladigan va resurslarni iste'mol qiladigan avtovakuum shaklida ichki Postgres jarayonlari ishga tushirildi.
Bizning belgimiz bilan nima sodir bo'lmoqda? Xuddi shu. Belgiga ko'ra bizning o'rtacha javob vaqtimiz bir necha darajaga ko'tarildi. Xususan, iste'mol qilinadigan resurslar nuqtai nazaridan, biz protsessorga yuk sezilarli darajada oshganini ko'ramiz. Bu yuqori o'ngdagi grafik. Va u ko'paydi, chunki protsessor kerak bo'lganini izlash uchun keraksiz qatorlarni saralashi kerak. Bu pastki o'ng grafik. Natijada, sekundiga qo'ng'iroqlar soni sezilarli darajada kamaydi, chunki ma'lumotlar bazasi bir xil miqdordagi so'rovlarni qayta ishlashga ulgurmadi.
Biz hayotga qaytishimiz kerak. Biz internetga kiramiz va uzoq tranzaktsiyalar muammolarga olib kelishini aniqlaymiz. Biz ushbu tranzaksiyani topamiz va o'ldiramiz. Va biz uchun hamma narsa odatiy holga aylanib bormoqda. Hammasi kerak bo'lganidek ishlaydi.
Biz tinchlandik, lekin bir muncha vaqt o'tgach, dastur favqulodda vaziyatdan oldingi kabi ishlamasligini seza boshlaymiz. So'rovlar hali ham sekinroq va sezilarli darajada sekinroq ko'rib chiqiladi. Mening misolimda bir yarim-ikki baravar sekinroq. Serverdagi yuk ham avariyadan oldingi darajadan yuqori.
Va savol: "Ayni paytda bazaga nima bo'lyapti?" Va taglik bilan quyidagi holat yuzaga keladi. Tranzaktsiyalar jadvalida siz uning to'xtaganini va haqiqatan ham uzoq muddatli bitimlar yo'qligini ko'rishingiz mumkin. Ammo baxtsiz hodisa paytida belgining o'lchami halokatli darajada oshdi. Va shundan beri ular kamaymadi. Bazadagi o'rtacha vaqt barqarorlashdi. Va javoblar biz uchun maqbul tezlikda yetib kelayotganga o'xshaydi. Avtovakuum faollashdi va belgi bilan nimadir qila boshladi, chunki u ko'proq ma'lumotlarni elakdan o'tkazishi kerak.
Xususan, biz balanslarni o'zgartiradigan hisoblar bilan sinov plastinkasiga ko'ra: so'rovga javob berish vaqti normal holatga qaytganga o'xshaydi. Lekin aslida bu bir yarim baravar yuqori.
Va protsessordagi yukdan biz protsessordagi yuk halokatdan oldin kerakli qiymatga qaytmaganligini ko'ramiz. Va sabablar pastki o'ng grafikda aniq yotadi. U erda ma'lum hajmdagi xotira qidirilayotganini ko'rish mumkin. Ya'ni, kerakli qatorni topish uchun biz keraksiz ma'lumotlarni saralashda ma'lumotlar bazasi serverining resurslarini behuda sarflaymiz. Bir soniyada tranzaktsiyalar soni barqarorlashdi.
Umuman olganda, yaxshi, lekin vaziyat avvalgidan ham yomonroq. Ushbu ma'lumotlar bazasi bilan ishlaydigan ilovamiz natijasida ma'lumotlar bazasi degradatsiyasini tozalang.
Va u erda nima sodir bo'layotganini tushunish uchun, agar siz avvalgi hisobotda bo'lmagan bo'lsangiz, endi bir oz nazariyani olaylik. Ichki jarayon haqidagi nazariya. Nima uchun mashina changyutgichi va u nima qiladi?
Tushunish uchun tom ma'noda qisqacha. Vaqt o'tishi bilan bizda stol bor. Jadvalda qatorlar mavjud. Bu chiziqlar faol, jonli va hozir kerak bo'lgan narsalar bo'lishi mumkin. Ular rasmda yashil rang bilan belgilangan. Va allaqachon ishlab chiqilgan, yangilangan va ularda yangi yozuvlar paydo bo'lgan o'lik chiziqlar mavjud. Va ular endi ma'lumotlar bazasi uchun qiziq emas deb belgilangan. Ammo ular Postgres xususiyati tufayli jadvalda.
Nima uchun sizga avtomobil changyutgichi kerak? Bir nuqtada avtovakuum keladi, ma'lumotlar bazasiga kiradi va undan so'raydi: "Iltimos, menga hozirda ma'lumotlar bazasida ochiq bo'lgan eng eski tranzaksiyaning identifikatorini bering." Ma'lumotlar bazasi ushbu identifikatorni qaytaradi. Va avtovakuum, unga tayanib, jadvaldagi chiziqlarni saralaydi. Va agar u ba'zi qatorlar ancha eski tranzaktsiyalar tomonidan o'zgartirilganligini ko'rsa, u ularni kelajakda yangi ma'lumotlarni yozish orqali biz qayta ishlatishimiz mumkin bo'lgan chiziqlar sifatida belgilashga haqli. Bu fon jarayoni.
Ayni paytda biz ma'lumotlar bazasi bilan ishlashni davom ettirmoqdamiz va jadvalga ba'zi o'zgarishlar kiritishda davom etamiz. Va biz qayta ishlatishimiz mumkin bo'lgan ushbu satrlarda biz yangi ma'lumotlarni yozamiz. Shunday qilib, biz tsiklga ega bo'lamiz, ya'ni har doim u erda o'lik eski chiziqlar paydo bo'ladi, ularning o'rniga biz kerakli yangi satrlarni yozamiz. Va bu PostgreSQL ishlashi uchun oddiy holat.
Baxtsiz hodisa paytida nima sodir bo'ldi? Bu jarayon u erda qanday sodir bo'ldi?
Bizda biron bir holatda belgi bor edi, ba'zilari tirik, ba'zilari o'lik chiziqlar. Avtomobil changyutgichi keldi. U ma'lumotlar bazasidan bizning eng qadimgi tranzaksiyamiz nima ekanligini va uning identifikatori nima ekanligini so'radi. Men bu identifikatorni oldim, bu ko'p soatlar oldin, balki o'n daqiqa oldin bo'lishi mumkin. Bu sizning ma'lumotlar bazasidagi yuk qanchalik og'irligiga bog'liq. Va u qayta ishlatilgan deb belgilashi mumkin bo'lgan chiziqlarni qidirdi. Va men jadvalimizda bunday chiziqlarni topmadim.
Ammo bu vaqtda biz stol bilan ishlashni davom ettirmoqdamiz. Biz unda biror narsa qilamiz, uni yangilaymiz, ma'lumotlarni o'zgartiramiz. Bu vaqtda ma'lumotlar bazasi nima qilishi kerak? Uning mavjud jadvalning oxiriga yangi qatorlar qo'shishdan boshqa iloji yo'q. Shunday qilib, bizning stol o'lchamimiz shishishni boshlaydi.
Aslida, ishlash uchun bizga yashil chiziqlar kerak. Ammo bunday muammo yuzaga kelganda, butun jadval bo'ylab yashil chiziqlar ulushi juda past ekanligi ma'lum bo'ldi.
Va so'rovni bajarganimizda, kerakli qatorni topish uchun ma'lumotlar bazasi barcha qatorlardan o'tishi kerak: qizil va yashil. Jadvalni keraksiz ma'lumotlar bilan to'ldirish ta'siri "bloat" deb ataladi, bu ham bizning diskdagi bo'sh joyimizni egallaydi. Esingizdami, 2 MB edi, 300 MB bo'ldi? Endi megabaytlarni gigabaytga o'zgartiring va siz tezda barcha disk resurslaringizni yo'qotasiz.
Biz uchun qanday oqibatlarga olib kelishi mumkin?
- Mening misolimda jadval va indeks 150 marta o'sdi. Bizning ba'zi mijozlarimiz diskda bo'sh joy tugashi bilan ko'proq halokatli holatlarga duch kelishdi.
- Jadvallarning o'lchami hech qachon kamaymaydi. Avtovakuum, ba'zi hollarda, agar faqat o'lik chiziqlar bo'lsa, stolning dumini kesib tashlashi mumkin. Ammo doimiy aylanish mavjud bo'lganligi sababli, bitta yashil chiziq oxirida muzlatib qo'yishi va yangilanmasligi mumkin, qolganlari esa plastinka boshida biror joyga yozib qo'yiladi. Ammo bu shunday bo'lishi mumkin bo'lmagan hodisaki, stolingizning o'zi kichrayadi, shuning uchun siz bunga umid qilmasligingiz kerak.
- Ma'lumotlar bazasi keraksiz qatorlarni saralashi kerak. Va biz disk resurslarini isrof qilamiz, protsessor resurslari va elektr energiyasini isrof qilamiz.
- Va bu bizning ilovamizga bevosita ta'sir qiladi, chunki agar boshida biz so'rovga 10 millisekund, kodimizga 10 millisekund sarflagan bo'lsak, buzilish paytida biz so'rovga bir soniya va kodga 10 millisekund sarflay boshladik, ya'ni. qo'llash samaradorligining kattaligi kamaydi. Va avariya bartaraf etilgach, biz so'rovga 20 millisekund, kodga 10 millisekund sarflay boshladik. Demak, hosildorlik hali ham bir yarim baravar pasaygan. Va bularning barchasi, ehtimol bizning aybimiz tufayli muzlatilgan bitta tranzaktsiya tufayli.
- Va savol: "Qanday qilib biz hamma narsani qaytarib olamiz?" Bizda hamma narsa yaxshi bo'ladi va so'rovlar voqea sodir bo'lgandan oldingi kabi tez keladi.
Shu maqsadda amalga oshiriladigan ishning ma'lum bir tsikli mavjud.
Avval biz shishgan muammoli jadvallarni topishimiz kerak. Biz tushunamizki, ba'zi jadvallarda yozuv faolroq, boshqalarida esa kamroq faol. Va buning uchun biz kengaytmadan foydalanamiz . Ushbu kengaytmani o'rnatish orqali siz juda shishgan jadvallarni topishga yordam beradigan so'rovlarni yozishingiz mumkin.
Ushbu jadvallarni topganingizdan so'ng, ularni siqish kerak. Buning uchun allaqachon vositalar mavjud. Kompaniyamizda biz uchta vositadan foydalanamiz. Birinchisi, o'rnatilgan VACUUM FULL. U shafqatsiz, qattiqqo'l va shafqatsiz, lekin ba'zida u juda foydali. ΠΈ - Bu jadvallarni siqish uchun uchinchi tomon yordamchi dasturlari. Va ular ma'lumotlar bazasiga ehtiyotkorlik bilan munosabatda bo'lishadi.
Ular siz uchun qulayroq bo'lgan narsaga qarab ishlatiladi. Ammo men sizga bu haqda oxirida aytib beraman. Asosiysi, uchta vosita mavjud. Tanlash uchun juda ko'p narsa bor.
Biz hamma narsani tuzatib, hamma narsa yaxshi ekanligiga ishonch hosil qilganimizdan so'ng, kelajakda bu vaziyatni qanday oldini olishni bilishimiz kerak:
- Uni juda oson oldini olish mumkin. Master serverda seanslar davomiyligini kuzatishingiz kerak. Tranzaksiya holatida, ayniqsa xavfli seanslar. Bular endigina tranzaktsiyani ochgan, nimadir qilgan va ketgan yoki shunchaki osilgan, kodda adashganlar.
- Va siz uchun, ishlab chiquvchilar sifatida, bunday vaziyatlar yuzaga kelganda kodingizni sinab ko'rish juda muhimdir. Buni qilish qiyin emas. Bu foydali tekshirish bo'ladi. Uzoq muddatli tranzaktsiyalar bilan bog'liq ko'plab "bolalarcha" muammolardan qochasiz.
Ushbu grafiklarda men bu holatda VACUUM FULL belgisidan o'tganimdan keyin ma'lumotlar bazasi belgisi va xatti-harakati qanday o'zgarganini ko'rsatmoqchi edim. Bu men uchun ishlab chiqarish emas.
Jadval hajmi darhol bir necha megabaytlik normal ish holatiga qaytdi. Bu server uchun o'rtacha javob vaqtiga katta ta'sir ko'rsatmadi.
Lekin, xususan, hisob balanslarini yangilagan sinov belgisi uchun, belgidagi ma'lumotlarni yangilash so'roviga o'rtacha javob vaqti favqulodda vaziyatlardan oldingi darajaga qisqarganini ko'ramiz. Ushbu so'rovni bajarish uchun protsessor tomonidan iste'mol qilinadigan resurslar ham buzilishdan oldingi darajaga tushib ketdi. Va pastki o'ng grafik shuni ko'rsatadiki, biz stol siqilishidan oldin mavjud bo'lgan o'lik chiziqlar to'plamidan o'tmasdan, biz darhol kerakli chiziqni topamiz. Va o'rtacha so'rov vaqti taxminan bir xil darajada qoldi. Ammo bu erda mening apparatimda xatolik bor.
Birinchi hikoya shu erda tugaydi. Bu eng keng tarqalgan. Va bu mijozning tajribasi va dasturchilar qanchalik malakali bo'lishidan qat'i nazar, hamma bilan sodir bo'ladi. Ertami-kechmi bu sodir bo'ladi.
Ikkinchi hikoya, unda biz yukni taqsimlaymiz va server resurslarini optimallashtiramiz
- Biz allaqachon katta bo'lib, jiddiy yigitlarga aylandik. Va bizda replika borligini tushunamiz va yukni muvozanatlash biz uchun yaxshi bo'lardi: Ustaga yozing va replikadan o'qing. Va odatda bu holat biz ba'zi hisobotlarni yoki ETLni tayyorlamoqchi bo'lganimizda paydo bo'ladi. Va biznes bundan juda xursand. U haqiqatan ham juda ko'p murakkab tahlillarga ega bo'lgan turli xil hisobotlarni xohlaydi.
- Hisobotlar ko'p soatlarni oladi, chunki murakkab tahlillarni millisekundlarda hisoblash mumkin emas. Biz, jasur yigitlar kabi, kod yozamiz. Qo'shish ilovasida biz Master-da yozuvni amalga oshiramiz va replika bo'yicha hisobotlarni bajaramiz.
- Yukni taqsimlash.
- Hammasi mukammal ishlaydi. Biz ajoyibmiz.
Va bu vaziyat qanday ko'rinadi? Xususan, ushbu grafiklarda men replikatsiyadan tranzaktsiyalar davomiyligini ham qo'shdim. Boshqa barcha grafiklar faqat asosiy serverga tegishli.
Bu vaqtga kelib mening hisobotlar kengashim ko'payib ketdi. Ulardan ko'proq. Biz serverning o'rtacha javob vaqti barqaror ekanligini ko'ramiz. Replikada bizda 2 soat davom etadigan uzoq muddatli tranzaksiya borligini ko'ramiz. Biz o'lik chiziqlarni qayta ishlaydigan avtovakuumning jim ishlashini ko'ramiz. Va bizda hamma narsa yaxshi.
Xususan, sinovdan o'tgan plastinkaga ko'ra, biz u erda hisob balanslarini yangilashni davom ettiramiz. Shuningdek, bizda so'rovlar uchun barqaror javob vaqti, barqaror resurslar iste'moli mavjud. Bizda hammasi yaxshi.
Replikatsiya bilan ziddiyat tufayli ushbu hisobotlar qayta ishga tushmaguncha hammasi yaxshi. Va ular muntazam ravishda o'q uzadilar.
Biz internetga kiramiz va nima uchun bu sodir bo'layotganini o'qishni boshlaymiz. Va biz yechim topamiz.
Birinchi yechim replikatsiya kechikishini oshirishdir. Bizning hisobotimiz 3 soat davom etishini bilamiz. Biz replikatsiya kechikishini 3 soatga o'rnatdik. Biz hamma narsani ishga tushirmoqdamiz, lekin biz hali ham ba'zida hisobotlarni bekor qilish bilan bog'liq muammolarga duch kelamiz.
Biz hamma narsa mukammal bo'lishini xohlaymiz. Biz ko'proq ko'tarilamiz. Va biz Internetda ajoyib sozlamani topdik - hot_standby_feedback. Keling, uni yoqaylik. Hot_standby_feedback bizga Masterdagi avtovakuumni ushlab turishga imkon beradi. Shunday qilib, biz replikatsiya ziddiyatlaridan butunlay xalos bo'lamiz. Va hisobotlar bilan biz uchun hamma narsa yaxshi ishlaydi.
Va bu vaqtda Master server bilan nima sodir bo'lmoqda? Va biz Master server bilan muammoga duch keldik. Endi biz ushbu ikkala sozlamalar yoqilgan bo'lsa, grafiklarni ko'rmoqdamiz. Va biz nusxamizdagi sessiya qandaydir tarzda Master serverdagi vaziyatga ta'sir qila boshlaganini ko'ramiz. Uning ta'siri bor, chunki u o'lik chiziqlarni tozalaydigan avtovakuumni to'xtatdi. Bizning stolimiz yana osmonga ko'tarildi. Butun ma'lumotlar bazasi bo'ylab so'rovlarni bajarishning o'rtacha vaqti ham keskin oshdi. Avtovakuumlar biroz qattiqlashdi.
Xususan, bizning plastinkamizdan biz undagi ma'lumotlarning yangilanishi ham osmonga ko'tarilganini ko'ramiz. Xuddi shunday, protsessor iste'moli sezilarli darajada oshdi. Biz yana ko'p sonli o'lik, keraksiz chiziqlardan o'tmoqdamiz. Va bu belgi uchun javob vaqti va tranzaktsiyalar soni kamaydi.
Oldin nima haqida gapirganimni bilmasak, bu qanday ko'rinishga ega bo'ladi?
- Biz muammolarni qidirishni boshlaymiz. Agar biz birinchi qismda muammolarga duch kelgan bo'lsak, bu uzoq tranzaksiya tufayli bo'lishi mumkinligini bilamiz va Masterga boramiz. Ustada muammomiz bor. Unga kolbasa. U qiziydi, uning o'rtacha yuk ko'rsatkichi yuzga yaqin.
- U erda so'rovlar sekin, lekin biz u erda uzoq muddatli tranzaksiyalarni ko'rmayapmiz. Va biz nima bo'lganini tushunmayapmiz. Biz qaerga qarashni tushunmayapmiz.
- Biz server uskunasini tekshiramiz. Ehtimol, bizning reydimiz halokatga uchragan. Balki xotira kartamiz yonib ketgandir. Ha, hamma narsa bo'lishi mumkin. Lekin yo'q, serverlar yangi, hammasi yaxshi ishlaydi.
- Hamma ishlaydi: ma'murlar, ishlab chiquvchilar va direktor. Hech narsa yordam bermaydi.
- Va bir nuqtada hamma narsa to'satdan o'zini to'g'rilashni boshlaydi.
Bu vaqtda bizning nusxamizdagi so'rov ko'rib chiqildi va qoldirildi. Biz hisobotni oldik. Biznes hali ham baxtli. Ko'rib turganingizdek, bizning belgimiz yana o'sdi va qisqarmaydi. Seanslar bilan grafikda men ushbu uzoq tranzaksiyaning bir qismini nusxadan qoldirdim, shunda vaziyat barqarorlashguncha qancha vaqt ketishini taxmin qilishingiz mumkin.
Seans tugadi. Va faqat bir muncha vaqt o'tgach, server ko'proq yoki kamroq tartibda keladi. Va Master serverdagi so'rovlar uchun o'rtacha javob vaqti normal holatga qaytadi. Chunki, nihoyat, avtovakuum bu o'lik chiziqlarni tozalash va belgilash imkoniyatiga ega. Va u o'z ishini qila boshladi. Va u buni qanchalik tez qilsa, biz tezda tartibga kelamiz.
Hisob balanslarini yangilaydigan sinovdan o'tgan planshetga ko'ra, biz aynan bir xil rasmni ko'ramiz. Hisobni yangilashning o'rtacha vaqti ham asta-sekin normallashmoqda. Protsessor tomonidan iste'mol qilinadigan resurslar ham kamayadi. Va soniyada tranzaktsiyalar soni normal holatga qaytadi. Ammo biz yana normal holatga qaytdik, avariyadan oldingidek emas.
Qanday bo'lmasin, biz birinchi holatda bo'lgani kabi, bir yarim-ikki baravar, ba'zan esa ko'proq samaradorlikni olamiz.
Biz hamma narsani to'g'ri qilganga o'xshaymiz. Yukni taqsimlang. Uskunalar ishlamayapti. Biz so'rovlarni fikrimizga ko'ra taqsimladik, ammo baribir hammasi yomon chiqdi.
- hot_standby_feedback yoqilmaydimi? Ha, ayniqsa kuchli sabablarsiz uni yoqish tavsiya etilmaydi. Chunki bu burilish to'g'ridan-to'g'ri Master serverga ta'sir qiladi va u erda avtovakuumning ishlashini to'xtatadi. Uni ba'zi bir nusxada yoqish va bu haqda unutish orqali siz Masterni o'ldirishingiz va ilova bilan katta muammolarga duch kelishingiz mumkin.
- Maksimal kutish rejimida_streaming_kechikish ko'paytirilsinmi? Ha, xabarlar uchun bu haqiqat. Agar sizda uch soatlik hisobot mavjud bo'lsa va siz replikatsiya mojarolari tufayli uning ishdan chiqishini istamasangiz, shunchaki kechikishni oshiring. Uzoq muddatli hisobot hech qachon ma'lumotlar bazasiga hozir kelgan ma'lumotlarni talab qilmaydi. Agar sizda uch soat bo'lsa, siz uni eski ma'lumotlar davri uchun ishlatasiz. Va siz uchun, uch soatlik kechikish yoki olti soatlik kechikish hech qanday farq qilmaydi, lekin siz doimiy ravishda hisobotlarni olasiz va ularning tushishi bilan hech qanday muammo bo'lmaydi.
- Tabiiyki, replikalarda uzoq seanslarni nazorat qilishingiz kerak, ayniqsa replikada hot_standby_feedback-ni yoqishga qaror qilsangiz. Chunki hamma narsa sodir bo'lishi mumkin. Biz ushbu nusxani ishlab chiquvchiga so'rovlarni sinab ko'rishi uchun berdik. U aqldan ozgan so'rov yozdi. U uni ishga tushirdi va choy ichish uchun ketdi va biz o'rnatilgan ustani oldik. Yoki u yerga noto'g'ri dastur qo'ygan bo'lishimiz mumkin. Vaziyatlar har xil. Replikalardagi mashg'ulotlar Masterdagi kabi diqqat bilan kuzatilishi kerak.
- Va agar sizda replikalar bo'yicha tez va uzoq so'rovlar bo'lsa, unda bu holda yukni taqsimlash uchun ularni bo'lish yaxshiroqdir. Bu streaming_delay havolasi. Tezkorlar uchun kichik replikatsiya kechikishi bilan bitta nusxaga ega bo'ling. Uzoq muddatli hisobot so'rovlari uchun 6 soat yoki bir kunga kechikishi mumkin bo'lgan nusxaga ega bo'ling. Bu mutlaqo normal holat.
Biz oqibatlarni xuddi shu tarzda yo'q qilamiz:
- Biz shishgan stollarni topamiz.
- Va biz uni o'zimizga mos keladigan eng qulay vosita bilan siqamiz.
Ikkinchi hikoya shu erda tugaydi. Keling, uchinchi hikoyaga o'tamiz.
Migratsiya bilan shug'ullanadigan biz uchun ham juda keng tarqalgan.
- Har qanday dasturiy mahsulot o'sib bormoqda. Unga qo'yiladigan talablar o'zgarmoqda. Har holda biz rivojlanishni xohlaymiz. Va shunday bo'ladiki, biz jadvaldagi ma'lumotlarni yangilashimiz kerak, ya'ni rivojlanishimizning bir qismi sifatida joriy etayotgan yangi funksiya uchun migratsiyamiz nuqtai nazaridan yangilashni ishga tushirishimiz kerak.
- Eski ma'lumotlar formati qoniqarli emas. Aytaylik, biz ikkinchi jadvalga murojaat qilamiz, u erda menda ushbu hisobvaraqlar bo'yicha operatsiyalar mavjud. Aytaylik, ular rublda edi va biz aniqlikni oshirishga qaror qildik va buni kopeklarda qilamiz. Va buning uchun biz yangilashni amalga oshirishimiz kerak: tranzaktsiya miqdori bilan maydonni yuzga ko'paytiring.
- Zamonaviy dunyoda biz ma'lumotlar bazasi versiyasini boshqarishning avtomatlashtirilgan vositalaridan foydalanamiz. Aytaylik . Migratsiyamizni u yerda roβyxatdan oβtkazamiz. Biz uni sinov bazamizda sinab ko'ramiz. Hammasi ajoyib. Yangilanish davom etmoqda. U bir muncha vaqt ishni bloklaydi, lekin biz yangilangan ma'lumotlarni olamiz. Va biz bu borada yangi funksiyalarni ishga tushirishimiz mumkin. Hammasi tekshirildi va tekshirildi. Hammasi tasdiqlandi.
- Biz rejalashtirilgan ishlarni amalga oshirdik va migratsiyani amalga oshirdik.
Mana sizning oldingizda taqdim etilgan yangilanish bilan migratsiya. Bu mening hisobimdagi operatsiyalarim bo'lganligi sababli, plastinka 15 GB edi. Va biz har bir satrni yangilaganimiz sababli, yangilanish bilan jadval hajmini ikki baravar oshirdik, chunki biz har bir satrni qayta yozdik.
Migratsiya paytida biz ushbu plastinka bilan hech narsa qila olmadik, chunki unga bo'lgan barcha so'rovlar navbatga qo'yilgan va bu yangilanish tugaguncha kutilgan. Ammo bu erda men sizning e'tiboringizni vertikal o'qda joylashgan raqamlarga qaratmoqchiman. Ya'ni, bizda taxminan 5 millisekundlik migratsiya va protsessor yuklanishidan oldin o'rtacha so'rov vaqti bor, disk xotirasini o'qish uchun blok operatsiyalari soni 7,5 dan kam.
Biz migratsiyani amalga oshirdik va yana muammolarga duch keldik.
Migratsiya muvaffaqiyatli bo'ldi, lekin:
- Eski funksiyani bajarish uchun endi ko'proq vaqt kerak bo'ladi.
- Stol yana kattalashdi.
- Serverdagi yuk yana avvalgidan ko'proq bo'ldi.
- Va, albatta, biz hali ham yaxshi ishlagan funksionallik bilan shug'ullanmoqdamiz, biz uni biroz yaxshiladik.
Va bu yana shishiradi, bu bizning hayotimizni yana buzadi.
Bu erda men jadval, avvalgi ikkita holat kabi, avvalgi o'lchamlariga qaytmasligini ko'rsataman. O'rtacha server yuki etarli ko'rinadi.
Va agar biz hisoblar bilan jadvalga murojaat qilsak, ushbu jadval uchun o'rtacha so'rov vaqti ikki baravar ko'payganini ko'ramiz. Protsessordagi yuk va xotirada tartiblangan qatorlar soni 7,5 dan oshdi, ammo pastroq edi. Va protsessorlar holatida 2 marta, blok operatsiyalarida 1,5 marta sakrab chiqdi, ya'ni biz serverning ishlashida degradatsiyaga duch keldik. Va natijada - bizning dasturimiz ishlashining yomonlashishi. Shu bilan birga, qo'ng'iroqlar soni taxminan bir xil darajada qoldi.
Va bu erda asosiy narsa, bunday migratsiyalarni qanday qilib to'g'ri bajarish kerakligini tushunishdir. Va ularni bajarish kerak. Biz bu migratsiyalarni juda izchil bajaramiz.
- Bunday katta migratsiya o'z-o'zidan sodir bo'lmaydi. Ular doimo nazorat ostida bo'lishi kerak.
- Bilimli shaxs tomonidan nazorat talab qilinadi. Agar sizning jamoangizda DBA bo'lsa, DBA buni qilsin. Bu uning ishi. Agar yo'q bo'lsa, unda ma'lumotlar bazalari bilan ishlashni biladigan eng tajribali odam qilsin.
- Yangi ma'lumotlar bazasi sxemasi, hatto bitta ustunni yangilagan bo'lsak ham, biz har doim bosqichma-bosqich, ya'ni dasturning yangi versiyasi chiqarilishidan oldin tayyorlanamiz:
- Biz yangilangan ma'lumotlarni yozib oladigan yangi maydonlar qo'shildi.
- Biz ma'lumotlarni eski maydondan yangi maydonga kichik qismlarga o'tkazamiz. Nega buni qilyapmiz? Birinchidan, biz doimo ushbu jarayonni nazorat qilamiz. Bilamizki, biz juda ko'p partiyalarni o'tkazdik va bizda juda ko'p qoldi.
- Va ikkinchi ijobiy ta'sir shundaki, har bir bunday partiya o'rtasida biz tranzaktsiyani yopamiz, yangisini ochamiz va bu avtovakuumning plastinkaga muvofiq ishlashiga, qayta foydalanish uchun o'lik chiziqlarni belgilashga imkon beradi.
- Ilova ishlayotganda paydo bo'ladigan satrlar uchun (bizda hali ham eski dastur ishlayapti), biz yangi maydonlarga yangi qiymatlarni yozadigan trigger qo'shamiz. Bizning holatda, bu eski qiymatdan yuzga ko'paytirish.
- Agar biz butunlay o'jar bo'lsak va bir xil maydonni xohlasak, barcha migratsiyalarni tugatgandan so'ng va dasturning yangi versiyasini chiqarishdan oldin, biz shunchaki maydonlarni qayta nomlaymiz. Qadimgilarga ixtiro qilingan nomlar beriladi va yangi maydonlar eskilariga o'zgartiriladi.
- Va shundan keyingina biz dasturning yangi versiyasini ishga tushiramiz.
Va shu bilan birga, biz shishib ketmaymiz va ishlash nuqtai nazaridan azoblanmaymiz.
Bu erda uchinchi hikoya tugaydi.
Va endi men birinchi hikoyada aytib o'tgan vositalar haqida bir oz ko'proq ma'lumot.
Bloatni qidirishdan oldin kengaytmani o'rnatishingiz kerak .
So'rovlar bilan chiqmaslik uchun biz bu so'rovlarni allaqachon ishimizda yozganmiz. Siz ulardan foydalanishingiz mumkin. Bu erda ikkita so'rov bor.
- Birinchisi ishlash uchun juda ko'p vaqt talab etadi, ammo u sizga jadvaldagi aniq ko'rsatkichlarni ko'rsatadi.
- Jadvalga ko'ra shishiradi yoki yo'qligini tezda baholash kerak bo'lganda, ikkinchisi tezroq ishlaydi va juda samarali. Shuningdek, shishish har doim Postgres jadvalida mavjudligini tushunishingiz kerak. Bu uning MVCC modelining xususiyati.
- Va ko'p hollarda jadvallar uchun 20% shishiradi. Ya'ni, siz tashvishlanmasligingiz va bu jadvalni siqishingiz kerak.
Biz foydasiz ma'lumotlar bilan shishgan jadvallarni qanday aniqlashni aniqladik.
Endi shishishni qanday tuzatish haqida:
- Agar bizda kichik planshet va yaxshi disklar bo'lsa, ya'ni gigabaytgacha bo'lgan planshetda VACUUM FULL-dan foydalanish juda mumkin. U bir necha soniya davomida stolda sizdan eksklyuziv qulfni oladi va yaxshi, lekin u hamma narsani tez va qattiq qiladi. VACUUM FULL nima qiladi? U stolda eksklyuziv qulfni oladi va eski jadvallardan jonli qatorlarni yangi jadvalga qayta yozadi. Va oxirida u ularni almashtiradi. U eski fayllarni o'chiradi va eskilarini yangilari bilan almashtiradi. Ammo uning ishlashi davomida u stolda eksklyuziv qulfni oladi. Bu shuni anglatadiki, siz ushbu jadval bilan hech narsa qila olmaysiz: unga yozmang, o'qimang va uni o'zgartirmang. Va VACUUM FULL ma'lumotlarni yozish uchun qo'shimcha disk maydoni talab qiladi.
- Keyingi vosita . O'z printsipi bo'yicha u VACUUM FULL ga juda o'xshaydi, chunki u eski fayllardan ma'lumotlarni yangilariga qayta yozadi va ularni jadvalda almashtiradi. Ammo shu bilan birga, u ishining boshida stolda eksklyuziv qulfni olmaydi, balki fayllarni almashtirish uchun allaqachon tayyor ma'lumotlarga ega bo'lgan paytda uni oladi. Uning disk resurslari talablari VACUUM FULL talablariga o'xshaydi. Sizga qo'shimcha disk maydoni kerak va agar sizda terabayt jadvallar mavjud bo'lsa, bu ba'zan juda muhim. Va u juda protsessorga och, chunki u I/U bilan faol ishlaydi.
- Uchinchi yordamchi dastur . Resurslar bilan ko'proq ehtiyot bo'ladi, chunki u bir oz boshqacha printsiplarga muvofiq ishlaydi. pgcompacttable-ning asosiy g'oyasi shundaki, u jadvaldagi yangilanishlar yordamida barcha jonli qatorlarni jadvalning boshiga ko'chiradi. Va keyin bu stolda vakuum ishlaydi, chunki biz boshida jonli qatorlar va oxirida o'lik qatorlar borligini bilamiz. Va vakuumning o'zi bu quyruqni kesib tashlaydi, ya'ni u juda ko'p qo'shimcha disk maydoni talab qilmaydi. Va shu bilan birga, u hali ham resurslar nuqtai nazaridan siqilishi mumkin.
Hamma narsa asboblar bilan.
Agar siz shishgan mavzuni yanada chuqurroq o'rganish nuqtai nazaridan qiziqarli deb topsangiz, bu erda bir nechta foydali havolalar mavjud:
- - Bu mening hamkasbimning hisoboti. Bu Postgresning ishi va hayoti davomida qayerga borishi haqida umumiydir. Va ma'lumotlar bazasi ma'murlari uchun bloat haqida juda katta va batafsil texnik qism mavjud.
- - bu bizning omborimizga havola bo'lib, u erda biz ma'lumotlar bazasi holatini tekshirish uchun bir qancha foydali skriptlarni saqlaymiz. U erda siz bloatni qidirish uchun skriptlarni topishingiz mumkin.
- ΠΈ belgilarni qisqartirishga yordam beradigan vositalarga havolalar.
- - bu mening hamkasbimning posti. U erda u juda jiddiy va texnik jihatdan ma'murlarga yaqin darajada shishishni batafsil tahlil qiladi.
Men ishlab chiquvchilar uchun dahshatli voqeani ko'rsatishga ko'proq harakat qildim, chunki ular bizning ma'lumotlar bazalarining bevosita mijozlari va nima va nimaga olib kelishini tushunishlari kerak. Umid qilamanki, men muvaffaqiyatga erishdim. E'tiboringiz uchun rahmat!
Sizning savollaringiz
Hisobot uchun rahmat! Siz muammolarni qanday aniqlashingiz mumkinligi haqida gapirdingiz. Ularni qanday ogohlantirish mumkin? Ya'ni, menda so'rovlar nafaqat ba'zi tashqi xizmatlarga kirganligi sababli osib qo'yilgan vaziyat bor edi. Bu faqat bir nechta yovvoyi qo'shilishlar edi. Ba'zi mayda, zararsiz iltimoslar bor edi, ular bir kun davomida osilib, keyin qandaydir bema'ni narsalarni qila boshladilar. Ya'ni, siz tasvirlagan narsaga juda o'xshash. Buni qanday kuzatish mumkin? O'tiring va doimiy ravishda qaysi so'rov tiqilib qolganligini kuzatib boring? Buni qanday qilib oldini olish mumkin?
Bunday holda, bu DBA uchun emas, balki kompaniyangiz ma'murlari uchun vazifadir.
Men administratorman.
PostgreSQL pg_stat_activity deb nomlangan ko'rinishga ega bo'lib, u osilgan so'rovlarni ko'rsatadi. Va u erda qancha vaqt osilganligini ko'rishingiz mumkin.
Har 5 daqiqada kirib, qarashim kerakmi?
Cronni o'rnating va tekshiring. Agar sizda uzoq muddatli so'rov bo'lsa, xat yozing va shu bilan. Ya'ni, sizning ko'zingiz bilan qarashga hojat yo'q, u avtomatlashtirilishi mumkin. Siz xat olasiz, unga munosabat bildirasiz. Yoki siz avtomatik ravishda suratga olishingiz mumkin.
Bu sodir bo'lishining aniq sabablari bormi?
Men ba'zilarini sanab o'tdim. Boshqa murakkabroq misollar. Va uzoq vaqt davomida suhbat bo'lishi mumkin.
Hisobot uchun rahmat! Men pg_repack yordam dasturi haqida aniqlik kiritmoqchi edim. Agar u eksklyuziv qulfni qilmasa, unda ...
U eksklyuziv qulflaydi.
... keyin men ma'lumotlarni yo'qotishim mumkin. Mening arizam shu vaqt ichida hech narsa yozmasligi kerakmi?
Yo'q, u jadval bilan muammosiz ishlaydi, ya'ni pg_repack avval mavjud bo'lgan barcha jonli chiziqlarni uzatadi. Tabiiyki, u erda jadvalga qandaydir kirish sodir bo'ladi. U shunchaki bu ot dumini tashqariga tashlamoqda.
Ya'ni, u oxir-oqibat buni qiladimi?
Oxir-oqibat, u ushbu fayllarni almashtirish uchun eksklyuziv qulfni oladi.
U VACUUM FULLdan tezroq bo'ladimi?
VACUUM FULL, ishga tushishi bilan darhol eksklyuziv qulfni oldi. Va u hamma narsani qilmaguncha, u uni qo'yib yubormaydi. Va pg_repack faqat faylni almashtirish vaqtida eksklyuziv qulfni oladi. Ayni paytda siz u erda yozmaysiz, lekin ma'lumotlar yo'qolmaydi, hamma narsa yaxshi bo'ladi.
Salom! Siz avtomobil changyutgichining ishlashi haqida gapirdingiz. Qizil, sariq va yashil ro'yxatga olish kataklari bo'lgan grafik mavjud edi. Ya'ni, sariq ranglar - ularni o'chirilgan deb belgiladi. Va natijada ularga yangi narsa yozilishi mumkinmi?
Ha. Postgres qatorlarni o'chirmaydi. U shunday o'ziga xos xususiyatga ega. Agar biz chiziqni yangilagan bo'lsak, eskisini o'chirilgan deb belgiladik. Bu qatorni o'zgartirgan tranzaksiya identifikatori o'sha erda paydo bo'ladi va biz yangi qatorni yozamiz. Va bizda ularni o'qishi mumkin bo'lgan sessiyalar mavjud. Bir nuqtada ular ancha qariydi. Va avtovakuumning qanday ishlashining mohiyati shundaki, u bu chiziqlardan o'tib, ularni keraksiz deb belgilaydi. Va u erda ma'lumotlarni qayta yozishingiz mumkin.
Tushundim. Lekin bu savolga tegishli emas. Men tugatmadim. Aytaylik, bizda stol bor. Unda o'zgaruvchan o'lchamdagi maydonlar mavjud. Va agar men yangi narsalarni qo'shishga harakat qilsam, u eski hujayraga mos kelmasligi mumkin.
Yo'q, har qanday holatda ham butun chiziq u erda yangilanadi. Postgres ikkita ma'lumotlarni saqlash modeliga ega. U ma'lumotlar turidan tanlaydi. Jadvalda to'g'ridan-to'g'ri saqlanadigan ma'lumotlar mavjud va tos ma'lumotlari ham mavjud. Bular katta hajmdagi ma'lumotlar: matn, json. Ular alohida plastinalarda saqlanadi. Va bu planshetlarga ko'ra, shishganlik bilan bir xil hikoya sodir bo'ladi, ya'ni hamma narsa bir xil. Ular faqat alohida sanab o'tilgan.
Hisobot uchun rahmat! Davomiylikni cheklash uchun bayonot kutish vaqti so'rovlaridan foydalanish maqbulmi?
Juda maqbul. Biz buni hamma joyda ishlatamiz. Va bizda o'z xizmatlarimiz yo'qligi sababli, biz masofaviy yordam ko'rsatamiz, mijozlarimiz juda xilma-xildir. Va hamma bundan to'liq mamnun. Ya'ni, bizda tekshiradigan cron ishlari bor. Mashg'ulotlarning davomiyligi mijoz bilan oddiygina kelishib olinadi, bundan oldin biz rozi emasmiz. Bu bir daqiqa, 10 daqiqa bo'lishi mumkin. Bu taglikdagi yukga va uning maqsadiga bog'liq. Lekin hammamiz pg_stat_activity dan foydalanamiz.
Hisobot uchun rahmat! Sizning hisobotingizni ilovalarimga qo'llashga harakat qilaman. Va biz hamma joyda tranzaktsiyani boshlayotganga o'xshaymiz va uni hamma joyda aniq yakunlaymiz. Agar biron bir istisno mavjud bo'lsa, orqaga qaytish hali ham sodir bo'ladi. Va keyin men o'ylay boshladim. Axir, tranzaktsiya aniq boshlanmasligi mumkin. Bu, ehtimol, qizga ishoradir. Agar men shunchaki yozuvni yangilasam, tranzaktsiya PostgreSQL-da boshlanadi va faqat ulanish uzilganida tugaydimi?
Agar siz hozir dastur darajasi haqida gapirayotgan bo'lsangiz, bu siz foydalanayotgan drayverga, foydalanilayotgan ORMga bog'liq. U erda juda ko'p sozlamalar mavjud. Agar sizda avtomatik sozlama yoqilgan boΚ»lsa, tranzaksiya shu yerda boshlanadi va darhol yopiladi.
Ya'ni, yangilanishdan so'ng darhol yopiladimi?
Bu sozlamalarga bog'liq. Men bitta sozlamani nomladim. Bu avtomatik majburiyat yoqilgan. Bu juda keng tarqalgan. Agar u yoqilgan bo'lsa, tranzaksiya ochilgan va yopilgan. Agar siz "tranzaksiyani boshlash" va "tranzaksiyani tugatish" deb aniq aytmasangiz, lekin seansga so'rov yuborgan bo'lsangiz.
Salom! Hisobot uchun rahmat! Tasavvur qilaylik, bizda shishgan va shishgan ma'lumotlar bazasi bor va keyin serverdagi bo'sh joy tugaydi. Ushbu vaziyatni tuzatish uchun vositalar bormi?
Serverdagi bo'sh joyni to'g'ri kuzatish kerak.
Masalan, DBA choyga bordi, kurortda edi va hokazo.
Fayl tizimi yaratilganda, ma'lumotlar yozilmagan joyda hech bo'lmaganda qandaydir zaxira maydoni yaratiladi.
Agar u butunlay noldan past bo'lsa-chi?
U erda u ajratilgan joy deb ataladi, ya'ni uni bo'shatish mumkin va u qanchalik katta bo'lganiga qarab, siz bo'sh joy olasiz. Odatiy bo'lib, ular qancha ekanligini bilmayman. Va boshqa holatda, rekonstruktiv operatsiyani bajarish uchun joy bo'lishi uchun disklarni etkazib bering. Sizga kerak bo'lmasligi kafolatlangan ba'zi jadvallarni o'chirishingiz mumkin.
Boshqa vositalar bormi?
U har doim qo'lda ishlangan. Va mahalliy sharoitda u erda nima qilish yaxshiroq ekanligi aniq bo'ladi, chunki ba'zi ma'lumotlar muhim, ba'zilari esa tanqidiy emas. Va har bir ma'lumotlar bazasi va u bilan ishlaydigan dastur uchun bu biznesga bog'liq. Bu har doim mahalliy darajada hal qilinadi.
Hisobot uchun rahmat! Menda ikkita savol bor. Birinchidan, siz tranzaktsiyalar to'xtab qolsa, jadval maydoni hajmi ham, indeks hajmi ham o'sishini ko'rsatadigan slaydlarni ko'rsatdingiz. Bundan tashqari, hisobotda planshetni qadoqlaydigan bir qator yordamchi dasturlar mavjud edi. Indeks haqida nima deyish mumkin?
Ularni ham qadoqlashadi.
Ammo vakuum indeksga ta'sir qilmaydi?
Ba'zilar indeks bilan ishlaydi. Masalan, pg_rapack, pgcompacttable. Vakuum indekslarni qayta yaratadi va ularga ta'sir qiladi. VACUUM FULL bilan g'oya hamma narsani ustiga yozishdir, ya'ni u hamma bilan ishlaydi.
Va ikkinchi savol. Nega replikatsiyalar haqidagi hisobotlar replikatsiyaning o'ziga bog'liqligini tushunmayapman. Menimcha, hisobotlar o'qiladi va replikatsiya yoziladi.
Replikatsiya ziddiyatiga nima sabab bo'ladi? Bizda jarayonlar sodir bo'ladigan Ustamiz bor. Bizda mashinani changyutkichdan tozalash ishlari olib borilmoqda. Avtovakuum aslida nima qiladi? U eski chiziqlarni kesib tashlamoqda. Agar bizda ushbu eski satrlarni o'qiydigan replika bo'yicha so'rov bo'lsa va Masterda avtovakuum ushbu satrlarni qayta yozish uchun iloji boricha belgilab qo'ygan vaziyat yuzaga kelgan bo'lsa, biz ularni qayta yozdik. Va biz ma'lumotlar paketini oldik, so'rov replikada kerak bo'lgan satrlarni qayta yozishimiz kerak bo'lganda, replikatsiya jarayoni siz sozlagan vaqt tugashini kutadi. Va keyin PostgreSQL u uchun nima muhimroq ekanligini hal qiladi. Va replikatsiya uning uchun so'rovdan ko'ra muhimroqdir va u replikada ushbu o'zgarishlarni amalga oshirish uchun so'rovni o'qqa tutadi.
Andrey, menda savol bor. Taqdimot paytida siz ko'rsatgan bu ajoyib grafikalar, bu sizning qandaydir foydali ishingizning natijasimi? Grafiklar qanday yaratilgan?
Bu xizmat .
Bu tijorat mahsulotmi?
Ha. Bu tijorat mahsulotidir.
Manba: www.habr.com