kirish
Bir muncha vaqt oldin menga muvaffaqiyatsiz klasterni ishlab chiqish vazifasi berildi , bitta shahar ichida optik tola bilan ulangan bir nechta ma'lumot markazlarida ishlaydi va bitta ma'lumot markazining ishdan chiqishiga (masalan, o'chirilishiga) bardosh bera oladi. Xatolarga chidamlilik uchun mas'ul bo'lgan dasturiy ta'minot sifatida men tanladim chunki bu RedHat kompaniyasining uzilish klasterlarini yaratish uchun rasmiy yechimidir. Bu yaxshi, chunki RedHat uni qo'llab-quvvatlaydi va bu yechim universal (modulli). Uning yordami bilan nafaqat PostgreSQL, balki standart modullardan foydalangan holda yoki ularni muayyan ehtiyojlar uchun yaratishda boshqa xizmatlarning xatolarga chidamliligini ta'minlash mumkin bo'ladi.
Ushbu qaror o'rinli savolni tug'dirdi: nosozliklar klasteri xatoga qanchalik chidamli bo'ladi? Buni tekshirish uchun men klaster tugunlaridagi turli nosozliklarni taqlid qiluvchi, xizmatning tiklanishini kutadigan, muvaffaqiyatsiz tugunni tiklaydigan va sinovni tsiklda davom ettiradigan sinov dastgohini ishlab chiqdim. Bu loyiha dastlab hapgsql deb nomlangan edi, lekin vaqt o'tishi bilan men faqat bitta unli bo'lgan nomdan zerikdim. Shuning uchun men xatolarga chidamli ma'lumotlar bazalarini chaqira boshladim (va ularga ishora qiluvchi suzuvchi IP) krogan (barcha muhim organlar takrorlanadigan kompyuter o'yinining qahramoni) va tugunlar, klasterlar va loyihaning o'zi tuchanka (kroganlar yashaydigan sayyora).
Endi rahbariyat ruxsat berdi . README tez orada ingliz tiliga tarjima qilinadi (chunki asosiy iste'molchilar yurak stimulyatori va PostgreSQL dasturchilari bo'lishi kutilmoqda) va men README ning eski ruscha versiyasini (qisman) ushbu maqola shaklida taqdim etishga qaror qildim.
Klasterlar virtual mashinalarda o'rnatiladi . Jami 12 ta virtual mashina (jami 36GiB) joylashtiriladi, ular 4 ta nosozliklarga chidamli klasterlarni (turli xil variantlar) tashkil qiladi. Birinchi ikkita klaster turli ma'lumotlar markazlarida joylashgan ikkita PostgreSQL serveridan va umumiy serverdan iborat. Guvoh c kvorum qurilmasi (uchinchi ma'lumotlar markazida arzon virtual mashinada joylashtirilgan), bu noaniqlikni hal qiladi 50% / 50%, ovozingizni partiyalardan biriga berish. Uchta ma'lumot markazlarida uchinchi klaster: bitta master, ikkita qul, yo'q kvorum qurilmasi. To'rtinchi klaster to'rtta PostgreSQL serveridan iborat bo'lib, har bir ma'lumot markaziga ikkitasi: bitta master, qolganlari replika, shuningdek, foydalanadi. Guvoh c kvorum qurilmasi. To'rtinchisi ikkita server yoki bitta ma'lumot markazining ishdan chiqishiga dosh bera oladi. Agar kerak bo'lsa, ushbu yechimni ko'proq nusxalar soniga o'tkazish mumkin.
Aniq vaqt xizmati xatolarga chidamlilik uchun ham qayta konfiguratsiya qilingan, lekin u usulning o'zidan foydalanadi ntpd (etim rejimi). Umumiy server Guvoh markaziy NTP serveri vazifasini bajaradi va o'z vaqtini barcha klasterlarga taqsimlaydi va shu bilan barcha serverlarni bir-biri bilan sinxronlashtiradi. Agar Guvoh ishlamay qolsa yoki izolyatsiya qilingan bo'lsa, klaster serverlaridan biri (klaster ichida) o'z vaqtini taqsimlay boshlaydi. Yordamchi keshlash HTTP proksi-server ga ham ko'tarilgan Guvoh, uning yordami bilan boshqa virtual mashinalar Yum omborlariga kirish huquqiga ega. Haqiqatda, aniq vaqt va proksi-serverlar kabi xizmatlar, ehtimol, ajratilgan serverlarda joylashtiriladi, lekin ular stendda joylashgan. Guvoh faqat virtual mashinalar sonini va bo'sh joyni tejash uchun.
Versiyalar
v0. VirtualBox 7 da CentOS 11 va PostgreSQL 6.1 bilan ishlaydi.
Klaster tuzilishi
Barcha klasterlar bir nechta ma'lumotlar markazlarida joylashgan bo'lib, bitta tekis tarmoqqa birlashtirilgan va bitta ma'lumot markazining ishdan chiqishi yoki tarmoq izolyatsiyasiga bardosh berishi kerak. Shunung uchun mumkin emas qarshi himoya qilish uchun foydalaning bo'lingan miya standart yurak stimulyatori texnologiyasi chaqirdi STONIT (Boshdagi boshqa tugunni otib tashlang) yoki fextavonie. Uning mohiyati: agar klasterdagi tugunlar biron bir tugunda biror narsa noto'g'ri ekanligiga shubha qila boshlasa, u javob bermayapti yoki noto'g'ri ishlasa, ular "tashqi" qurilmalar, masalan, IPMI yoki UPS boshqaruv kartasi orqali uni majburan o'chirib qo'yishadi. . Ammo bu faqat bitta nosozlik bo'lsa, IPMI yoki UPS serveri ishlashda davom etgan hollarda ishlaydi. Bu erda biz butun ma'lumotlar markazi ishlamay qolganda (masalan, quvvatni yo'qotganda) yanada halokatli nosozlikdan himoya qilishni rejalashtirmoqdamiz. Va bunday rad etish bilan hamma narsa toshbo'ron-qurilmalar (IPMI, UPS va boshqalar) ham ishlamaydi.
Buning o'rniga, tizim kvorum g'oyasiga asoslanadi. Barcha tugunlar ovozga ega va faqat barcha tugunlarning yarmidan ko'pini ko'ra oladiganlar ishlashi mumkin. Bu "yarim + 1" miqdori deyiladi kvorum. Agar kvorumga erishilmasa, u holda tugun tarmoq izolyatsiyasida ekanligiga qaror qiladi va o'z resurslarini o'chirib qo'yishi kerak, ya'ni. bu nima split-miya himoyasi. Agar ushbu xatti-harakat uchun javobgar bo'lgan dasturiy ta'minot ishlamasa, masalan, IPMI-ga asoslangan qo'riqchi, ishlashi kerak bo'ladi.
Agar tugunlar soni juft bo'lsa (ikkita ma'lumot markazidagi klaster), unda noaniqlik paydo bo'lishi mumkin. 50% / 50% (ellik ellik) tarmoq izolyatsiyasi klasterni yarmiga bo'lganda. Shuning uchun, juft sonli tugunlar uchun biz qo'shamiz kvorum qurilmasi uchinchi ma'lumotlar markazida eng arzon virtual mashinada ishga tushirilishi mumkin bo'lgan oddiy demon. U o'z ovozini (u ko'rgan) segmentlardan biriga beradi va shu bilan 50%/50% noaniqlikni hal qiladi. Men kvorum qurilmasi ishga tushiriladigan serverni nomladim Guvoh (repmgr terminologiyasi, menga yoqdi).
Resurslarni bir joydan ikkinchi joyga ko'chirish mumkin, masalan, noto'g'ri serverlardan sog'lom serverlarga yoki tizim ma'murlari buyrug'i bilan. Mijozlar o'zlariga kerakli resurslar qayerda joylashganligini bilishlari uchun (qaerga ulanish kerak?), suzuvchi IP (float IP). Bular yurak stimulyatori tugunlar bo'ylab harakatlanishi mumkin bo'lgan IP-lardir (hamma narsa tekis tarmoqda). Ularning har biri resursni (xizmatni) ramziy qiladi va ushbu xizmatga kirish uchun ulanishingiz kerak bo'lgan joyda joylashgan bo'ladi (bizning holimizda ma'lumotlar bazasi).
Tuchanka1 (siqilishli sxema)
tuzilma
G'oya shundan iborat ediki, bizda kam yuklangan ko'plab kichik ma'lumotlar bazalari bor, ular uchun faqat o'qiladigan tranzaktsiyalar uchun issiq kutish rejimida ajratilgan qul serverni saqlash foydasizdir (resurslarni bunday isrof qilishning hojati yo'q).
Har bir ma'lumot markazida bitta server mavjud. Har bir serverda ikkita PostgreSQL nusxasi mavjud (PostgreSQL terminologiyasida ular klasterlar deb ataladi, ammo chalkashmaslik uchun men ularni misollar deb atayman (boshqa ma'lumotlar bazalariga o'xshash) va men faqat yurak stimulyatori klasterlarini klaster deb atayman). Bitta nusxa asosiy rejimda ishlaydi va faqat u xizmatlarni taqdim etadi (faqat float IP unga olib keladi). Ikkinchi nusxa ikkinchi ma'lumotlar markazi uchun qul sifatida ishlaydi va faqat uning ustasi ishlamay qolganda xizmatlarni taqdim etadi. Ko'pincha ikkitadan bittasi (magistr) xizmatlarni taqdim etishi (so'rovlarni bajarish) uchun barcha server resurslari master uchun optimallashtirilgan (xotira shared_buffers keshi va boshqalar uchun ajratilgan), lekin ikkinchi nusxasi shunday qilib. shuningdek, ma'lumotlar markazlaridan biri ishlamay qolganda etarli resurslarga ega (fayl tizimining keshi orqali suboptimal ishlash uchun bo'lsa ham). Qul klasterning normal ishlashi vaqtida xizmatlar ko'rsatmaydi (faqat o'qish uchun so'rovlarni bajarmaydi), shunda bitta mashinada usta bilan resurslar uchun urush bo'lmaydi.
Ikki tugun bo'lsa, noto'g'ri bardoshlik faqat asinxron replikatsiya bilan mumkin, chunki sinxron replikatsiya bilan qulning ishlamay qolishi masterning to'xtashiga olib keladi.
Guvohlik qilmaslik
Guvohlik qilmaslik (kvorum qurilmasi) Men faqat Tuchanka1 klasterini ko'rib chiqaman, qolganlari bilan bir xil hikoya bo'ladi. Agar guvoh muvaffaqiyatsiz bo'lsa, klaster tuzilmasida hech narsa o'zgarmaydi, hamma narsa xuddi shunday ishlashda davom etadi. Ammo kvorum 2 tadan 3 taga aylanadi va shuning uchun har qanday keyingi muvaffaqiyatsizlik klaster uchun halokatli bo'ladi. Hali ham zudlik bilan tuzatish kerak bo'ladi.
Tuchanka1 rad etish
Tuchanka1 uchun ma'lumotlar markazlaridan birining ishlamay qolishi. Ushbu holatda Guvoh ikkinchi ma'lumotlar markazidagi ikkinchi tugunga ovoz beradi. U erda sobiq qul ustaga aylanadi, natijada ikkala master bir xil serverda ishlaydi va ikkala suzuvchi IP-lari ham ularga ishora qiladi.
Tuchanka2 (klassik)
tuzilma
Ikki tugunning klassik sxemasi. Xo'jayin birida, qul ikkinchisida ishlaydi. Ikkalasi ham so'rovlarni bajarishi mumkin (qul faqat o'qiladi), shuning uchun ikkalasi ham float IP orqali ko'rsatiladi: krogan2 - usta, krogan2s1 - tobe. Xo'jayin ham, qul ham xatolarga chidamli bo'ladi.
Ikki tugun bo'lsa, noto'g'ri bardoshlik faqat asinxron replikatsiya bilan mumkin, chunki sinxron replikatsiya bilan qulning ishlamay qolishi masterning to'xtashiga olib keladi.
Tuchanka2 rad etish
Agar ma'lumotlar markazlaridan biri ishlamay qolsa Guvoh ikkinchisiga ovoz beradi. Yagona ishlaydigan ma'lumotlar markazida master ko'tariladi va ikkala suzuvchi IP ham unga ishora qiladi: master va qul. Albatta, namuna shunday tuzilgan bo'lishi kerakki, u bir vaqtning o'zida master va slave float IP-dan barcha ulanishlar va so'rovlarni qabul qilish uchun etarli resurslarga (ulanish chegaralari va boshqalar) ega bo'lishi kerak. Ya'ni, normal ish paytida u etarli miqdorda chegaralarga ega bo'lishi kerak.
Tuchanka4 (ko'p qullar)
tuzilma
Allaqachon yana bir ekstremal. Faqat o'qish uchun juda ko'p so'rovlarni qabul qiladigan ma'lumotlar bazalari mavjud (yuqori yuklangan saytning odatiy holati). Tuchanka4 - bu kabi so'rovlarni bajarish uchun uch yoki undan ortiq qul bo'lishi mumkin bo'lgan vaziyat, lekin hali ham juda ko'p emas. Qullarning juda ko'p soni bilan ierarxik replikatsiya tizimini ixtiro qilish kerak bo'ladi. Minimal holatda (rasmda) ikkita ma'lumot markazining har birida PostgreSQL namunasi bo'lgan ikkita server mavjud.
Ushbu sxemaning yana bir xususiyati shundaki, allaqachon bitta sinxron replikatsiyani tashkil qilish mumkin. U, agar iloji bo'lsa, master bilan bir xil ma'lumotlar markazidagi replikatsiyaga emas, balki boshqa ma'lumotlar markaziga replikatsiya qilish uchun tuzilgan. Usta va har bir tobe suzuvchi IP bilan ishora qilinadi. Yaxshiyamki, qullar o'rtasida qandaydir tarzda so'rovlarni muvozanatlash kerak bo'ladi sql proksi, masalan, mijoz tomonida. Har xil turdagi mijozlar har xil turlarni talab qilishi mumkin sql proksi, va kimga nima kerakligini faqat mijoz ishlab chiquvchilar biladi. Ushbu funktsiya tashqi demon yoki mijoz kutubxonasi (ulanish hovuzi) va boshqalar tomonidan amalga oshirilishi mumkin. Bularning barchasi o'zgarmas ma'lumotlar bazasi klasteri mavzusidan tashqariga chiqadi (failover SQL proksi mijozning xatolariga chidamliligi bilan birgalikda mustaqil ravishda amalga oshirilishi mumkin).
Tuchanka4 rad etish
Agar bitta ma'lumot markazi (ya'ni, ikkita server) ishlamay qolsa, guvoh ikkinchisiga ovoz beradi. Natijada, ikkinchi ma'lumotlar markazida ikkita server ishlamoqda: biri master ishlaydi va master float IP unga ishora qiladi (o'qish-yozish so'rovlarini qabul qilish uchun); ikkinchi serverda esa sinxron replikatsiya bilan ishlaydigan slave mavjud va slave float IP-laridan biri unga ishora qiladi (faqat o'qish uchun so'rovlar uchun).
E'tiborga olish kerak bo'lgan birinchi narsa shundaki, barcha slave float IP-lar ishchi bo'lmaydi, faqat bitta. Va u bilan to'g'ri ishlash uchun bu kerak bo'ladi sql proksi barcha so'rovlarni qolgan yagona float IP ga yo'naltirdi; Agar sql proksi yo'q, u holda ulanish URL manzilida vergul bilan ajratilgan barcha float IP qullarini ro'yxatlashingiz mumkin. Bu holda, bilan libpq ulanish birinchi ishlaydigan IP-ga bo'ladi, bu avtomatik sinov tizimida amalga oshiriladi. Ehtimol, boshqa kutubxonalarda, masalan, JDBC, bu ishlamaydi va kerak sql proksi. Buning sababi, qullar uchun suzuvchi IP-larni bir serverda bir vaqtning o'zida ko'tarish taqiqlanganligi sababli, agar ular bir nechta ishlayotgan bo'lsa, ular tobe serverlar o'rtasida teng taqsimlanadi.
Ikkinchidan: ma'lumotlar markazi ishlamay qolgan taqdirda ham, sinxron replikatsiya saqlanib qoladi. Va agar ikkilamchi nosozlik yuzaga kelsa ham, ya'ni qolgan ma'lumotlar markazidagi ikkita serverdan biri ishlamay qolsa ham, klaster xizmatlarni ko'rsatishni to'xtatsa ham, o'zi bajarilganligini tasdiqlagan barcha tranzaksiyalar haqidagi ma'lumotlarni saqlab qoladi. (ikkilamchi nosozlik bo'lsa, yo'qotish haqida ma'lumot bo'lmaydi).
Tuchanka3 (3 ma'lumot markazi)
tuzilma
Bu uchta to'liq ishlaydigan ma'lumotlar markazi mavjud bo'lgan vaziyat uchun klaster bo'lib, ularning har biri to'liq ishlaydigan ma'lumotlar bazasi serveriga ega. Ushbu holatda kvorum qurilmasi kerak emas. Bir ma'lumot markazida usta, qolgan ikkitasida qullar ishlaydi. Replikatsiya sinxron boβlib, HAR QANDAY (toβgβri1, tobe2) turi, yaβni qullardan birortasi majburiyatni qabul qilganligi haqida birinchi boβlib javob berganida, mijoz majburiyatni tasdiqlashni oladi. Resurslar master uchun bitta float IP va ikkita tobe uchun ko'rsatilgan. Tuchanka4 dan farqli o'laroq, uchta float IP-ning barchasi xatolarga chidamli. Faqat o'qish uchun mo'ljallangan SQL so'rovlarini muvozanatlash uchun siz foydalanishingiz mumkin sql proksi (alohida nosozlikka chidamlilik bilan) yoki bitta tobe float IP-ni mijozlarning yarmiga, ikkinchi yarmini esa ikkinchisiga tayinlang.
Tuchanka3 rad etish
Agar ma'lumotlar markazlaridan biri ishlamay qolsa, ikkitasi qoladi. Ulardan birida master va float IP ko'tariladi, ikkinchisida - tobe va ikkala tobe suzuvchi IP-lar (har ikkala tobe float IP-dan barcha ulanishlarni qabul qilish uchun misolda ikki marta resurslar zaxirasi bo'lishi kerak). Ustalar va qullar o'rtasidagi sinxron replikatsiya. Shuningdek, klaster ikkita ma'lumot markazi yo'q qilingan taqdirda (agar ular bir vaqtning o'zida yo'q qilinmasa) amalga oshirilgan va tasdiqlangan tranzaktsiyalar to'g'risidagi ma'lumotlarni saqlaydi (axborot yo'qolmaydi).
Men fayl tuzilishi va tarqatilishining batafsil tavsifini kiritmaslikka qaror qildim. O'ynamoqchi bo'lgan har bir kishi hammasini README da o'qishi mumkin. Men faqat avtomatlashtirilgan test tavsifini beraman.
Avtomatik sinov tizimi
Turli nosozliklarni simulyatsiya qilish orqali klasterlarning nosozliklarga chidamliligini sinash uchun avtomatik sinov tizimi yaratildi. Skript tomonidan ishga tushirilgan test/failure. Skript siz sinab ko'rmoqchi bo'lgan klasterlar sonini parametr sifatida qabul qilishi mumkin. Masalan, bu buyruq:
test/failure 2 3faqat ikkinchi va uchinchi klasterni sinab ko'radi. Agar parametrlar ko'rsatilmagan bo'lsa, barcha klasterlar sinovdan o'tkaziladi. Barcha klasterlar parallel ravishda sinovdan o'tkaziladi va natija tmux panelida ko'rsatiladi. Tmux maxsus tmux serveridan foydalanadi, shuning uchun skript standart tmux ostida ishga tushirilishi mumkin, natijada ichki tmux paydo bo'ladi. Men terminalni katta oynada va kichik shrift bilan ishlatishni tavsiya qilaman. Sinov boshlanishidan oldin, barcha virtual mashinalar skript tugashi bilanoq suratga qaytariladi. setup.
Terminal tekshirilayotgan klasterlar soniga ko'ra ustunlarga bo'lingan; sukut bo'yicha (skrinshotda) to'rttasi bor. Tuchanka2 misolidan foydalanib, ustunlar mazmunini tasvirlab beraman. Skrinshotdagi panellar raqamlangan:
- Test statistikasi bu erda ko'rsatiladi. Ustunlar:
- noto'g'ri β xatoga taqlid qiluvchi test (skriptdagi funksiya) nomi.
- reaktsiya β klaster oΚ»z funksiyasini tiklagan soniyalardagi oΚ»rtacha arifmetik vaqt. Bu xatoga taqlid qiluvchi skriptning boshlanishidan boshlab, klaster o'z funksionalligini tiklab, xizmatlarni ko'rsatishni davom ettira oladigan paytgacha o'lchanadi. Agar vaqt juda qisqa bo'lsa, masalan, olti soniya (bu bir nechta qullar (Tuchanka3 va Tuchanka4) bo'lgan klasterlarda sodir bo'ladi), bu nosozlik asenkron qulda bo'lganligini va hech qanday tarzda ishlashga ta'sir qilmaganligini anglatadi; klaster holati kalitlari.
- og'ish β qiymatning tarqalishini (aniqligini) ko'rsatadi reaktsiya standart og'ish usuli yordamida.
- hisoblash - bu test necha marta o'tkazildi.
- Qisqa jurnal klaster hozirda nima qilayotganini baholash imkonini beradi. Takrorlash (sinov) raqami, vaqt tamg'asi va operatsiya nomi ko'rsatiladi. Juda uzoq ishlash (>5 daqiqa) muammoni ko'rsatadi.
- yurak (yurak) - joriy vaqt. Ish faoliyatini vizual baholash uchun usta Joriy vaqt doimiy ravishda o'z jadvaliga float IP master yordamida yoziladi. Agar muvaffaqiyatli bo'lsa, natija ushbu panelda ko'rsatiladi.
- mag'lub (impuls) - "joriy vaqt", ilgari skript tomonidan yozilgan yurak o'zlashtirmoq, endi dan o'qing qul float IP orqali. Qul va replikatsiyaning ishlashini vizual baholashga imkon beradi. Tuchanka1-da suzuvchi IP-ga ega qullar yo'q (xizmat ko'rsatuvchi qullar yo'q), lekin ikkita misol (JB) mavjud, shuning uchun u bu erda ko'rsatilmaydi mag'lubva yurak ikkinchi misol.
- Yordamchi dastur yordamida klaster sog'lig'ini kuzatish
pcs mon. Resurslarning tuzilishi, tugunlar bo'yicha taqsimlanishi va boshqa foydali ma'lumotlarni ko'rsatadi. - Bu erda klasterdagi har bir virtual mashinadan tizim monitoringi ko'rsatiladi. Klasterda qancha virtual mashinalar mavjudligiga qarab, bunday panellar ko'proq bo'lishi mumkin. Ikkita grafik CPU yuki (virtual mashinalarda ikkita protsessor mavjud), virtual mashina nomi, Tizim yuki (O'rtacha 5, 10 va 15 daqiqa davomida o'rtacha hisoblanganligi uchun o'rtacha yuk deb ataladi), ma'lumotlarni qayta ishlash va xotirani ajratish.
- Sinovni amalga oshirayotgan skript izi. Nosozlik bo'lsa - ishning to'satdan uzilishi yoki cheksiz kutish davri - bu erda siz ushbu xatti-harakatlarning sababini ko'rishingiz mumkin.
Sinov ikki bosqichda amalga oshiriladi. Birinchidan, skript barcha turdagi testlardan o'tadi va tasodifiy ravishda ushbu testni qo'llash uchun virtual mashinani tanlaydi. Keyin cheksiz sinov tsikli amalga oshiriladi, virtual mashinalar va nosozlik har safar tasodifiy tanlanadi. Sinov skriptining to'satdan tugatilishi (pastki panel) yoki biror narsani kutishning cheksiz davri (bitta operatsiya uchun 5 daqiqadan ortiq bajarish vaqti, buni izda ko'rish mumkin) ushbu klasterdagi ba'zi testlar muvaffaqiyatsiz bo'lganligini ko'rsatadi.
Har bir test quyidagi operatsiyalardan iborat:
- Nosozlikni taqlid qiluvchi funktsiyani ishga tushiring.
- Tayyor? β klasterning tiklanishini kutish (barcha xizmatlar taqdim etilganda).
- Klasterni tiklash vaqti tugashini ko'rsatadi (reaktsiya).
- Fix - klaster "ta'mirlanmoqda". Shundan so'ng u to'liq ish holatiga qaytishi va keyingi nosozlikka tayyor bo'lishi kerak.
Bu erda nima qilishlari tavsiflangan testlar ro'yxati:
- ForkBomb: Fork bomba yordamida "Xotira tugadi" ni yaratadi.
- OutOfSpace: Qattiq disk to'lgan. Ammo test juda ramziy; sinov paytida hosil bo'ladigan ahamiyatsiz yuk bilan PostgreSQL odatda qattiq disk to'la bo'lganda ishlamay qolmaydi.
- Postgres - KILL: buyruq bilan PostgreSQLni o'ldiradi
killall -KILL postgres. - Postgres-STOP: PostgreSQL buyrug'ini osib qo'yadi
killall -STOP postgres. - OΚ»chirish: buyruq bilan virtual mashinani "quvvatsizlantiradi"
VBoxManage controlvm "Π²ΠΈΡΡΡΠ°Π»ΠΊΠ°" poweroff. - o'rnatish: virtual mashinani buyruq bilan ortiqcha yuklaydi
VBoxManage controlvm "Π²ΠΈΡΡΡΠ°Π»ΠΊΠ°" reset. - SBD-STOP: buyruq bilan SBD jinini to'xtatib qo'yadi
killall -STOP sbd. - O'chirish; yopish: SSH orqali virtual mashinaga buyruq yuboradi
systemctl poweroff, tizim chiroyli tarzda o'chadi. - Aloqani uzish: tarmoq izolyatsiyasi, buyruq
VBoxManage controlvm "Π²ΠΈΡΡΡΠ°Π»ΠΊΠ°" setlinkstate1 off.
Standart tmux buyrug'i "kill-window" yordamida testni yakunlash Ctrl-b &, yoki "mijozni ajratish" buyrug'i Ctrl-b d: bu vaqtda test tugaydi, tmux yopiladi, virtual mashinalar o'chiriladi.
Sinov jarayonida aniqlangan muammolar
-
Ayni damda qo'riqchi iblis sbd kuzatilgan demonlarni to'xtatish ustida ishlaydi, lekin ularni muzlatish emas. Va, natijada, faqat muzlatishga olib keladigan nosozliklar Korosink ΠΈ yurak stimulyatori, lekin osilgan emas sbd... Tekshirish uchun Korosink endi bor , mavzuga qabul qilindi usta. Ular (PR#83 da) yurak stimulyatori uchun shunga o'xshash narsa bo'lishini va'da qilishdi, umid qilamanki Qizil shapka 8 qiladi. Ammo bunday "nosozliklar" spekulyativdir va ularni sun'iy ravishda osongina simulyatsiya qilish mumkin, masalan,
killall -STOP corosync, lekin haqiqiy hayotda hech qachon uchrashmang. -
Π£ yurak stimulyatori uchun versiyada CentOS 7 noto'g'ri o'rnatilgan sync_timeout Ρ kvorum qurilmasi, Natijada , usta ko'chib o'tishi kerak edi. Kattalashtirish yo'li bilan davolanadi sync_timeout Ρ kvorum qurilmasi joylashtirish paytida (skriptda
setup/setup1). Ushbu tuzatish ishlab chiquvchilar tomonidan qabul qilinmadi yurak stimulyatori, buning o'rniga ular infratuzilmani shunday (aniq noma'lum kelajakda) qayta loyihalashtirishga va'da berishdi, shunda bu kutish vaqti avtomatik ravishda hisoblab chiqiladi. -
Agar ma'lumotlar bazasi konfiguratsiyasi buni belgilasa
LC_MESSAGES(matnli xabarlar) Unicode-dan foydalanish mumkin, masalan.ru_RU.UTF-8, keyin ishga tushirilganda postgres Mahalliy til UTF-8 bo'lmagan muhitda, aytaylik, bo'sh muhitda (bu erda yurak stimulyatori+pgsqlms(paf) yuguradi postgres), keyin . PostgreSQL ishlab chiquvchilari bu holatda nima qilish kerakligi haqida kelishib olishmadi. Bu qimmatga tushadi, siz o'rnatishingiz kerakLC_MESSAGES=en_US.UTF-8ma'lumotlar bazasi namunasini sozlashda (yaratishda). -
Agar wal_receiver_timeout o'rnatilgan bo'lsa (sukut bo'yicha u 60s), u holda tuchanka3 va tuchanka4 klasterlarida masterda PostgreSQL-STOP testi paytida . U erda replikatsiya sinxrondir, shuning uchun nafaqat qul, balki yangi usta ham to'xtaydi. PostgreSQL-ni sozlashda wal_receiver_timeout=0 o'rnatish orqali ishlaydi.
-
Vaqti-vaqti bilan ForkBomb testida PostgreSQL-da replikatsiyaning muzlashini kuzatdim (xotiraning to'lib ketishi). . Men buni faqat tuchanka3 va tuchanka4 klasterlarida uchratdim, bu erda master sinxron replikatsiya tufayli muzlab qoldi. Muammo uzoq vaqtdan keyin (taxminan ikki soat) o'z-o'zidan o'tib ketdi. Buni tuzatish uchun ko'proq tadqiqotlar talab etiladi. Semptomlar oldingi xatoga o'xshaydi, bu boshqa sababga ko'ra yuzaga keladi, lekin bir xil oqibatlarga olib keladi.
Krogan surati olingan muallifning ruxsati bilan:
Manba: www.habr.com