Patroni Failure Stories သို့မဟုတ် သင်၏ PostgreSQL အစုအဝေးကို မည်သို့ ပျက်စီးစေမည်နည်း။ Alexey Lesovsky

Patroni ၏ အဓိကပန်းတိုင်မှာ PostgreSQL အတွက် မြင့်မားသောရရှိနိုင်မှုအား ဖြည့်ဆည်းပေးရန်ဖြစ်သည်။ သို့သော် Patroni သည် အဆင်သင့်လုပ်ထားသော tool မဟုတ်ဘဲ ပုံစံပလိတ်တစ်ခုသာဖြစ်သည် (ယေဘုယျအားဖြင့် စာတမ်းတွင်ဖော်ပြထားသည်)။ ပထမတစ်ချက်တွင် Patroni ကို စမ်းသပ်ဓာတ်ခွဲခန်းတွင် တပ်ဆင်ပြီးနောက်၊ ၎င်းသည် မည်မျှကောင်းမွန်သောကိရိယာဖြစ်ပြီး အစုအဝေးကိုချိုးဖျက်ရန် ကျွန်ုပ်တို့၏ကြိုးပမ်းမှုများကို မည်မျှလွယ်ကူစွာကိုင်တွယ်သည်ကို သင်မြင်နိုင်သည်။ သို့သော် လက်တွေ့တွင်၊ ထုတ်လုပ်မှုပတ်ဝန်းကျင်တွင်၊ စမ်းသပ်ခန်းတစ်ခုတွင်ကဲ့သို့ အရာများသည် အမြဲတမ်း လှပ၍ အံဝင်ခွင်ကျမဖြစ်ပါ။

ကိုယ့်အကြောင်း နည်းနည်းပြောပြမယ်။ စနစ်စီမံခန့်ခွဲသူအဖြစ် စတင်ခဲ့တယ်။ ဝဘ်ဖွံ့ဖြိုးတိုးတက်ရေးတွင်အလုပ်လုပ်ခဲ့သည်။ ကျွန်ုပ်သည် Data Egret တွင် 2014 ခုနှစ်ကတည်းက အလုပ်လုပ်နေပါသည်။ ကုမ္ပဏီသည် Postgres ၏နယ်ပယ်တွင်အတိုင်ပင်ခံလုပ်ငန်းတွင်ပါ ၀ င်သည်။ ကျွန်ုပ်တို့သည် Postgres အတိအကျကို ဆောင်ရွက်ပေးပြီး ကျွန်ုပ်တို့သည် Postgres နှင့် နေ့တိုင်းလုပ်ဆောင်သောကြောင့် ကျွန်ုပ်တို့တွင် ခွဲစိတ်မှုနှင့်ပတ်သက်သည့် ကျွမ်းကျင်မှုအမျိုးမျိုးရှိသည်။

2018 နှစ်ကုန်တွင် Patroni ကို ကျွန်ုပ်တို့ ဖြည်းညှင်းစွာ အသုံးပြုလာကြသည်။ ပြီးတော့ အတွေ့အကြုံတွေ စုဆောင်းပြီးပြီ။ ကျွန်ုပ်တို့သည် ၎င်းကို တစ်နည်းတစ်ဖုံ ရှာဖွေစစ်ဆေးခဲ့ပြီး ချိန်ညှိကာ ကျွန်ုပ်တို့၏ အကောင်းဆုံးအလေ့အကျင့်များဆီသို့ ရောက်လာခဲ့သည်။ ပြီးတော့ ဒီအစီရင်ခံစာမှာ သူတို့အကြောင်း ငါပြောမယ်။

Postgres မှလွဲ၍ Linux ကိုနှစ်သက်သည်။ အဲဒါကို လှည့်ပတ်ပြီး စူးစမ်းရတာ ကြိုက်တယ်၊ Core တွေကို စုဆောင်းရတာ ကြိုက်တယ်။ ငါ virtualization၊ containers၊ docker၊ Kubernetes ကိုကြိုက်တယ်။ အက်မင်အလေ့အထဟောင်းတွေက သက်ရောက်မှုရှိတာကြောင့် ဒါတွေအားလုံးက ကျွန်တော့်ကို စိတ်ဝင်စားတယ်။ စောင့်ကြည့်ဆက်ဆံရတာ ကြိုက်တယ်။ ပြီးတော့ စီမံခန့်ခွဲရေးနဲ့ပတ်သက်တဲ့ postgres တွေ ဥပမာ ကူးယူတာ၊ အရန်သိမ်းတာကို ကြိုက်တယ်။ ပြီးတော့ အားလပ်ချိန်တွေမှာ Go မှာရေးတယ်။ ကျွန်ုပ်သည် ဆော့ဖ်ဝဲလ်အင်ဂျင်နီယာမဟုတ်ပါ၊ ကျွန်ုပ်သည် Go တွင် ကိုယ်တိုင်ရေးရုံသာဖြစ်သည်။ ပြီးတော့ ပျော်ရွှင်မှုပေးတယ်။

• Postgres မှာ HA (High Availability) မရှိဘူးဆိုတာကို တော်တော်များများသိမယ်ထင်ပါတယ်။ HA ရရှိရန်အတွက် သင်သည် တစ်ခုခုကို ထည့်သွင်းရန်၊ ၎င်းကို စီစဉ်သတ်မှတ်ရန်၊ ကြိုးစားအားထုတ်ပြီး ၎င်းကို ရယူရန် လိုအပ်သည်။
• ကိရိယာများစွာရှိပြီး Patroni သည် HA ကိုဖြေရှင်းပေးသည့်အလွန်အေးမြပြီးအလွန်ကောင်းမွန်သည်။ ဒါပေမယ့် အဲဒါအားလုံးကို စမ်းသပ်ဓာတ်ခွဲခန်းထဲမှာ ထည့်ထားပြီး အဲဒါကို လည်ပတ်ခြင်းအားဖြင့်၊ အားလုံးအလုပ်လုပ်တယ်၊ ပြဿနာတချို့ကို မျိုးပွားနိုင်တယ်၊ Patroni က အဲဒါတွေကို ဘယ်လို ဆောင်ရွက်ပေးတယ်ဆိုတာကို ကြည့်ပါ။ ပြီး​တော့ အားလုံး​ကောင်း​ကောင်း​ကောင်း​ကောင်း​လုပ်​ဆောင်​နိုင်​တာ​ကို ကျွန်​တော်​တို့​မြင်​ရ​လိမ့်​မယ်။
• ဒါပေမယ့် လက်တွေ့မှာတော့ မတူညီတဲ့ပြဿနာတွေကို ကြုံတွေ့ခဲ့ရပါတယ်။ ပြီးတော့ ဒီပြဿနာတွေအကြောင်း ပြောပြမယ်။
• အဲဒါကို ဘယ်လိုရောဂါရှာဖွေခဲ့တယ်၊ ဘယ်လိုပြင်ဆင်ခဲ့သလဲဆိုတာကို ပြောပြပါ့မယ်။

• Patroni ကိုမည်ကဲ့သို့ထည့်သွင်းရမည်ကို ကျွန်ုပ်ပြောပြမည်မဟုတ်ပါ၊ အဘယ်ကြောင့်ဆိုသော် သင်သည်အင်တာနက်ပေါ်တွင် google လုပ်နိုင်သောကြောင့်၊ ၎င်းကိုမည်ကဲ့သို့စတင်သည်၊ ၎င်းကိုမည်သို့ပြင်ဆင်ထားသည်ကိုနားလည်ရန် configuration ဖိုင်များကိုကြည့်ရှုနိုင်သည်။ အစီအစဥ်များ၊ ဗိသုကာလက်ရာများ၊ ၎င်းနှင့်ပတ်သက်သည့် အချက်အလက်များကို အင်တာနက်ပေါ်တွင် ရှာဖွေနားလည်နိုင်သည်။
• တခြားသူရဲ့ အတွေ့အကြုံကို ပြောပြမှာ မဟုတ်ပါဘူး။ ကြုံနေရတဲ့ ပြဿနာတွေကိုပဲ ပြောပြမယ်။
• Patroni နှင့် PostgreSQL ပြင်ပရှိ ပြဿနာများအကြောင်း ကျွန်ုပ် မပြောပါ။ ဥပမာအားဖြင့်၊ ချိန်ခွင်လျှာညှိခြင်းနှင့်ဆက်စပ်သည့် ပြဿနာများရှိနေပါက၊ ကျွန်ုပ်တို့၏အစုအဝေးပြိုကျသောအခါ၊ ကျွန်ုပ်သည် ယင်းအကြောင်းကို မပြောပါ။

ကျွန်ုပ်တို့၏ အစီရင်ခံစာကို မစတင်မီ သေးငယ်သော ငြင်းဆိုချက်တစ်ခု။

ကျွန်ုပ်တို့ကြုံတွေ့ခဲ့ရသော ဤပြဿနာများအားလုံးသည် ခွဲစိတ်မှု၏ ပထမ 6-7-8 လတွင် ၎င်းတို့ကို ရရှိခဲ့ပါသည်။ အချိန်ကြာလာသည်နှင့်အမျှ ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ အတွင်းပိုင်း အကောင်းဆုံး အလေ့အကျင့်များဆီသို့ ရောက်လာသည်။ ပြီးတော့ ငါတို့ပြဿနာတွေ ပျောက်သွားတယ်။ ထို့ကြောင့် အစီရင်ခံစာသည် လွန်ခဲ့သော ခြောက်လခန့်က ကျွန်ုပ်၏ခေါင်းထဲတွင် ဆန်းသစ်နေပြီး အားလုံးကို ကောင်းစွာမှတ်မိနေချိန်တွင် ကြေငြာခဲ့သည်။

အစီရင်ခံစာပြင်ဆင်နေစဉ်တွင် အလောင်းကို ခွဲစစ်ဆေးပြီး မှတ်တမ်းဟောင်းများကို ပြုစုပြီးဖြစ်သည်။ အချို့သောအသေးစိတ်အချက်အလက်များကို မေ့လျော့သွားနိုင်သည်၊ သို့မဟုတ် အချို့သောအသေးစိတ်အချက်များသည် ပြဿနာများကို ခွဲခြမ်းစိတ်ဖြာနေစဉ်အတွင်း အပြည့်အဝ မစုံစမ်းနိုင်သောကြောင့် အချို့သောအချက်များတွင် ပြဿနာများကို အပြည့်အဝထည့်သွင်းစဉ်းစားခြင်းမပြုဘဲ သို့မဟုတ် အချက်အလက်များ နည်းပါးနေသည်ဟု ထင်ရပေမည်။ ဒါကြောင့် ဒီအခိုက်အတန့်အတွက် ခွင့်လွှတ်ပေးဖို့ တောင်းဆိုပါတယ်။

Patroni ဆိုတာ ဘာလဲ။

• ဤသည်မှာ HA တည်ဆောက်ရန်အတွက် ပုံစံတစ်ခုဖြစ်သည်။ အဲဒါက စာရွက်စာတမ်းထဲမှာ ပြောတာ။ ပြီးတော့ ကျွန်တော့်အမြင်အရတော့ ဒါဟာ အလွန်မှန်ကန်တဲ့ ရှင်းလင်းချက်ပါပဲ။ Patroni သည် သင့်ပြဿနာအားလုံးကို ဖြေရှင်းပေးမည့် ငွေကျည်ဆံမဟုတ်ပါ၊ ဆိုလိုသည်မှာ ၎င်းကို အလုပ်ဖြစ်အောင်လုပ်ပြီး အကျိုးကျေးဇူးများရရှိစေရန် သင်ကြိုးစားအားထုတ်ရန် လိုအပ်ပါသည်။
• ၎င်းသည် ဒေတာဘေ့စ်ဝန်ဆောင်မှုတိုင်းတွင် ထည့်သွင်းထားသည့် အေးဂျင့်ဝန်ဆောင်မှုတစ်ခုဖြစ်ပြီး သင်၏ Postgres အတွက် init စနစ်တစ်မျိုးဖြစ်သည်။ ၎င်းသည် Postgres စတင်သည်၊ ရပ်သည်၊ ပြန်လည်စတင်သည်၊ ပြန်လည်ဖွဲ့စည်းရန်နှင့် သင်၏အစုအဝေး၏ထိပ်ပိုင်းကို ပြောင်းလဲသည်။
• ထို့ကြောင့်၊ အစုအဝေး၏အခြေအနေကို သိမ်းဆည်းရန်အတွက်၊ ၎င်း၏လက်ရှိကိုယ်စားပြုမှုမှာ၊ အချို့သော သိုလှောင်မှုမျိုး လိုအပ်ပါသည်။ ဤရှုထောင့်မှကြည့်လျှင် Patroni သည် နိုင်ငံတော်ကို ပြင်ပစနစ်တစ်ခုတွင် သိမ်းဆည်းခြင်း၏လမ်းကြောင်းကို ယူခဲ့သည်။ ၎င်းသည် ဖြန့်ဝေထားသော သိုလှောင်မှုစနစ်တစ်ခုဖြစ်သည်။ ၎င်းသည် Etcd၊ Consul၊ ZooKeeper သို့မဟုတ် kubernetes Etcd၊ ဆိုလိုသည်မှာ ဤရွေးချယ်စရာများထဲမှတစ်ခု ဖြစ်နိုင်သည်။
• Patroni ၏ အင်္ဂါရပ်များထဲမှ တစ်ခုမှာ ၎င်းကို တပ်ဆင်ခြင်းဖြင့်သာ autofiler ကို ဘောက်စ်အတွင်းမှ ရရှိခြင်းဖြစ်သည်။ အကယ်၍ ကျွန်ုပ်တို့သည် Repmgr ကို နှိုင်းယှဉ်ပါက၊ filer သည် ထိုနေရာတွင် ပါဝင်သည်။ Repmgr ဖြင့်၊ ကျွန်ုပ်တို့သည် ကူးပြောင်းမှုတစ်ခုကို ရရှိသည်၊ သို့သော် ကျွန်ုပ်တို့သည် autofiler တစ်ခုကို လိုချင်လျှင် ၎င်းကို ထပ်မံ၍ configure လုပ်ရန် လိုအပ်ပါသည်။ Patroni တွင် autofiler တစ်ခုရှိပြီးဖြစ်သည်။
• အခြားအရာများစွာရှိသေးသည်။ ဥပမာအားဖြင့်၊ ပုံစံတူပြင်ဆင်မှုများ၊ အသစ်သွန်းလောင်းခြင်း၊ အရန်သိမ်းဆည်းခြင်းစသည်ဖြင့်၊ ဤအရာသည် အစီရင်ခံစာ၏ ဘောင်ကိုကျော်လွန်၍ ၎င်းအကြောင်းကို မပြောပါ။

သေးငယ်သောရလဒ်မှာ Patroni ၏အဓိကတာဝန်မှာ ကျွန်ုပ်တို့၏ cluster ဆက်လက်လည်ပတ်နေစေရန်ဖြစ်ပြီး အပလီကေးရှင်းသည် cluster topology တွင်ပြောင်းလဲမှုများကိုသတိမပြုမိစေရန်မှာ autofile ကို ကောင်းမွန်စွာယုံကြည်စိတ်ချစွာပြုလုပ်ရန်ဖြစ်သည်။

သို့သော် ကျွန်ုပ်တို့ Patroni ကို စတင်အသုံးပြုသောအခါ၊ ကျွန်ုပ်တို့၏စနစ်သည် အနည်းငယ် ပိုမိုရှုပ်ထွေးလာသည်။ အကယ်၍ ကျွန်ုပ်တို့တွင် Postgres ရှိခဲ့ပါက Patroni ကိုအသုံးပြုသောအခါ Patroni သူ့ဘာသာသူရမည်ဖြစ်ပြီး၊ ပြည်နယ်သိမ်းဆည်းထားသည့် DCS ကိုရရှိမည်ဖြစ်သည်။ ပြီးတော့ အားလုံးက တစ်နည်းနည်းနဲ့ လုပ်ရမှာပေါ့။ ဒါဆို ဘာများမှားသွားနိုင်လဲ။

ချိုးနိုင်သည်-

• Postgres ပျက်သွားနိုင်တယ်။ ၎င်းသည် မာစတာ သို့မဟုတ် ပုံတူဖြစ်နိုင်သည်၊ ၎င်းတို့ထဲမှ တစ်ခုသည် ကျရှုံးနိုင်သည်။
• Patroni ကိုယ်တိုင်က ကွဲသွားနိုင်တယ်။
• ပြည်နယ်သိမ်းထားသည့် DCS ပျက်သွားနိုင်သည်။
• ပြီးတော့ ကွန်ရက် ပျက်သွားနိုင်တယ်။

ဒီအချက်တွေအားလုံးကို အစီရင်ခံစာမှာ ထည့်သွင်းစဉ်းစားပါမယ်။

အမှုအခင်းတွင် အစိတ်အပိုင်းများစွာပါဝင်သည်ဟု ရှုမြင်ခြင်းမဟုတ်ဘဲ ၎င်းတို့သည် ပိုမိုရှုပ်ထွေးလာသောကြောင့် ကျွန်ုပ်သုံးသပ်ပါမည်။ ပြီးတော့ ပုဂ္ဂလဓိဋ္ဌာန်ခံစားမှုရဲ့ ရှုထောင့်ကနေကြည့်ရင် ဒီကိစ္စက ငါ့အတွက် ခက်တယ်၊ အဲဒါကို ဖြုတ်ရခက်တယ်... နဲ့ အပြန်အလှန်အားဖြင့်၊ တချို့ကိစ္စက ပေါ့ပါးပြီး ဖြုတ်ရတာလည်း လွယ်ကူတယ်။

ပထမကိစ္စက အလွယ်ဆုံးပါ။ ကျွန်ုပ်တို့သည် ဒေတာဘေ့စ် အစုအဝေးတစ်ခုကို ယူကာ ကျွန်ုပ်တို့၏ DCS သိုလှောင်မှုကို တူညီသော အစုအဝေးတွင် အသုံးချသောအခါတွင် ဤအရာဖြစ်သည်။ ဒါက အဖြစ်အများဆုံး အမှားပါ။ ၎င်းသည် မတူညီသောအစိတ်အပိုင်းများကို တစ်နေရာတည်းတွင် ပေါင်းစပ်ထားသော ဗိသုကာလက်ရာများကို တည်ဆောက်ရာတွင် အမှားတစ်ခုဖြစ်သည်။

ဒီတော့ filer တစ်ခုရှိတယ်၊ ဖြစ်ပျက်ခဲ့တာကို ကိုင်တွယ်ကြည့်ရအောင်။

ဤနေရာတွင် filer ဖြစ်ခဲ့သည်ကို ကျွန်ုပ်တို့ စိတ်ဝင်စားပါသည်။ ဆိုလိုသည်မှာ၊ အစုအဖွဲ့အခြေအနေပြောင်းလဲသွားသည့်အချိန်၌ ဤအခိုက်အတန့်ကို ကျွန်ုပ်တို့စိတ်ဝင်စားပါသည်။

သို့သော် filer သည် အမြဲတမ်း ချက်ချင်းလက်ငင်းမဟုတ်ပါ၊ ဆိုလိုသည်မှာ အချိန်ယူနစ်တစ်ခုမှ မယူပါ၊ ၎င်းသည် နှောင့်နှေးနိုင်ပါသည်။ ကြာရှည်ခံနိုင်ပါတယ်။

ထို့ကြောင့်၊ ၎င်းတွင် စတင်ချိန်နှင့် ပြီးဆုံးချိန်ရှိသည်၊ ဆိုလိုသည်မှာ ၎င်းသည် စဉ်ဆက်မပြတ်ဖြစ်ရပ်တစ်ခုဖြစ်သည်။ ထို့အပြင် ကျွန်ုပ်တို့သည် အဖြစ်အပျက်အားလုံးကို ကြားကာလသုံးပိုင်းအဖြစ် ပိုင်းခြားထားပါသည်။ ကျွန်ုပ်တို့တွင် ဖိုင်တင်သူရှေ့၊ ဖိုင်တင်သည့်ကာလနှင့် ဖိုင်သူပြီးနောက် ကျွန်ုပ်တို့တွင် အချိန်ရှိသည်။ ဆိုလိုသည်မှာ၊ ဤ timeline ရှိ အဖြစ်အပျက်အားလုံးကို ကျွန်ုပ်တို့ သုံးသပ်ပါသည်။

ပဌမဆုံးအချက်က၊ ဖိုင်လ်တစ်ခု ဖြစ်ခဲ့တဲ့အခါ၊ ဖြစ်ပျက်မှုရဲ့ အကြောင်းရင်း၊ ဖိုလ်ဒါကို ဖြစ်ပေါ်စေတဲ့ အကြောင်းအရင်းက ဘာလဲ၊ အကြောင်းရင်းကို ရှာကြည့်တယ်။

မှတ်တမ်းများကိုကြည့်လျှင် ၎င်းတို့သည် ဂန္ထဝင် Patroni မှတ်တမ်းများဖြစ်သည်။ ဆာဗာသည် မာစတာဖြစ်လာပြီး မာစတာ၏အခန်းကဏ္ဍသည် ဤ node သို့ ရောက်ရှိသွားပြီဖြစ်ကြောင်း ၎င်းတို့တွင် ကျွန်ုပ်တို့အား ပြောထားသည်။ ဤတွင် မီးမောင်းထိုးပြထားသည်။

နောက်တစ်ခု၊ ဖိုင်ဘာဘာကြောင့်ဖြစ်ခဲ့တာလဲ၊ ဥပမာ၊ မာစတာအခန်းက Node တစ်ခုကနေ နောက်တစ်ခုကို ပြောင်းသွားစေတဲ့ အဖြစ်အပျက်တွေ ဖြစ်ပျက်ခဲ့တာကို နားလည်ဖို့လိုတယ်။ ဤကိစ္စတွင်၊ အရာအားလုံးသည်ရိုးရှင်းသည်။ သိုလှောင်မှုစနစ်နှင့် အပြန်အလှန်တုံ့ပြန်ရာတွင် အမှားအယွင်းတစ်ခုရှိသည်။ သခင်သည် DCS နှင့် အလုပ်မလုပ်နိုင်ကြောင်း သဘောပေါက်သည်၊ ဆိုလိုသည်မှာ အပြန်အလှန်ဆက်ဆံရေးတွင် ပြဿနာအချို့ရှိနေသည်။ သူသည် သခင်အဖြစ်မှ နှုတ်ထွက်ခြင်း မပြုနိုင်တော့ဟု ဆိုသည်။ ဒီစာကြောင်းက “မိမိကိုယ်ကို နှိမ့်ချခြင်း” လို့ အတိအကျ ပြောထားတယ်။

filer ရှေ့က အဖြစ်အပျက်တွေကို ကြည့်ရင်၊ wizard ကို ဆက်ပြီး ပြဿနာ ဖြစ်စေတဲ့ အကြောင်းရင်းတွေကို အဲဒီမှာ တွေ့နိုင်ပါတယ်။

Patroni မှတ်တမ်းများကို ကြည့်ပါက၊ ကျွန်ုပ်တို့တွင် အမှားအယွင်းများ၊ အချိန်ကုန်ခြင်းများ အများအပြားရှိသည်၊ ဆိုလိုသည်မှာ Patroni အေးဂျင့်သည် DCS နှင့် အလုပ်မလုပ်နိုင်တော့သည်ကို တွေ့ရပါမည်။ ဤကိစ္စတွင်၊ ၎င်းသည် port 8500 တွင်ဆက်သွယ်နေသောကောင်စစ်ဝန်အေးဂျင့်ဖြစ်သည်။

ဤနေရာတွင် ပြဿနာမှာ Patroni နှင့် database သည် တူညီသော host ပေါ်တွင် လုပ်ဆောင်နေခြင်းဖြစ်သည်။ ကောင်စစ်ဝန်ဆာဗာများကို တူညီသော node ပေါ်တွင် စတင်ခဲ့သည်။ ဆာဗာပေါ်တွင် ဝန်တစ်ခုဖန်တီးခြင်းဖြင့် ကောင်စစ်ဝန်ဆာဗာများအတွက်လည်း ပြဿနာများကို ဖန်တီးခဲ့သည်။ ကောင်းစွာ မဆက်သွယ်နိုင်ခဲ့ကြပါ။

အချိန်အတော်ကြာပြီးနောက်၊ ဝန်လျော့သွားသောအခါ၊ ကျွန်ုပ်တို့၏ Patroni သည် အေးဂျင့်များနှင့် ထပ်မံဆက်သွယ်နိုင်ခဲ့သည်။ ပုံမှန်အလုပ်တွေ ပြန်စပါပြီ။ တူညီသော Pgdb-2 ဆာဗာသည် မာစတာဖြစ်လာပြန်သည်။ ဆိုလိုသည်မှာ၊ node သည်သခင်၏အာဏာများကိုနှုတ်ထွက်ပြီးနောက်တဖန်ပြန်လည်ရယူသောကြောင့်၊ ဆိုလိုသည်မှာအရာအားလုံးသည်ယခင်အတိုင်းပြန်လာသောကြောင့်ဖြစ်သည်။

၎င်းကို မှားယွင်းသောအချက်ပြမှုတစ်ခုအဖြစ် မှတ်ယူနိုင်သည်၊ သို့မဟုတ် Patroni သည် အရာရာတိုင်းကို မှန်ကန်သည်ဟု မှတ်ယူနိုင်သည်။ ဆိုလိုသည်မှာ၊ သူသည် အစုအဖွဲ့၏အခြေအနေကို မထိန်းသိမ်းနိုင်ဘဲ ၎င်း၏လုပ်ပိုင်ခွင့်အာဏာကို ဖယ်ရှားနိုင်သည်ကို သူသဘောပေါက်ခဲ့သည်။

ကောင်စစ်ဝန်ဆာဗာများသည် အခြေခံများကဲ့သို့ ဟာ့ဒ်ဝဲများပေါ်တွင် ရှိနေသောကြောင့် ဤတွင် ပြဿနာပေါ်ပေါက်ခဲ့သည်။ ထို့ကြောင့်၊ မည်သည့်ဝန်ကိုမဆို- ဒစ်ခ်များ သို့မဟုတ် ပရိုဆက်ဆာများတွင် ဝန်ဖြစ်စေ၊ ၎င်းသည် Consul အစုအဝေးနှင့် အပြန်အလှန်အကျိုးသက်ရောက်မှုကိုလည်း သက်ရောက်မှုရှိသည်။

အတူတူမနေသင့်ဘူးလို့ ဆုံးဖြတ်ပြီး ကောင်စစ်ဝန်အတွက် သီးခြားအစုအဖွဲ့တစ်ခုကို ခွဲဝေပေးခဲ့တယ်။ Patroni သည် သီးခြားကောင်စစ်ဝန်တစ်ဦးနှင့် လုပ်ဆောင်နေပြီဖြစ်သည်၊ ဆိုလိုသည်မှာ သီးခြား Postgres အစုအဖွဲ့၊ သီးခြားကောင်စစ်ဝန်အစုအဝေးတစ်ခု ရှိနေပြီဖြစ်သည်။ ဤအရာအားလုံးသည် အတူတကွ မနေထိုင်နိုင်အောင် သယ်ဆောင်ရန်နှင့် သိမ်းဆည်းနည်းအတွက် အခြေခံလမ်းညွှန်ချက်ဖြစ်သည်။

ရွေးချယ်စရာတစ်ခုအနေဖြင့်၊ သင်သည် ကန့်သတ်ဘောင်များကို ttl၊ loop_wait၊ retry_timeout၊ ဆိုလိုသည်မှာ ဤကန့်သတ်ချက်များကို တိုးမြှင့်ခြင်းဖြင့် ဤရေတို load peak များကို ရှင်သန်ရန် ကြိုးစားနိုင်သည်။ ဒါပေမယ့် ဒါက အသင့်တော်ဆုံး ရွေးချယ်မှုတော့ မဟုတ်ပါဘူး၊ ဘာကြောင့်လဲဆိုတော့ ဒီဝန်က အချိန်ကြာကြာနေနိုင်လို့ပါ။ ကျွန်ုပ်တို့သည် ဤကန့်သတ်ချက်များကို ကျော်လွန်သွားပါမည်။ ပြီးတော့ အဲဒါက တကယ်ကို မကူညီနိုင်ဘူးလေ။

သင်နားလည်သည့်အတိုင်း ပထမပြဿနာမှာ ရိုးရှင်းပါသည်။ DCS ကို အရင်းနဲ့ တွဲယူပြီးတော့ ပြဿနာတက်သွားတယ်။

ဒုတိယပြဿနာသည် ပထမပြဿနာနှင့် ဆင်တူသည်။ ကျွန်ုပ်တို့သည် DCS စနစ်တွင် အပြန်အလှန်လုပ်ဆောင်နိုင်မှု ပြဿနာများ ထပ်မံကြုံတွေ့နေရသည့်အတွက် အလားတူပင်ဖြစ်သည်။

မှတ်တမ်းများကို ကြည့်လျှင် ကျွန်ုပ်တို့တွင် ဆက်သွယ်ရေး ချို့ယွင်းချက် ရှိနေသည်ကို တွေ့ရလိမ့်မည်။ Patroni က DCS နှင့် မဆက်သွယ်နိုင်သောကြောင့် လက်ရှိမာစတာသည် ပုံစံတူမုဒ်သို့ သွားပါသည်။

သခင်ဟောင်းသည် ပုံစံတူဖြစ်လာသည်၊ ဤနေရာတွင် Patroni သည် ဖြစ်သင့်သည်အတိုင်း လုပ်ဆောင်သည်။ ၎င်းသည် အရောင်းအ၀ယ်မှတ်တမ်းကို ပြန်ကြည့်ရန် pg_rewind လုပ်ဆောင်ပြီး မာစတာအသစ်နှင့် လိုက်မီရန် မာစတာအသစ်ကို ချိတ်ဆက်ပါ။ ဒီမှာ Patroni က သူလုပ်သင့်သလောက် လုပ်တယ်။

ဤနေရာတွင် filer ၏ ရှေ့သွားမည့်နေရာကို ရှာရမည်ဖြစ်ပြီး၊ ဆိုလိုသည်မှာ filer တစ်ခုရှိစေသော အမှားများဖြစ်သည်။ ဤကိစ္စနှင့်စပ်လျဉ်း၍ Patroni မှတ်တမ်းများသည် အလုပ်လုပ်ရန် အတော်လေး အဆင်ပြေပါသည်။ သူသည် အချိန်ကာလတစ်ခုတွင် တူညီသောစာများကို ရေးသည်။ အကယ်၍ ကျွန်ုပ်တို့သည် ဤမှတ်တမ်းများကို လျင်မြန်စွာ စတင်ရှာဖွေပါက၊ မှတ်တမ်းများ ပြောင်းလဲသွားသည်ကို မြင်တွေ့ရမည်ဖြစ်ပြီး၊ ဆိုလိုသည်မှာ အချို့သော ပြဿနာများ စတင်နေပြီဖြစ်သည်။ ငါတို့ ဒီနေရာကို အမြန်ပြန်လာပြီး ဘာဖြစ်သွားလဲဆိုတာ ကြည့်လိုက်ပါ။

သာမာန်အခြေအနေတွင် သစ်လုံးများသည် ဤကဲ့သို့သော အရာမျိုးဖြစ်သည်။ သော့ပိုင်ရှင်ကို စစ်ဆေးတယ်။ ဥပမာအားဖြင့် ပိုင်ရှင်သည် ပြောင်းလဲသွားပါက Patroni တုံ့ပြန်ရမည့် ဖြစ်ရပ်အချို့ ဖြစ်ပေါ်လာနိုင်သည်။ ဒါပေမယ့် ဒီကိစ္စမှာ ကျွန်တော်တို့ အဆင်ပြေပါတယ်။ အမှားများစတင်ခဲ့သည့်နေရာကို ကျွန်ုပ်တို့ရှာဖွေနေပါသည်။

အမှားများ ပေါ်လာသည့် နေရာကို လှိမ့်လိုက်ပြီးနောက်၊ ကျွန်ုပ်တို့တွင် auto-fileover ရှိသည်ကို ကျွန်ုပ်တို့တွေ့မြင်ရပါသည်။ ကျွန်ုပ်တို့၏အမှားများသည် DCS နှင့်အပြန်အလှန်ဆက်သွယ်မှုနှင့်ပတ်သက်ပြီး ကျွန်ုပ်တို့၏ကိစ္စရပ်တွင် ကောင်စစ်ဝန်ကိုအသုံးပြုသောကြောင့်၊ ကျွန်ုပ်တို့သည် ကောင်စစ်ဝန်မှတ်တမ်းများကိုကြည့်ပါ၊ ထိုနေရာတွင်ဖြစ်ပျက်ခဲ့သမျှကိုကြည့်ပါ။

တိုင်ကြားသူ၏အချိန်နှင့် ကောင်စစ်ဝန်မှတ်တမ်းများတွင် အချိန်ကို အကြမ်းဖျင်း နှိုင်းယှဉ်ကြည့်ပါက ကောင်စစ်ဝန်အစုအဝေးရှိ ကျွန်ုပ်တို့၏အိမ်နီးချင်းများသည် ကောင်စစ်ဝန်အစုအဖွဲ့၏ အခြားအဖွဲ့ဝင်များ၏ တည်ရှိမှုကို သံသယစပြုလာသည်ကို ကျွန်ုပ်တို့တွေ့မြင်ရပါသည်။

အခြားကောင်စစ်ဝန်အေးဂျင့်များ၏ မှတ်တမ်းများကိုလည်း လေ့လာကြည့်လျှင် ကွန်ရက်ပြိုကျမှုမျိုးသည် ထိုနေရာတွင် ဖြစ်ပွားနေကြောင်း သင်တွေ့နိုင်သည်။ ကောင်စစ်ဝန်အစုအဖွဲ့မှ အဖွဲ့ဝင်များအားလုံးသည် အချင်းချင်း၏တည်ရှိမှုကို သံသယ၀င်ကြသည်။ ပြီးတော့ ဒါက filer အတွက် တွန်းအားဖြစ်ခဲ့တယ်။

ဤအမှားများ မတိုင်မီ ဖြစ်ပျက်ခဲ့သည်ကို လေ့လာကြည့်ပါက၊ ဥပမာ၊ နောက်ဆုံးနေ့၊ RPC ကျဆင်းသွားသည်၊ ဆိုလိုသည်မှာ ကောင်စစ်ဝန်အစုအဖွဲ့ ဝင်များအချင်းချင်း အပြန်အလှန် ဆက်ဆံရာတွင် ပြဿနာအချို့ ရှိနေသည်ကို သင်တွေ့နိုင်သည်။ .

အရိုးရှင်းဆုံးအဖြေမှာ ကွန်ရက်ကို ပြုပြင်ရန်ဖြစ်သည်။ ဒါပေမယ့် ကျွန်တော့်အတွက်ကတော့ စင်မြင့်ပေါ်မှာ ရပ်တည်နေတာက ဒီလိုပြောရတာ လွယ်ပါတယ်။ သို့သော် ဖောက်သည်သည် ကွန်ရက်ကို အမြဲပြုပြင်ရန် မတတ်နိုင်သည့် အခြေအနေမျိုး ဖြစ်နေသည်။ သူသည် DC တွင်နေထိုင်နိုင်ပြီး ကွန်ရက်ကို မပြုပြင်နိုင်ဘဲ စက်ပစ္စည်းများကို ထိခိုက်နိုင်သည်။ ထို့ကြောင့် အခြားရွေးချယ်စရာအချို့ လိုအပ်ပါသည်။

ရွေးချယ်စရာများ ရှိသည်-

• စာရွက်စာတမ်းများတွင်ပင် ကျွန်ုပ်၏ထင်မြင်ယူဆချက်တွင် ရေးထားသည့် အရိုးရှင်းဆုံးရွေးချယ်မှုမှာ ကောင်စစ်ဝန်စစ်ဆေးမှုများကို ပိတ်ရန်ဖြစ်သည်၊ ဆိုလိုသည်မှာ ဗလာကျင်းတစ်ခုကို ဖြတ်သွားရုံသာဖြစ်သည်။ ပြီးတော့ စစ်ဆေးမှုတွေကို မသုံးဖို့ ကောင်စစ်ဝန်ကို ကျွန်တော်တို့ ပြောထားပါတယ်။ ဤစစ်ဆေးမှုများဖြင့် ကျွန်ုပ်တို့သည် ဤကွန်ရက်မုန်တိုင်းများကို လျစ်လျူရှုနိုင်ပြီး ဖိုင်ကိုစတင်လုပ်ဆောင်ခြင်းမပြုနိုင်ပါ။
• အခြားရွေးချယ်စရာမှာ raft_multiplier ကို နှစ်ချက်စစ်ဆေးရန်။ ၎င်းသည် Consul ဆာဗာကိုယ်တိုင်၏ ကန့်သတ်ချက်တစ်ခုဖြစ်သည်။ ပုံသေအားဖြင့်၊ ၎င်းကို 5 ဟုသတ်မှတ်ထားသည်။ ဤတန်ဖိုးကို ဇာတ်ညွှန်းပတ်ဝန်းကျင်များအတွက် မှတ်တမ်းပြုစုခြင်းဖြင့် အကြံပြုထားသည်။ အမှန်မှာ၊ ၎င်းသည် ကောင်စစ်ဝန်ကွန်ရက်အဖွဲ့ဝင်များကြား စာပို့သည့်အကြိမ်ရေအပေါ် သက်ရောက်မှုရှိသည်။ အမှန်မှာ၊ ဤကန့်သတ်ချက်သည် ကောင်စစ်ဝန်အစုအဖွဲ့၏ အဖွဲ့ဝင်များကြား ဝန်ဆောင်မှုဆက်သွယ်ရေး၏ အရှိန်အဟုန်ကို သက်ရောက်မှုရှိသည်။ ထုတ်လုပ်မှုအတွက်၊ ၎င်းကို လျှော့ချရန် အကြံပြုထားပြီး ဖြစ်သောကြောင့် node များသည် မက်ဆေ့ချ်များ ပိုမိုမကြာခဏ ဖလှယ်နိုင်စေပါသည်။
• ကျွန်ုပ်တို့ရရှိလာသည့် နောက်ထပ်ရွေးချယ်စရာတစ်ခုမှာ လည်ပတ်စနစ်၏ လုပ်ငန်းစဉ်အစီအစဉ်အတွက် အခြားလုပ်ငန်းစဉ်များအကြား ကောင်စစ်ဝန်လုပ်ငန်းစဉ်များကို ဦးစားပေးလုပ်ဆောင်ရန်ဖြစ်သည်။ ထိုသို့သော “ကောင်းမွန်သော” ကန့်သတ်ဘောင်တစ်ခု ရှိသည်၊ ၎င်းသည် အချိန်ဇယားဆွဲသည့်အခါ OS အစီအစဉ်ဆွဲသူမှ ထည့်သွင်းစဉ်းစားသည့် လုပ်ငန်းစဉ်များ၏ ဦးစားပေးမှုကိုသာ ဆုံးဖြတ်သည်။ ကောင်စစ်ဝန်အေးဂျင့်များအတွက် ကောင်းသောတန်ဖိုးကိုလည်း ကျွန်ုပ်တို့ လျှော့ချထားပါသည်။ လည်ပတ်မှုစနစ်သည် Consul လုပ်ငန်းစဉ်များကို အချိန်ပိုပေးပြီး ၎င်းတို့၏ကုဒ်ကို လုပ်ဆောင်ရန်အတွက် ဦးစားပေးကို တိုးမြှင့်ထားသည်။ ကျွန်ုပ်တို့၏ကိစ္စတွင်၊ ဤအရာသည်ကျွန်ုပ်တို့၏ပြဿနာကိုဖြေရှင်းခဲ့သည်။
• အခြားရွေးချယ်စရာမှာ ကောင်စစ်ဝန်ကို အသုံးမပြုရန်ဖြစ်သည်။ ကျွန်တော့်မှာ Etcd ကို ထောက်ခံသူ ကြီးကြီးတစ်ယောက် ရှိတယ်။ ပြီးတော့ Etcd သို့မဟုတ် Consul က ပိုကောင်းတဲ့သူနဲ့ မကြာခဏ ငြင်းခုံပါတယ်။ ဒါပေမယ့် ပိုကောင်းတာက Consul မှာ database တစ်ခုနဲ့ node တစ်ခုစီမှာ အလုပ်လုပ်သင့်တဲ့ အေးဂျင့်တစ်ခုရှိတယ်ဆိုတာ သူသဘောတူပါတယ်။ ဆိုလိုသည်မှာ၊ Patroni ၏ Consul အစုအဖွဲ့နှင့် Patroni ၏အပြန်အလှန်ဆက်သွယ်မှုသည်ဤအေးဂျင့်မှတဆင့်ဖြစ်သည်။ ပြီးတော့ ဒီအေးဂျင့်က တစ်ဆို့သွားတာပေါ့။ အေးဂျင့်တစ်ခုခုဖြစ်သွားပါက Patroni သည် Consul cluster နှင့် အလုပ်မလုပ်တော့ပါ။ ပြီးတော့ ဒါက ပြဿနာပါ။ Etcd အစီအစဉ်တွင် ကိုယ်စားလှယ်မရှိပါ။ Patroni သည် Etcd ဆာဗာများစာရင်းနှင့် တိုက်ရိုက်အလုပ်လုပ်နိုင်ပြီး ၎င်းတို့နှင့် ဆက်သွယ်ပြီးသားဖြစ်သည်။ ဤကိစ္စနှင့် ပတ်သက်၍ သင်သည်သင်၏ကုမ္ပဏီတွင် Etcd ကိုအသုံးပြုပါက Etcd သည် Consul ထက်ပိုမိုကောင်းမွန်သောရွေးချယ်မှုဖြစ်နိုင်သည်။ သို့သော် ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ဖောက်သည်များကို ဖောက်သည်ရွေးချယ်ထားသည့်အရာဖြင့် အမြဲကန့်သတ်ထားသည်။ ဖောက်သည်အားလုံးအတွက် ကျွန်ုပ်တို့တွင် ကောင်စစ်ဝန်ရှိသည်။
• နောက်ဆုံးအချက်မှာ parameter တန်ဖိုးများကို ပြန်လည်ပြင်ဆင်ရန်ဖြစ်သည်။ ကျွန်ုပ်တို့၏ရေတိုကွန်ရက်ပြဿနာများသည် တိုတောင်းပြီး ဤကန့်သတ်ဘောင်၏အကွာအဝေးအပြင်ဘက်သို့ မကျရောက်စေရန် ကျွန်ုပ်တို့၏ရေတိုကွန်ရက်ပြဿနာများကို မျှော်လင့်ခြင်းဖြင့် ဤကန့်သတ်ချက်များကို မြှင့်တင်နိုင်ပါသည်။ ဤနည်းဖြင့် ကွန်ရက်ပြဿနာအချို့ ဖြစ်ပွားပါက Patroni ၏ ရန်လိုမှုကို လျှော့ချနိုင်သည်။

Patroni သုံးသူတော်တော်များများက ဒီ command နဲ့ ရင်းနှီးပြီးသားလို့ထင်ပါတယ်။

ဤအမိန့်တော်သည် အစုအဝေး၏ လက်ရှိအခြေအနေကို ပြသသည်။ ပထမတစ်ချက်တွင်၊ ဤပုံသည် သာမန်ဟုထင်ရပေမည်။ ကျွန်ုပ်တို့တွင် သခင်တစ်ဦးရှိသည်၊ ကျွန်ုပ်တို့တွင် ပုံတူတစ်ခုရှိသည်၊ အတုယူရန် နောက်ကျနေခြင်းမရှိပါ။ ဒါပေမယ့် ဒီအစုအဝေးမှာ နှစ်ခုမဟုတ်ဘဲ node သုံးခုရှိရမယ်ဆိုတာကို ငါတို့သိတဲ့အထိ ဒီပုံက ပုံမှန်ပါပဲ။

ထို့ကြောင့်၊ autofile တစ်ခုရှိခဲ့သည်။ ဤ autofile ပြီးနောက်၊ ကျွန်ုပ်တို့၏ပုံတူသည် ပျောက်ကွယ်သွားပါသည်။ သူမ ဘာကြောင့် ပျောက်ကွယ်သွားပြီး သူ့ကို ပြန်ခေါ်လာတယ်၊ သူ့ကို ပြန်ပေးရမယ် ဆိုတာ သိဖို့လိုတယ်။ ကျွန်ုပ်တို့သည် မှတ်တမ်းများကို တစ်ဖန်သွား၍ ကျွန်ုပ်တို့တွင် အဘယ်ကြောင့် အော်တိုဖိုင်ကို တင်ထားရကြောင်း ကြည့်ရှုပါ။

ဤကိစ္စတွင်၊ ဒုတိယပုံတူသည် သခင်ဖြစ်လာသည်။ အားလုံးအဆင်ပြေတယ်နော်။

ပြီးတော့ အစုလိုက်အပြုံလိုက် ပြိုကျသွားတဲ့ ပုံစံတူကို ကြည့်ဖို့ လိုပါတယ်။ ကျွန်ုပ်တို့သည် Patroni မှတ်တမ်းများကိုဖွင့်ပြီး pg_rewind အဆင့်တွင် အစုအဝေးသို့ ချိတ်ဆက်ခြင်းလုပ်ငန်းစဉ်တွင် ပြဿနာတစ်ခုရှိနေကြောင်း တွေ့ရှိရပါသည်။ အစုအဝေးသို့ ချိတ်ဆက်ရန်၊ ငွေပေးငွေယူမှတ်တမ်းကို ပြန်ကြည့်ရန်၊ မာစတာထံမှ လိုအပ်သော ငွေပေးငွေယူမှတ်တမ်းကို တောင်းဆိုပြီး မာစတာနှင့် လိုက်လျောညီထွေဖြစ်စေရန် ၎င်းကို အသုံးပြုပါ။

ဤကိစ္စတွင်၊ ကျွန်ုပ်တို့တွင် ငွေပေးငွေယူ မှတ်တမ်းတစ်ခု မရှိတော့ဘဲ ပုံစံတူကို မစတင်နိုင်ပါ။ ထို့ကြောင့်၊ ကျွန်ုပ်တို့သည် အမှားတစ်ခုဖြင့် Postgres ကို ရပ်တန့်လိုက်သည်။ ထို့ကြောင့် ၎င်းသည် အစုအဝေးတွင် မရှိပါ။

၎င်းသည် အစုအဝေးတွင် အဘယ်ကြောင့်မရှိသနည်း၊ အဘယ်ကြောင့် မှတ်တမ်းများမရှိသည်ကို နားလည်ရန်လိုသည်။ သခင်သစ်ထံသွား၍ သစ်လုံးများတွင် ပါသောအရာများကို ကြည့်ပါ။ pg_rewind ပြီးသောအခါတွင် စစ်ဆေးရေးဂိတ်တစ်ခု ဖြစ်ပေါ်ခဲ့သည်။ နှင့် အချို့သော ငွေပေးငွေယူမှတ်တမ်းဟောင်းများကို ရိုးရိုးအမည်ပြောင်းခဲ့သည်။ မာစတာဟောင်းသည် မာစတာအသစ်နှင့် ချိတ်ဆက်ရန် ကြိုးစားသောအခါ၊ ဤမှတ်တမ်းများကို မေးမြန်းသောအခါ၊ ၎င်းတို့သည် အမည်ပြောင်းထားပြီးဖြစ်သော်လည်း ၎င်းတို့သည် မရှိခဲ့ပါ။

ဒီအဖြစ်အပျက်တွေ ဖြစ်ခဲ့တဲ့ အချိန်တွေကို ကျွန်တော် နှိုင်းယှဉ်ကြည့်မိပါတယ်။ ထိုနေရာတွင် ခြားနားချက်မှာ စာသားအရ 150 မီလီစက္ကန့်ဖြစ်သည်၊ ဆိုလိုသည်မှာ 369 မီလီစက္ကန့်အတွင်း စစ်ဆေးရေးဂိတ်ကို WAL အပိုင်းများဟု အမည်ပြောင်းခဲ့သည်။ စာသားအရ 517 တွင် 150 မီလီစက္ကန့်အကြာတွင်၊ အဟောင်းပုံစံတူကို ပြန်ရစ်သည်။ ဆိုလိုသည်မှာ၊ စာသားအရ 150 မီလီစက္ကန့်သည် ကျွန်ုပ်တို့အတွက် လုံလောက်သောကြောင့် ပုံတူသည် ချိတ်ဆက်၍မရပါ။

ရွေးချယ်စရာတွေကဘာတွေလဲ။

ကျွန်ုပ်တို့သည် ကနဦးတွင် ပုံတူပွားခြင်းများကို အသုံးပြုခဲ့သည်။ ကောင်းတယ်လို့ ထင်ခဲ့ကြတယ်။ လည်ပတ်မှုပထမအဆင့်တွင်သော်လည်း၊ ကျွန်ုပ်တို့သည် slot များကိုပိတ်ထားသည်။ အကွက်များသည် WAL အပိုင်းများစွာ စုပုံနေပါက၊ ကျွန်ုပ်တို့သည် မာစတာကို လွှတ်ချနိုင်သည်ဟု ထင်ရသည်။ သူလဲကျလိမ့်မယ်။ ကျွန်ုပ်တို့သည် အထိုင်များမရှိဘဲ အချိန်အတော်ကြာ ခံစားခဲ့ရသည်။ ပြီးတော့ ကျွန်တော်တို့ slot တွေလိုတယ်ဆိုတာ သဘောပေါက်ပြီး slot တွေကို ပြန်ပေးတယ်။

သို့သော် ဤနေရာတွင် မာစတာသည် ပုံစံတူသို့သွားသည့်အခါ၊ ၎င်းသည် အကွက်များကို ဖျက်ပြီး အကွက်များနှင့်အတူ WAL အပိုင်းများကို ဖျက်ပစ်သည်မှာ ပြဿနာတစ်ခုရှိသည်။ ဤပြဿနာကို ဖယ်ရှားရန်၊ ကျွန်ုပ်တို့သည် wal_keep_segments ကန့်သတ်ဘောင်ကို မြှင့်တင်ရန် ဆုံးဖြတ်ခဲ့သည်။ ၎င်းသည် အပိုင်း ၈ ပိုင်းအထိ သတ်မှတ်ထားသည်။ အဲဒါကို 8 နဲ့ မြှင့်တင်ပြီး နေရာဘယ်လောက်လွတ်လဲဆိုတာကို ကြည့်ပါ။ ပြီးတော့ wal_keep_segments အတွက် 1 ဂစ်ဂါဘိုက်ကို လှူဒါန်းခဲ့ပါတယ်။ ဆိုလိုသည်မှာ၊ ကူးပြောင်းသည့်အခါတွင်၊ ကျွန်ုပ်တို့သည် node အားလုံးတွင် ငွေပေးငွေယူမှတ်တမ်းများ 000 gigabyte ၏ အရန်ငွေအမြဲရှိသည်။

ထို့အပြင် - ၎င်းသည် ရေရှည်ထိန်းသိမ်းခြင်းလုပ်ငန်းများအတွက် သက်ဆိုင်ဆဲဖြစ်သည်။ ပုံတူများထဲမှ တစ်ခုကို အပ်ဒိတ်လုပ်ရန် လိုအပ်သည်ဆိုပါစို့။ ပြီးတော့ ငါတို့က အဲဒါကို ပိတ်ချင်တယ်။ ဆော့ဖ်ဝဲ၊ လည်ပတ်မှုစနစ်၊ အခြားအရာတစ်ခုခုကို အပ်ဒိတ်လုပ်ရန် လိုအပ်သည်။ ပုံတူတစ်ခုကို ပိတ်လိုက်သောအခါ၊ ထိုပုံတူအတွက် အပေါက်ကိုလည်း ဖယ်ရှားပါသည်။ အကယ်၍ ကျွန်ုပ်တို့သည် wal_keep_segments ငယ်ကို အသုံးပြုပါက၊ ထို့နောက် ပုံတူတစ်ခုမျှ ကြာကြာမရှိသဖြင့်၊ ငွေပေးငွေယူမှတ်တမ်းများ ဆုံးရှုံးသွားမည်ဖြစ်သည်။ ကျွန်ုပ်တို့သည် ပုံတူတစ်ခုကို ပြုစုပျိုးထောင်မည်ဖြစ်ပြီး၊ ၎င်းသည် ရပ်တန့်သွားသော အဆိုပါ ငွေပေးငွေယူမှတ်တမ်းများကို တောင်းဆိုလိမ့်မည်၊ သို့သော် ၎င်းတို့သည် မာစတာတွင် ရှိနေမည်မဟုတ်ပါ။ ပုံတူသည်လည်းကောင်း ချိတ်ဆက်နိုင်မည် မဟုတ်ပါ။ ထို့ကြောင့် ကျွန်ုပ်တို့သည် မဂ္ဂဇင်းများစွာကို သိမ်းဆည်းထားသည်။

ကျွန်တော်တို့မှာ ထုတ်လုပ်မှုအခြေခံရှိတယ်။ ပရောဂျက်တွေ လုပ်နေပြီ။

ဖိုင်လ်တစ်ခုရှိခဲ့သည်။ ကျွန်ုပ်တို့ ဝင်ကြည့်သည် - အရာအားလုံးသည် စနစ်ကျသည်၊ ပုံစံတူများသည် နေရာယူထားပြီး၊ ပုံတူကူးချခြင်း မရှိတော့ပါ။ မှတ်တမ်းများတွင်လည်း အမှားအယွင်းမရှိပါ၊ အရာအားလုံးသည် အစဉ်အတိုင်းဖြစ်သည်။

ထုတ်ကုန်အဖွဲ့မှ ဒေတာအချို့ရှိသင့်သည်ဟု ပြောကြားသော်လည်း ၎င်းကို အရင်းအမြစ်တစ်ခုတည်းမှ မြင်သော်လည်း ဒေတာဘေ့စ်တွင် မတွေ့ပါ။ ပြီးတော့ သူတို့ ဖြစ်ပျက်ခဲ့တာတွေကို နားလည်ဖို့လိုတယ်။

pg_rewind က သူတို့ကို လွတ်သွားတာ ရှင်းပါတယ်။ ဒါကို ချက်ခြင်း သဘောပေါက်ပေမယ့် ဖြစ်ပျက်နေတာကို သွားကြည့်တယ်။

မှတ်တမ်းများတွင်၊ ဖိုင်တင်သူဖြစ်ချိန်၊ သခင်ဖြစ်လာသည့်အချိန်၊ ကျွန်ုပ်တို့သည် အမြဲတမ်းရှာဖွေတွေ့ရှိနိုင်ပြီး၊ သခင်ဟောင်းက မည်သူနည်း၊ သူသည် ပုံစံတူဖြစ်လာလိုသည့်အခါတွင် ကျွန်ုပ်တို့သည် ဤမှတ်တမ်းများကို လိုအပ်သည်ဆိုလိုသည်မှာ ငွေပေးငွေယူမှတ်တမ်းများကို ရှာဖွေရန် ဤမှတ်တမ်းများ လိုအပ်ပါသည်။ ပျောက်ဆုံးခဲ့သည်။

ကျွန်ုပ်တို့၏ဆရာဟောင်းသည် ပြန်လည်စတင်ပါပြီ။ Patroni သည် autorun တွင်မှတ်ပုံတင်ခဲ့သည်။ Patroni ကို စတင်ခဲ့သည်။ ထို့နောက် Postgres ကိုစတင်ခဲ့သည်။ ပိုတိကျသည်မှာ Postgres မစတင်မီနှင့် ၎င်းကို ပုံစံတူမပြုလုပ်မီ Patroni သည် pg_rewind လုပ်ငန်းစဉ်ကို စတင်ခဲ့သည်။ ထို့ကြောင့်၊ သူသည် ငွေပေးငွေယူမှတ်တမ်းများကို ဖျက်လိုက်သည်၊ အသစ်များကို ဒေါင်းလုဒ်လုပ်ပြီး ချိတ်ဆက်ထားသည်။ ဤတွင် Patroni သည် မျှော်လင့်ထားသည့်အတိုင်း စမတ်ကျကျ လုပ်ဆောင်ခဲ့သည်။ အစုအဝေးကို ပြန်လည်ရယူပြီးဖြစ်သည်။ filer 3 nodes ပြီးနောက် ကျွန်ုပ်တို့တွင် node 3 ခု ရှိသည် - အရာအားလုံးသည် အေးမြသည်။

ဒေတာအချို့ ဆုံးရှုံးသွားပါပြီ။ ငါတို့ဘယ်လောက်ဆုံးရှုံးခဲ့ရတယ်ဆိုတာ နားလည်ဖို့ လိုတယ်။ နောက်ပြန်ဆုတ်သွားတဲ့ အခိုက်အတန့်လေးကို ကျွန်တော်တို့ ရှာဖွေနေပါတယ်။ အဲဒီလို ဂျာနယ်တွေမှာ တွေ့နိုင်တယ်။ အစပြု၍ တစ်ခုခုလုပ်ကာ ပြီးဆုံးသွားပါသည်။

မာစတာဟောင်း ထားခဲ့သည့် ငွေပေးငွေယူ မှတ်တမ်းရှိ ရာထူးကို ကျွန်ုပ်တို့ ရှာဖွေရန် လိုအပ်ပါသည်။ ဤကိစ္စတွင်၊ ဤသည်မှာ အမှတ်အသားဖြစ်သည်။ ပြီးတော့ သခင်ဟောင်းက အသစ်နဲ့ မတူတဲ့ အကွာအဝေးကို ဒုတိယ အမှတ်အသားလိုတယ်။

ပုံမှန် pg_wal_lsn_diff ကိုယူ၍ ဤအမှတ်အသားနှစ်ခုကို နှိုင်းယှဉ်ပါ။ ဤကိစ္စတွင်၊ ကျွန်ုပ်တို့သည် 17 megabytes ရရှိသည်။ နည်းနည်းဖြစ်ဖြစ်၊ အများကြီးပဲ၊ လူတိုင်းက သူ့ဘာသာ ဆုံးဖြတ်တယ်။ တစ်စုံတစ်ယောက်အတွက် 17 megabytes သည် မများသောကြောင့်၊ တစ်စုံတစ်ယောက်အတွက် သည် အလွန်များပြီး လက်ခံနိုင်စရာမရှိပါ။ ဤတွင်၊ တစ်ဦးချင်းစီသည် လုပ်ငန်း၏လိုအပ်ချက်များနှင့်အညီ မိမိအတွက် ဆုံးဖြတ်သည်။

သို့သော် ကျွန်ုပ်တို့သည် မိမိတို့အတွက် အဘယ်အရာတွေ့ရှိခဲ့သနည်း။

ဦးစွာ၊ ကျွန်ုပ်တို့ကိုယ်တိုင် ဆုံးဖြတ်ရပါမည် - စနစ်ပြန်လည်စတင်ပြီးနောက် Patroni ကို ကျွန်ုပ်တို့ အမြဲတမ်း အလိုအလျောက်စတင်ရန် လိုအပ်ပါသလား။ သခင်ဟောင်းထံသွား၍ သူမည်မျှဝေးဝေးသွားသည်ကို ကြည့်ရလေ့ရှိသည်။ ငွေပေးငွေယူမှတ်တမ်း၏ အပိုင်းများကို စစ်ဆေးပါ၊ အဲဒီမှာ ဘာပါလဲ ကြည့်ပါ။ ကျွန်ုပ်တို့သည် ဤဒေတာကို ဆုံးရှုံးနိုင်သည်ဖြစ်စေ သို့မဟုတ် ဤဒေတာကို ဆွဲထုတ်ရန်အတွက် သီးခြားမုဒ်တွင် မာစတာအဟောင်းကို လုပ်ဆောင်ရန် လိုအပ်ခြင်းရှိမရှိ နားလည်ရန်။

၎င်းနောက်မှသာလျှင် ကျွန်ုပ်တို့သည် ဤဒေတာကို စွန့်ပစ်နိုင်သည် သို့မဟုတ် ၎င်းကို ပြန်လည်ရယူနိုင်၊ ဤ node ကို ကျွန်ုပ်တို့၏ အစုအဝေးသို့ ပုံစံတူအဖြစ် ချိတ်ဆက်ရန် ဆုံးဖြတ်ရပါမည်။

ထို့အပြင်၊ "maximum_lag_on_failover" အတိုင်းအတာတစ်ခုလည်း ရှိပါသည်။ ပုံမှန်အားဖြင့်၊ ကျွန်ုပ်၏မှတ်ဉာဏ်သည် ကျွန်ုပ်အား ဆောင်ရွက်ပေးမည်ဆိုပါက၊ ဤသတ်မှတ်ချက်သည် 1 megabyte တန်ဖိုးရှိသည်။

သူဘယ်လိုအလုပ်လုပ်သလဲ။ ကျွန်ုပ်တို့၏ ပုံတူပွားမှုတွင် ဒေတာ 1 megabyte နောက်ကျနေပါက၊ ဤပုံတူသည် ရွေးကောက်ပွဲများတွင် ပါဝင်မည်မဟုတ်ပါ။ အကယ်၍ ရုတ်တရက် ဖိုင်လွှဲပြောင်းမှုတစ်ခု ပေါ်ပေါက်လာပါက Patroni သည် မည်သည့်ပုံတူများ နောက်ကျကျန်နေသေးသည်ကို ကြည့်ရှုသည်။ ငွေပေးငွေယူ မှတ်တမ်းများ အများအပြားဖြင့် နောက်ကွယ်တွင် ရှိနေပါက၊ ၎င်းတို့သည် မာစတာ ဖြစ်လာနိုင်မည် မဟုတ်ပါ။ ၎င်းသည် သင့်အား ဒေတာများစွာ ဆုံးရှုံးခြင်းမှ ကာကွယ်ပေးသည့် အလွန်ကောင်းမွန်သော လုံခြုံရေးအင်္ဂါရပ်တစ်ခုဖြစ်သည်။

သို့သော် Patroni အစုအဝေးရှိ ကူးယူမှုနောက်ကျခြင်းနှင့် DCS သည် အချို့သောကြားကာလတွင် အပ်ဒိတ်လုပ်သည့်အတွက် ပြဿနာတစ်ခုရှိပါသည်။ စက္ကန့် 30 သည် default ttl value ဖြစ်သည်ဟု ကျွန်တော်ထင်ပါတယ်။

ထို့ကြောင့်၊ DCS တွင် ပုံတူပွားခြင်းအတွက် ပုံတူကူးယူရန် နှေးကွေးမှုတစ်ခုရှိနိုင်သော်လည်း အမှန်တကယ်တွင် လုံးဝကွဲပြားခြားနားသော နှေးကွေးခြင်း သို့မဟုတ် နောက်ကျကျန်ခြင်း လုံးဝမရှိနိုင်၊ ဆိုလိုသည်မှာ ဤအရာသည် လက်ရှိအချိန်မဟုတ်ပေ။ ပြီးတော့ တကယ့်ရုပ်ပုံလွှာကို အမြဲတမ်း ထင်ဟပ်နေတာ မဟုတ်ပါဘူး။ ပြီးတော့ အဲဒါကို စိတ်ကူးယဉ်ယုတ္တိနဲ့ လုပ်ရတာ မတန်ဘူး။

ပြီးတော့ ဆုံးရှုံးနိုင်ခြေက အမြဲရှိနေတယ်။ အဆိုးဆုံးတွင် ဖော်မြူလာတစ်ခုနှင့် ပျမ်းမျှကိစ္စတွင် အခြားဖော်မြူလာ။ ဆိုလိုသည်မှာ၊ ကျွန်ုပ်တို့သည် Patroni ကို အကောင်အထည်ဖော်ရန် စီစဉ်ပြီး ကျွန်ုပ်တို့ ဒေတာမည်မျှ ဆုံးရှုံးနိုင်သည်ကို အကဲဖြတ်သည့်အခါ၊ ကျွန်ုပ်တို့သည် ဤဖော်မြူလာများကို အားကိုးရမည်ဖြစ်ပြီး ကျွန်ုပ်တို့သည် ဒေတာမည်မျှ ဆုံးရှုံးနိုင်သည်ကို အကြမ်းဖျင်း တွေးကြည့်ပါ။

ပြီးတော့ သတင်းကောင်းရှိတယ်။ သခင်ဟောင်းသည် ရှေ့သို့သွားသောအခါ၊ အချို့သော နောက်ခံဖြစ်စဉ်များကြောင့် ရှေ့သို့သွားနိုင်သည်။ ဆိုလိုသည်မှာ၊ သူသည် autovacuum အမျိုးအစားအချို့ရှိပါသည်၊ သူသည်ဒေတာကိုရေးသည်၊ ငွေပေးငွေယူမှတ်တမ်းတွင်သိမ်းဆည်းထားသည်။ ပြီးတော့ ဒီဒေတာကို အလွယ်တကူ လျစ်လျူရှုပြီး ဆုံးရှုံးနိုင်ပါတယ်။ ဒီထဲမှာ ဘာပြဿနာမှ မရှိပါဘူး။

မှတ်တမ်းများသည် maximum_lag_on_failover ကို သတ်မှတ်ပြီး filer တစ်ခု ဖြစ်သွားပါက၊ မှတ်တမ်းများသည် မည်ကဲ့သို့ ပုံသဏ္ဌာန်ရှိသနည်း၊ သင်သည် မာစတာအသစ်ကို ရွေးချယ်ရန် လိုအပ်ပါသည်။ ပုံတူသည် ရွေးကောက်ပွဲတွင် မပါဝင်နိုင်ဟု သူ့ကိုယ်သူ အကဲဖြတ်သည်။ ပြီးတော့ သူမဟာ ခေါင်းဆောင်အတွက် ပြိုင်ပွဲမှာ ပါဝင်ဖို့ ငြင်းဆိုခဲ့ပါတယ်။ ပြီးတော့ သခင်အသစ်ကို ရွေးဖို့ စောင့်နေတယ်၊ ​​ဒါမှ သူနဲ့ ချိတ်ဆက်နိုင်မှာပါ။ ဤသည်မှာ ဒေတာဆုံးရှုံးမှုအတွက် နောက်ထပ်တိုင်းတာမှုတစ်ခုဖြစ်သည်။

ဤတွင် ကျွန်ုပ်တို့တွင် ၎င်းတို့၏ထုတ်ကုန်သည် Postgres နှင့် ပြဿနာရှိနေသည်ဟု ရေးထားသော ထုတ်ကုန်အဖွဲ့တစ်ခုရှိသည်။ တစ်ချိန်တည်းမှာပင်၊ SSH မှတစ်ဆင့် မရရှိနိုင်သောကြောင့် မာစတာကိုယ်တိုင်ဝင်ရောက်၍မရပါ။ ပြီးတော့ autofile လည်းမဖြစ်ပါဘူး။

ဤအိမ်ရှင်အား ပြန်ဖွင့်ခိုင်းခဲ့သည်။ ပြန်လည်စတင်ခြင်းကြောင့်၊ ကျွန်ုပ်ယခုနားလည်ထားသည့်အတိုင်း manual auto-file ကိုပြုလုပ်နိုင်သော်လည်း၊ auto-file ဖြစ်သွားပါသည်။ ပြန်လည်စတင်ပြီးနောက်၊ လက်ရှိမာစတာနှင့်ကျွန်ုပ်တို့ရှိနေသည်ကိုတွေ့မြင်ရတော့မည်ဖြစ်သည်။

တစ်ချိန်တည်းမှာပင်၊ ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့တွင် disks များနှင့် ပြဿနာရှိနေကြောင်း ကြိုသိထားပြီးဖြစ်သည်၊ ဆိုလိုသည်မှာ မည်သည့်နေရာတွင် တူးရမည်နှင့် မည်သည့်အရာကို ရှာဖွေရမည်ကို စောင့်ကြည့်ခြင်းမှ ကျွန်ုပ်တို့ သိထားပြီးဖြစ်သည်။

ကျွန်ုပ်တို့သည် postgres မှတ်တမ်းထဲသို့ဝင်၍ ထိုနေရာတွင်ဖြစ်ပျက်နေသည်များကိုတွေ့မြင်ရတော့သည်။ အဲဒီ့မှာ တစ်၊ နှစ်၊ သုံးစက္ကန့်လောက်ကြာအောင် ကတိကဝတ်တွေ တွေ့ခဲ့တယ်၊ ဒါက လုံးဝ ပုံမှန်တော့ မဟုတ်ပါဘူး။ ကျွန်ုပ်တို့၏ autovacuum သည် အလွန်နှေးကွေးပြီး ထူးထူးခြားခြား စတင်သည်ကို ကျွန်ုပ်တို့တွေ့မြင်ခဲ့ရသည်။ ပြီးတော့ ဒစ်ပေါ်မှာ ယာယီဖိုင်တွေ တွေ့တယ်။ ဆိုလိုသည်မှာ၊ ဤအရာအားလုံးသည် disks နှင့်ပြဿနာများ၏ညွှန်ပြချက်များဖြစ်သည်။

ကျွန်ုပ်တို့သည် စနစ် dmesg (kernel မှတ်တမ်း) သို့ ကြည့်ရှုခဲ့သည်။ ကျွန်ုပ်တို့သည် disks တစ်ခုနှင့်ပြဿနာများရှိသည်ကိုကျွန်ုပ်တို့တွေ့မြင်ခဲ့သည်။ disk ခွဲစနစ်သည် ဆော့ဖ်ဝဲ Raid ဖြစ်သည်။ ကျွန်ုပ်တို့သည် /proc/mdstat တွင်ကြည့်ရှုပြီး drive တစ်ခုပျောက်ဆုံးနေသည်ကိုတွေ့လိုက်ရသည်။ ဆိုလိုသည်မှာ၊ 8 disks ၏စီးနင်းမှုတစ်ခုရှိသည်၊ ကျွန်ုပ်တို့တစ်ခုပျောက်ဆုံးနေသည်။ Slide ကို သေချာကြည့်မယ်ဆိုရင် output မှာ sde မရှိဘူးဆိုတာကို တွေ့နိုင်ပါတယ်။ အခြေအနေအရပြောရရင်တော့ ငါတို့မှာ ဒစ်က ပြုတ်သွားပြီ။ ဤအရာသည် ဒစ်ခ်ပြဿနာများဖြစ်ပေါ်စေပြီး အပလီကေးရှင်းများသည် Postgres အစုအဝေးနှင့် လုပ်ဆောင်သည့်အခါတွင်လည်း ပြဿနာများကြုံတွေ့ခဲ့ရသည်။

ဤကိစ္စတွင်၊ Patroni သည် ကျွန်ုပ်တို့အား မည်သည့်နည်းဖြင့်မျှ ကူညီမည်မဟုတ်ပါ၊ အဘယ်ကြောင့်ဆိုသော် Patroni သည် ဆာဗာ၏အခြေအနေ၊ ဒစ်ခ်၏အခြေအနေကို စောင့်ကြည့်ရန်တာဝန်မရှိသောကြောင့်ဖြစ်သည်။ နောက်ပြီးတော့ ပြင်ပက စောင့်ကြည့်မှုတွေက ဒီလိုအခြေအနေတွေကို စောင့်ကြည့်ရမယ်။ ကျွန်ုပ်တို့သည် disk စောင့်ကြည့်ခြင်းကို ပြင်ပစောင့်ကြည့်ခြင်းသို့ လျင်မြန်စွာ ထည့်သွင်းထားပါသည်။

ကာရံခြင်း သို့မဟုတ် စောင့်ကြည့်ရေးဆော့ဖ်ဝဲက ကျွန်ုပ်တို့ကို ကူညီပေးနိုင်မလား။ Patroni သည် ပြဿနာများအတွင်း DCS အစုအဖွဲ့နှင့် ဆက်၍ တုံ့ပြန်ခဲ့ပြီး မည်သည့်ပြဿနာမျှ မတွေ့ခဲ့ရသောကြောင့် ဤကိစ္စတွင် သူသည် ကျွန်ုပ်တို့ကို ကူညီပေးလိမ့်မည်မဟုတ်ဟု ကျွန်ုပ်တို့ ထင်မြင်မိပါသည်။ ဆိုလိုသည်မှာ၊ DCS နှင့် Patroni ၏ရှုထောင့်မှကြည့်လျှင် အစုအဝေးတွင် အရာအားလုံး အဆင်ပြေနေသော်လည်း အမှန်တကယ်တွင် disk တွင် ပြဿနာများရှိသော်လည်း၊ ဒေတာဘေ့စ်ရရှိနိုင်မှုတွင် ပြဿနာများရှိနေသည်။

ကျွန်တော့်အမြင်အရတော့ ဒါက တော်တော်ကြာအောင် သုတေသနပြုထားတဲ့ အထူးဆန်းဆုံး ပြဿနာတွေထဲက တစ်ခုပါ၊ မှတ်တမ်းတွေ အများကြီးဖတ်ပြီး ပြန်ကောက်ပြီး အဲဒါကို အစုလိုက်အပြုံလိုက် simulator လို့ခေါ်တယ်။

ပြဿနာမှာ သခင်ဟောင်းသည် သာမာန်ပုံတူမဖြစ်သွားနိုင်သောကြောင့် Patroni က ၎င်းကို စတင်ခဲ့သည်၊ Patroni သည် ဤ node သည် ပုံစံတူအဖြစ် ရှိနေကြောင်း ပြသခဲ့သော်လည်း တစ်ချိန်တည်းမှာပင် ၎င်းသည် သာမန်ပုံစံတူမဟုတ်ပေ။ အခု မင်းဘာလို့တွေ့မလဲ။ ဒီပြဿနာကို ခွဲခြမ်းစိတ်ဖြာခြင်းကနေ ကျွန်တော် သိမ်းထားခဲ့တာ။

အားလုံးက ဘယ်လိုစခဲ့တာလဲ။ ၎င်းသည် ယခင်ပြဿနာတွင်ကဲ့သို့ ဒစ်ဘရိတ်ဖြင့် စတင်ခဲ့သည်။ ကျွန်ုပ်တို့သည် တစ်စက္ကန့်၊ နှစ်ခုအတွက် ကတိကဝတ်များ ရှိခဲ့သည်။

အဆက်အသွယ်ပြတ်တောက်မှုများရှိခဲ့သည်၊ ဆိုလိုသည်မှာ၊ ဖောက်သည်များစုတ်ပြဲခဲ့သည်။

ပြင်းထန်မှု အမျိုးမျိုး ပိတ်ဆို့ခြင်းများ ရှိခဲ့သည်။

ထို့ကြောင့်၊ disk ခွဲစနစ်သည် အလွန်တုံ့ပြန်မှုမရှိပါ။

ပြီးတော့ ကျွန်တော့်အတွက် အဆန်းကြယ်ဆုံးအရာက ချက်ချင်းရောက်လာတဲ့ ပိတ်ပစ်ဖို့ တောင်းဆိုချက်ပါပဲ။ Postgres တွင် shutdown mode သုံးခုရှိသည်။

• ဖောက်သည်များအားလုံး ၎င်းတို့ကိုယ်တိုင် ချိတ်ဆက်မှုဖြတ်တောက်ရန် စောင့်ဆိုင်းသည့်အခါ ကြည်နူးစရာကောင်းပါသည်။
• ကျွန်ုပ်တို့သည် ဖောက်သည်များကို ပိတ်တော့မည်ဖြစ်သောကြောင့် ကျွန်ုပ်တို့သည် ဖောက်သည်များအား အဆက်ဖြတ်ရန် တွန်းအားပေးသောအခါတွင် မြန်ဆန်ပါသည်။
• ချက်ခြင်း . ဤကိစ္စတွင်၊ ချက်ချင်းပိတ်ရန် ဖောက်သည်များကိုပင် မပြောဘဲ၊ သတိပေးခြင်းမရှိဘဲ ပိတ်လိုက်ရုံသာဖြစ်သည်။ ဖောက်သည်များအားလုံးထံသို့၊ လည်ပတ်မှုစနစ်သည် RST မက်ဆေ့ဂျ်တစ်စောင်ပေးပို့ပြီးဖြစ်သည် (ချိတ်ဆက်မှုပြတ်တောက်နေပြီး ကလိုင်းယင့်ကိုဖမ်းရန် နောက်ထပ်ဘာမျှမရှိသည့် TCP မက်ဆေ့ချ်တစ်ခု)။

ဒီအချက်ပြမှုကို ဘယ်သူပို့တာလဲ။ Postgres နောက်ခံ လုပ်ငန်းစဉ်များသည် တစ်ခုနှင့်တစ်ခုသို့ ထိုကဲ့သို့ အချက်ပြမှုများကို မပို့ပါ၊ ဆိုလိုသည်မှာ ၎င်းသည် kill-9 ဖြစ်သည်။ ၎င်းတို့သည် ထိုအရာများကို အချင်းချင်း မပို့ဘဲ၊ ၎င်းတို့သည် ထိုအရာများကိုသာ တုံ့ပြန်ကြသည်၊ ဆိုလိုသည်မှာ ဤအရာသည် Postgres ၏ အရေးပေါ် ပြန်လည်စတင်ခြင်း ဖြစ်သည်။ ဘယ်သူပို့လဲတော့ မသိဘူး။

"နောက်ဆုံး" အမိန့်ကို ကြည့်လိုက်တော့ ကျွန်တော်တို့နဲ့ ဒီဆာဗာမှာ လော့ဂ်အင်ဝင်ထားတဲ့ လူတစ်ယောက်ကို တွေ့လိုက်ရတယ်၊ ဒါပေမယ့် မေးခွန်းတစ်ခုမေးဖို့ ရှက်လွန်းတယ်။ သတ်-၉ ဖြစ်ကောင်းဖြစ်နိုင်တယ်။ သစ်လုံးထဲမှာ သတ်-၉ သတ်တာတွေ့လို့၊ Postgres က -9 ကိုသတ်ပစ်ခဲ့တယ်လို့ပြောပေမယ့် သစ်လုံးတွေထဲမှာတော့မတွေ့ဘူး။

နောက်ထပ်ကြည့်လိုက်ရင် Patroni က မှတ်တမ်းကို 54 စက္ကန့်ကြာအောင် မရေးခဲ့တာကို ကျွန်တော်တွေ့လိုက်တယ်။ အချိန်တံဆိပ်နှစ်ခုကို နှိုင်းယှဉ်ပါက၊ 54 စက္ကန့်ခန့် မက်ဆေ့ချ်များ မရှိပါ။

ထိုအချိန်တွင် autofile တစ်ခုရှိသည်။ Patroni သည် ဤနေရာတွင် ကောင်းမွန်သော အလုပ်တစ်ခုကို ထပ်မံပြုလုပ်ခဲ့သည်။ ကျွန်ုပ်တို့၏ သခင်ဟောင်းသည် မရနိုင်တော့ပါ၊ တစ်ခုခု ဖြစ်သွားသည်။ သခင်အသစ်၏ ရွေးကောက်ပွဲကို စတင်ခဲ့သည်။ ဒီမှာ အားလုံး အဆင်ပြေသွားပါပြီ။ ကျွန်ုပ်တို့၏ pgsql01 သည် ခေါင်းဆောင်အသစ်ဖြစ်လာပါပြီ။

ကျွန်ုပ်တို့တွင် သခင်ဖြစ်လာသော ပုံတူတစ်ခုရှိသည်။ ပြီးတော့ ဒုတိယ တုံ့ပြန်မှုလည်း ရှိတယ်။ ဒုတိယပုံတူနှင့် ပြဿနာများ ရှိခဲ့သည်။ သူမသည် ပြန်လည်ပြင်ဆင်ရန် ကြိုးစားခဲ့သည်။ ကျွန်တော်နားလည်သလိုပဲ၊ သူက recovery.conf ကိုပြောင်းပြီး Postgres ကို ပြန်စပြီး မာစတာအသစ်နဲ့ ချိတ်ဆက်ဖို့ ကြိုးစားခဲ့ပါတယ်။ သူမကြိုးစားနေတဲ့ 10 စက္ကန့်တိုင်း မက်ဆေ့ချ်တွေရေးပေမယ့် မအောင်မြင်ပါဘူး။

ဤကြိုးပမ်းမှုများအတွင်း၊ ချက်ခြင်းပိတ်သည့်အချက်ပြမှုတစ်ခုသည် မာစတာအိုထံရောက်လာသည်။ မာစတာကို ပြန်လည်စတင်သည်။ မာစတာဟောင်းသည် ပြန်လည်စတင်သွားသောကြောင့် ပြန်လည်ရယူခြင်းမှာလည်း ရပ်သွားပါသည်။ ဆိုလိုသည်မှာ၊ ပုံတူသည် ၎င်းနှင့် ချိတ်ဆက်၍မရပါ၊ ၎င်းသည် shutdown mode တွင်ရှိနေသောကြောင့်ဖြစ်သည်။

တစ်ချိန်ချိန်တွင်၊ ၎င်းသည်အလုပ်လုပ်သော်လည်း၊ ပုံတူပွားမှုမစတင်ပါ။

ကျွန်ုပ်၏ တစ်ခုတည်းသော ခန့်မှန်းချက်မှာ recovery.conf တွင် မာစတာလိပ်စာဟောင်းတစ်ခု ရှိခဲ့ပါသည်။ သခင်အသစ်ပေါ်လာသောအခါ၊ ဒုတိယပုံစံတူသည် သခင်ဟောင်းနှင့် ချိတ်ဆက်ရန် ကြိုးစားဆဲဖြစ်သည်။

Patroni ဒုတိယပုံတူကိုစတင်သောအခါ၊ node သည်စတင်ခဲ့သော်လည်းပုံတူကူးရန်မအောင်မြင်ပါ။ နှင့် ဤကဲ့သို့သောပုံသဏ္ဌာန်တူသော ပုံတူကူးချခြင်းတစ်ခု ဖြစ်ပေါ်လာခဲ့သည်။ ဆိုလိုသည်မှာ၊ node သုံးခုလုံးနေရာ၌ရှိသော်လည်းဒုတိယ node သည်နောက်ကျကျန်နေခဲ့သည်။

တစ်ချိန်တည်းမှာပင်၊ ရေးထားသော မှတ်တမ်းများကို ကြည့်လျှင် ငွေပေးငွေယူ မှတ်တမ်းများ ကွဲပြားသောကြောင့် ပြန်လည်ပုံတူခြင်း မစတင်နိုင်သည်ကို တွေ့နိုင်သည်။ ထို့အပြင် recovery.conf တွင်သတ်မှတ်ထားသော master ကမ်းလှမ်းသောငွေပေးငွေယူမှတ်တမ်းများသည်ကျွန်ုပ်တို့၏လက်ရှိ node နှင့်မကိုက်ညီပါ။

ပြီးတော့ ဒီနေရာမှာ ကျွန်တော် အမှားတစ်ခု လုပ်ခဲ့ပါတယ်။ ကျွန်ုပ်တို့သည် မှားယွင်းသောသခင်နှင့် ချိတ်ဆက်နေသည်ဟူသော ကျွန်ုပ်၏ယူဆချက်အား စမ်းသပ်ရန် recovery.conf တွင် ရှိသည်များကို ကျွန်ုပ်လာရောက်ကြည့်ရှုရမည်ဖြစ်သည်။ ဒါပေမဲ့ အဲဒါကို ကျွန်တော် ကိုင်တွယ်ဖြေရှင်းနေရုံနဲ့ အဲဒါက ကျွန်တော့်အတွက် ဖြစ်မလာဘူး၊ ဒါမှမဟုတ် ပုံစံတူက နောက်ကျကျန်နေတယ်ဆိုတာ မြင်လိုက်ရပြီး ပြန်ဖြည့်ရမှာပဲ၊ ဆိုလိုတာက ကျွန်တော် ပေါ့ပေါ့ဆဆ အလုပ်လုပ်ခဲ့တယ်။ ဒါက ကျွန်တော့်ရဲ့ အဆစ်ပါ။

မိနစ် 30 ကြာပြီးနောက်၊ အက်ဒ်မင်သည် လာနေပြီ၊ ဆိုလိုသည်မှာ ငါ Patroni ပုံစံတူကို ပြန်လည်စတင်ခဲ့သည်။ ဒါကို အပြီးတိုင်ထားပြီး၊ ပြန်ဖြည့်ရမယ်လို့ ထင်ခဲ့တယ်။ ပြီးတော့ ငါ Patroni ကို ပြန်စမယ် ၊ တစ်ခုခုတော့ ကောင်းလာလိမ့်မယ် လို့ တွေးခဲ့တယ်။ ပြန်လည်ထူထောင်ရေးစတင်ခဲ့သည်။ ပြီးတော့ အခြေစိုက်စခန်းကိုတောင် ဖွင့်ထားတော့ ချိတ်ဆက်မှုတွေကို လက်ခံဖို့ အဆင်သင့်ဖြစ်နေပါပြီ။

ပုံတူကူးခြင်း စတင်ပါပြီ။ ဒါပေမယ့် တစ်မိနစ်အကြာမှာတော့ ငွေပေးငွေယူ မှတ်တမ်းတွေဟာ သူ့အတွက် မသင့်တော်တဲ့ အမှားတစ်ခုနဲ့ ပြုတ်ကျသွားခဲ့ပါတယ်။

ငါပြန်စမယ်လို့ထင်ခဲ့တယ်။ Patroni ကို တစ်ဖန်ပြန်လည်စတင်ခဲ့ပြီး Postgres ကို ပြန်လည်စတင်ခြင်းမရှိခဲ့ဘဲ ဒေတာဘေ့စ်ကို အံ့သြဖွယ်စတင်နိုင်မည်ဟုမျှော်လင့်ချက်ဖြင့် Patroni ကို ပြန်လည်စတင်ခဲ့သည်။

ပြန်လည်ပုံတူကူးခြင်း စတင်ခဲ့သည်၊ သို့သော် ငွေပေးငွေယူမှတ်တမ်းရှိ အမှတ်အသားများသည် ကွဲပြားသွားကာ ၎င်းတို့သည် ယခင်စတင်ကြိုးပမ်းမှုနှင့် မတူပါ။ ထပ်တူထပ်မျှ ရပ်တန့်သွားသည်။ ပြီးတော့ သတင်းစကားက နည်းနည်းတော့ ကွဲနေပြီ။ ပြီးတော့ အဲဒါက ငါ့အတွက် သိပ်အသိပေးစရာ မဟုတ်ဘူး။

ပြီးတော့ အဲဒါက ငါ့အတွက် ဖြစ်တတ်ပါတယ် - Postgres ကို ပြန်စရင် ဘာဖြစ်မလဲ၊ ဒီအချိန်မှာ အရောင်းအဝယ် မှတ်တမ်းထဲက အမှတ်ကို ရှေ့နည်းနည်း ရွှေ့ဖို့ လက်ရှိ မာစတာမှာ စစ်ဆေးရေးဂိတ်တစ်ခု လုပ်ထားတယ်၊ ထို့အပြင် ကျွန်ုပ်တို့တွင် WAL စတော့များ ရှိပါသေးသည်။

Patroni ကို ပြန်လည်စတင်ခဲ့ပြီး၊ မာစတာတွင် စစ်ဆေးရေးဂိတ်အချို့ကို လုပ်ဆောင်ခဲ့ပြီး ၎င်းကိုဖွင့်သည့်အခါ ပုံစံတူတွင် ပြန်လည်စတင်သည့်အချက်အချို့ကို လုပ်ဆောင်ခဲ့သည်။ ကူညီပေးခဲ့တယ်။ ဘာ့ကြောင့် ကူညီပေးသလဲ ၊ ဘယ်လိုအလုပ်လုပ်လဲ ဆိုတာကို အချိန်အတော်ကြာ စဉ်းစားခဲ့တယ်။ ပြီးတော့ ပုံတူစပြုတယ်။ ပုံတူကူးခြင်းလည်း စုတ်ပြဲခြင်းမရှိတော့ပါ။

ထိုပြဿနာသည် ကျွန်ုပ်အတွက် ပို၍ လျှို့ဝှက်ဆန်းကြယ်သော အရာများထဲမှ တစ်ခုဖြစ်ပြီး ထိုနေရာတွင် အမှန်တကယ် ဖြစ်ပျက်ခဲ့သည်ကို ကျွန်ုပ် ပဟေဠိဖြစ်နေဆဲဖြစ်သည်။

ဒီနေရာမှာ ဘယ်လိုသက်ရောက်မှုတွေရှိလဲ။ Patroni သည် ရည်ရွယ်ထားသည့်အတိုင်း လုပ်ဆောင်နိုင်ပြီး မည်သည့်အမှားအယွင်းမျှမရှိဘဲ လုပ်ဆောင်နိုင်သည်။ သို့သော် တစ်ချိန်တည်းတွင်၊ ၎င်းသည် ကျွန်ုပ်တို့နှင့် အရာအားလုံး အဆင်ပြေကြောင်း 100% အာမခံချက် မဟုတ်ပါ။ ပုံတူသည် စတင်နိုင်သော်လည်း ၎င်းသည် တစ်ပိုင်းအလုပ်မလုပ်သည့်အခြေအနေတွင် ရှိနေနိုင်ပြီး ဒေတာဟောင်းများရှိမည်ဖြစ်သောကြောင့် အဆိုပါပုံစံတူနှင့် အပလီကေးရှင်းတွင် အလုပ်မလုပ်နိုင်ပါ။

filer ပြီးနောက်၊ အရာအားလုံးသည် အစုအဝေးနှင့် လိုက်လျောညီထွေရှိ၊ ဆိုလိုသည်မှာ၊ လိုအပ်သော ပုံတူအရေအတွက်များ ရှိ၊ ပွားများခြင်း နောက်ကျခြင်း မရှိသည်ကို အမြဲစစ်ဆေးရန် လိုအပ်ပါသည်။

ပြီးတော့ ဒီပြဿနာတွေကို ဖြတ်ကျော်ပြီး အကြံပြုချက်တွေ လုပ်မယ်။ သူတို့ကို ဆလိုက်နှစ်ခုအဖြစ် ပေါင်းစပ်ဖို့ ကြိုးစားခဲ့တယ်။ ဇာတ်လမ်းအားလုံးကို ဆလိုက်နှစ်ခုအဖြစ် ပေါင်းစပ်ပြီး ပြောပြရုံသာ ဖြစ်နိုင်သည်။

Patroni ကို သင်အသုံးပြုသောအခါတွင် စောင့်ကြည့်မှု ရှိရမည်။ သင့်တွင် autofileover တစ်ခုရှိနေသည်ကို သင်မသိပါက၊ အစုအဝေးကို သင်ထိန်းချုပ်နိုင်စွမ်းမရှိသောကြောင့် သင်အမြဲတမ်းသိသင့်သည်။ ဆိုးတယ်။

ဖိုင်တစ်ခုစီပြီးနောက်၊ ကျွန်ုပ်တို့သည် အစုအဝေးကို အမြဲတမ်းစစ်ဆေးရပါမည်။ ကျွန်ုပ်တို့တွင် ခေတ်မီသော ပုံတူများ အမြဲရှိနေစေရန်၊ ကူးယူမှု နှေးကွေးခြင်းမရှိပါ၊ Patroni၊ DCS စနစ်ဖြင့် တိုက်ရိုက်ထုတ်လွှင့်ခြင်းနှင့် သက်ဆိုင်သည့် မှတ်တမ်းများတွင် အမှားအယွင်းများ မရှိပါ။

အလိုအလျောက်စနစ် အောင်မြင်စွာ လုပ်ဆောင်နိုင်သည်၊ Patroni သည် အလွန်ကောင်းမွန်သော ကိရိယာတစ်ခုဖြစ်သည်။ ၎င်းသည် အလုပ်လုပ်နိုင်သော်လည်း ၎င်းသည် အစုအဝေးကို အလိုရှိသော အခြေအနေသို့ ယူဆောင်လာမည်မဟုတ်ပါ။ အဲဒါကို မသိရင် ဒုက္ခရောက်မယ်။

Patroni သည် ငွေကျည်ဆန်မဟုတ်ပါ။ Postgres အလုပ်လုပ်ပုံ၊ ပုံတူကူးပုံအလုပ်လုပ်ပုံနှင့် Patroni အလုပ်လုပ်ပုံနှင့် Postgres နှင့် node များကြား ဆက်သွယ်ရေးကို ပံ့ပိုးပေးပုံတို့ကို နားလည်ရန် လိုအပ်ပါသည်။ သင့်လက်ဖြင့် ပြဿနာများကို ဖြေရှင်းနိုင်စေရန်အတွက် ၎င်းသည် လိုအပ်ပါသည်။

ရောဂါရှာဖွေရေးပြဿနာကို မည်သို့ချဉ်းကပ်ရမည်နည်း။ ကျွန်ုပ်တို့သည် မတူညီသော client များနှင့်အလုပ်လုပ်ပြီး ELK stack တစ်ခုမျှမရှိသည့်အတွက်ကြောင့် ကွန်ဆိုးလ် 6 ခုနှင့် တက်ဘ် 2 ခုကိုဖွင့်ခြင်းဖြင့် မှတ်တမ်းများကိုခွဲထုတ်ရမည်ဖြစ်ပါသည်။ တဘ်တစ်ခုတွင်၊ ၎င်းတို့သည် node တစ်ခုစီအတွက် Patroni မှတ်တမ်းများဖြစ်ပြီး အခြားတက်ဘ်တွင်၊ ၎င်းတို့သည် လိုအပ်ပါက ကောင်စစ်ဝန်မှတ်တမ်းများ သို့မဟုတ် Postgres များဖြစ်သည်။ ဒါကို ဖော်ထုတ်ဖို့ အရမ်းခက်တယ်။

ငါဘယ်လိုချဉ်းကပ်ခဲ့လဲ။ ပထမဆုံး၊ filer ရောက်တဲ့အခါ အမြဲကြည့်တယ်။ ပြီးတော့ ငါ့အတွက် ဒါက ရေကန်ပါ။ filer မတိုင်မီ၊ filer အတွင်းနှင့် filer အပြီးတွင်ဖြစ်ပျက်ခဲ့သည်များကိုကြည့်ရှုပါ။ ဖိုင်ဗာတွင် အမှတ်အသားနှစ်ခုရှိသည်- ဤသည်မှာ စတင်ချိန်နှင့် ပြီးဆုံးချိန်ဖြစ်သည်။

ထို့နောက်၊ filer ၏ရှေ့တွင်ရှိသော အဖြစ်အပျက်များအတွက် မှတ်တမ်းများတွင် ကျွန်ုပ်ကြည့်သည်၊ ဆိုလိုသည်မှာ filer ဖြစ်ပေါ်လာရသည့် အကြောင်းရင်းများကို ရှာဖွေနေပါသည်။

ဤအရာသည် ဖြစ်ပျက်ခဲ့သမျှနှင့် အနာဂတ်တွင် မည်သို့လုပ်ဆောင်နိုင်သည်ကို နားလည်သဘောပေါက်သည့် ပုံရိပ်ကို ပေးစွမ်းနိုင်သောကြောင့် ထိုသို့သော အခြေအနေများ မပေါ်ပေါက်စေရန် (ထို့ကြောင့် ဖိုင်ဘာစနစ်မှ မရှိပါ)။

ငါတို့ဘယ်ကိုကြည့်လေ့ရှိသလဲ။ ကြည့်နေတယ်

• ပထမဦးစွာ Patroni မှတ်တမ်းများဆီသို့။
• ထို့နောက်၊ Patroni မှတ်တမ်းများတွင် တွေ့ရှိရသည့်အပေါ်မူတည်၍ Postgres မှတ်တမ်းများ သို့မဟုတ် DCS မှတ်တမ်းများကို ကြည့်ရှုပါ။
• စနစ်မှတ်တမ်းများသည် တစ်ခါတစ်ရံတွင် ဖိုင်ဘာကြောင့်ဖြစ်ရသည့်အကြောင်းကိုလည်း နားလည်ပေးပါသည်။

Patroni ကို ဘယ်လိုခံစားရလဲ။ Patroni နဲ့ အရမ်းကောင်းတဲ့ ဆက်ဆံရေးရှိပါတယ်။ ကျွန်တော့်အမြင်အရတော့ ဒါဟာ ဒီနေ့အတွက် အကောင်းဆုံးပါပဲ။ အခြားထုတ်ကုန်များစွာကို ကျွန်တော်သိပါသည်။ ၎င်းတို့မှာ Stolon၊ Repmgr၊ Pg_auto_failover၊ PAF တို့ဖြစ်သည်။ ကိရိယာ ၄ ခု။ ငါသူတို့အားလုံးကိုကြိုးစားခဲ့သည်။ Patroni က ကျွန်တော်အကြိုက်ဆုံးပါ။

သူတို့ကငါ့ကိုမေးရင် "Patroni ကိုငါအကြံပြုမလား။" ငါ Patroni ကိုကြိုက်လို့ ဟုတ်တယ်လို့ပြောလိမ့်မယ်။ ပြီးတော့ ချက်ပြုတ်နည်းကို သင်ယူခဲ့တယ် ထင်ပါတယ်။

Patroni တွင်ကျွန်ုပ်ဖော်ပြထားသောပြဿနာများအပြင်သင်သည် Patroni တွင်မည်သည့်ပြဿနာများရှိသည်ကိုသင်စိတ်ဝင်စားပါက၊ သင်သည်စာမျက်နှာကိုအမြဲတမ်းကြည့်ရှုနိုင်သည်။ ကိစ္စများ GitHub တွင် မတူညီတဲ့ ဇာတ်လမ်းတွေ အများကြီးရှိပြီး စိတ်ဝင်စားစရာကောင်းတဲ့ ကိစ္စရပ်တွေလည်း ဆွေးနွေးထားပါတယ်။ ရလဒ်အနေနှင့် အချို့သော bug များကို မိတ်ဆက်ပြီး ဖြေရှင်းခဲ့သည်၊ ဆိုလိုသည်မှာ ဤသည်မှာ စိတ်ဝင်စားစရာကောင်းသောစာဖတ်ခြင်းပင်ဖြစ်သည်။

ခြေထောက်နဲ့ ပစ်သတ်တဲ့ လူတွေအကြောင်း စိတ်ဝင်စားစရာကောင်းတဲ့ ဇာတ်လမ်းတွေရှိတယ်။ အရမ်းအသိပေးတယ်။ အဲဒီလိုလုပ်ဖို့ မလိုအပ်ဘူးဆိုတာ မင်းဖတ်ပြီး နားလည်တယ်။ ကိုယ့်ကိုယ်ကိုယ် အမှတ်ခြစ်မိတယ်။

ပြီးတော့ ဒီပရောဂျက်ကို ဖန်တီးပေးခဲ့တဲ့ Alexander Kukushkin နဲ့ Alexey Klyukin တို့အတွက် Zalando ကို ကျေးဇူးအများကြီးတင်ပါတယ်လို့ ပြောချင်ပါတယ်။ Aleksey Klyukin သည် တွဲဖက်စာရေးဆရာများထဲမှ တစ်ဦးဖြစ်ပြီး Zalando တွင် အလုပ်မရှိတော့သော်လည်း ၎င်းတို့သည် ဤထုတ်ကုန်ကို စတင်လုပ်ကိုင်ခဲ့သူ နှစ်ဦးဖြစ်သည်။

ပြီးတော့ Patroni က အရမ်းမိုက်တဲ့ အရာလို့ ကျွန်တော်ထင်ပါတယ်။ သူမရှိနေတာကို ဝမ်းသာပါတယ်၊ သူ့အတွက် စိတ်ဝင်စားစရာပါ။ Patroni အား ဖာထေးမှုများ ရေးပေးကြသော ပံ့ပိုးကူညီသူများအားလုံးကို ကျေးဇူးအထူးတင်ရှိပါသည်။ Patroni သည် အသက်ကြီးလာသည်နှင့်အမျှ ပိုမိုရင့်ကျက်၊ အေးမြပြီး ထိရောက်လာမည်ဟု မျှော်လင့်ပါသည်။ ၎င်းသည် လုပ်ဆောင်နိုင်နေပြီဖြစ်သော်လည်း ပိုကောင်းလာမည်ဟု မျှော်လင့်ပါသည်။ ထို့ကြောင့် သင်သည် Patroni ကိုအသုံးပြုရန်စီစဉ်ထားပါက မကြောက်ပါနှင့်။ ဒါဟာ ကောင်းမွန်တဲ့ ဖြေရှင်းချက်ဖြစ်ပြီး၊ အကောင်အထည်ဖော်နိုင်ပြီး အသုံးပြုနိုင်ပါတယ်။

ဒါပါပဲ။ မေးစရာများရှိရင် မေးပါ။

မေးခွန်းများကို

အစီရင်ခံစာအတွက် ကျေးဇူးတင်ပါသည်။ အကယ်၍ ဖိုင်တစ်ခုပြီးပါက သင်သည် ထိုနေရာတွင် အလွန်ဂရုတစိုက်ကြည့်ရှုရန် လိုအပ်သေးပါက၊ ကျွန်ုပ်တို့သည် အဘယ်ကြောင့် အလိုအလျောက်ဖိုင်ကို လိုအပ်သနည်း။

ပစ္စည်းအသစ်မို့လို့ပါ။ ငါတို့က သူမနဲ့ တစ်နှစ်လောက်ပဲရှိတာ။ လုံခြုံဖို့ ပိုကောင်းပါတယ်။ ဝင်လာပြီး အရာရာတိုင်းဟာ ဖြစ်သင့်ဖြစ်ထိုက်တာကို တကယ်ပဲ ပြေလည်သွားအောင် မြင်ချင်ပါတယ်။ ဤသည်မှာ အရွယ်ရောက်ပြီးသူများ၏ မယုံကြည်မှုအဆင့်ဖြစ်သည် - နှစ်ဆစစ်ဆေးကြည့်ခြင်းက ပိုကောင်းပါတယ်။

ဥပမာအားဖြင့်၊ ငါတို့က မနက်ခင်းမှာ သွားကြည့်တယ် ဟုတ်လား။

မနက်ခင်းမှာမဟုတ်ပဲ autofile အကြောင်းချက်ချင်းလေ့လာလေ့ရှိပါတယ်။ ကျွန်ုပ်တို့သည် အကြောင်းကြားချက်များကို လက်ခံရရှိသည်၊ autofile တစ်ခုဖြစ်ပွားသည်ကို ကျွန်ုပ်တို့တွေ့မြင်ရပါသည်။ ငါတို့ချက်ချင်းနီးပါးသွားကြည့်တယ်။ ဒါပေမယ့် ဒီစစ်ဆေးမှုတွေအားလုံးကို စောင့်ကြည့်တဲ့အဆင့်အထိ ဆောင်သွားသင့်ပါတယ်။ သင်သည် REST API မှတဆင့် Patroni ကိုဝင်ရောက်ပါက၊ မှတ်တမ်းတစ်ခုရှိသည်။ မှတ်တမ်းအားဖြင့် သင်သည် filer ဖြစ်ခဲ့သောအခါ အချိန်တံဆိပ်တုံးများကို တွေ့နိုင်သည်။ ယင်းကိုအခြေခံ၍ စောင့်ကြည့်စစ်ဆေးနိုင်သည်။ သမိုင်းကြောင်းတွေ၊ အဖြစ်အပျက်တွေ ဘယ်လောက်ရှိတယ်ဆိုတာ မြင်နိုင်ပါတယ်။ ကျွန်ုပ်တို့တွင် နောက်ထပ်ဖြစ်ရပ်များရှိပါက၊ အော်တိုဖိုင်တစ်ခု ဖြစ်သွားပါပြီ။ သွားကြည့်လို့ရပါတယ်။ သို့မဟုတ် ကျွန်ုပ်တို့၏ စောင့်ကြည့်ရေး အလိုအလျောက်စနစ်သည် ကျွန်ုပ်တို့တွင် ပုံတူများအားလုံးကို ထားရှိထားကြောင်း စစ်ဆေးပြီး၊ နှေးကွေးမှုမရှိကြောင်းနှင့် အရာအားလုံး အဆင်ပြေပါသည်။

Thank you!

ဇာတ်လမ်းကောင်းအတွက် ကျေးဇူးအများကြီးတင်ပါတယ်။ ကျွန်ုပ်တို့သည် DCS အစုအဝေးကို Postgres အစုအဝေးမှတစ်နေရာသို့ ရွှေ့ပါက၊ ဤအစုအဝေးကိုလည်း အခါအားလျော်စွာ ဝန်ဆောင်မှုပေးရန် လိုအပ်ပါသည်။ DCS အစုအဝေး၏ အချို့သောအပိုင်းများကို ပိတ်ရန်၊ ၎င်းတို့နှင့် ပတ်သက်သည့်အရာများ စသည်ဖြင့် အကောင်းဆုံးအလေ့အကျင့်များကား အဘယ်နည်း။ ဒီဖွဲ့စည်းပုံတစ်ခုလုံး ဘယ်လိုရှင်သန်မလဲ။ ပြီးတော့ ဒီအရာတွေကို သင်ဘယ်လိုလုပ်မလဲ။

ကုမ္ပဏီတစ်ခုအတွက်၊ အစိတ်အပိုင်းတစ်ခု သို့မဟုတ် အစိတ်အပိုင်းများစွာ ပျက်ကွက်ပါက ပြဿနာများ၏ matrix တစ်ခုပြုလုပ်ရန် လိုအပ်ပါသည်။ ဤမက်ထရစ်အရ၊ ကျွန်ုပ်တို့သည် အစိတ်အပိုင်းများအားလုံးကို ဆင့်ကဲဖြတ်သန်းပြီး ဤအစိတ်အပိုင်းများ ချို့ယွင်းမှုရှိပါက မြင်ကွင်းများကို တည်ဆောက်ပါသည်။ ထို့ကြောင့်၊ ပျက်ကွက်မှုတစ်ခုစီအတွက်၊ ပြန်လည်ရယူရန်အတွက် လုပ်ဆောင်မှုအစီအစဉ်တစ်ခု သင့်တွင်ရှိနိုင်သည်။ DCS ကိစ္စတွင်၊ ၎င်းသည် စံအခြေခံအဆောက်အအုံ၏ တစ်စိတ်တစ်ပိုင်းအဖြစ် လာပါသည်။ ပြီးတော့ အက်ဒ်မင်က အဲဒါကို စီမံခန့်ခွဲတယ်၊ အဲဒါကို စီမံခန့်ခွဲတဲ့ စီမံခန့်ခွဲသူတွေနဲ့ မတော်တဆမှုတွေမှာ ပြုပြင်နိုင်တဲ့ သူတို့ရဲ့ အရည်အချင်းကို ငါတို့က အားကိုးနေပြီ။ DCS လုံးဝမရှိပါက၊ ၎င်းကိုကျွန်ုပ်တို့ဖြန့်ကျက်ထားသော်လည်း၊ အခြေခံအဆောက်အအုံအတွက်ကျွန်ုပ်တို့သည်တာဝန်မရှိသောကြောင့်၎င်းကိုအထူးကြပ်မတ်စစ်ဆေးမည်မဟုတ်သော်လည်းမည်ကဲ့သို့စောင့်ကြည့်ရမည်ကိုအကြံပြုချက်ပေးပါသည်။

ဆိုလိုသည်မှာ၊ ကျွန်ုပ်သည် Patroni ကိုပိတ်ရန်၊ filer ကိုပိတ်ရန်၊ hosts နှင့်ဘာမှမလုပ်မီအရာအားလုံးကို disable လုပ်ရန်လိုအပ်ကြောင်းကိုကျွန်ုပ်မှန်ကန်စွာနားလည်ပါသလား။

၎င်းသည် DCS အစုအဝေးတွင် ကျွန်ုပ်တို့ရှိနေသည့် နံပါတ်မည်မျှအပေါ် မူတည်သည်။ အကယ်၍ node အများအပြားရှိပြီး node များထဲမှ တစ်ခုသာ disable လုပ်ပါက (ပုံတူ)၊ cluster သည် quorum ကို ထိန်းသိမ်းထားသည်။ Patroni သည် လည်ပတ်နေဆဲဖြစ်သည်။ ပြီးတော့ ဘာကိုမှ အစပျိုးမထားဘူး။ အကယ်၍ ကျွန်ုပ်တို့တွင် နောက်ထပ် node များကို ထိခိုက်စေသော ရှုပ်ထွေးသော လုပ်ဆောင်မှုများ ရှိပါက၊ အစီရမ်ကို ပျက်စီးစေနိုင်သည် မရှိတော့ပါက၊ Patroni ကို ခေတ္တရပ်ရန် အဓိပ္ပာယ်ရှိပေမည်။ ၎င်းတွင် သက်ဆိုင်ရာ command တစ်ခုပါရှိသည် - patronictl pause၊ patronictl resume။ ကျွန်ုပ်တို့ ခေတ္တရပ်လိုက်ပြီး autofiler သည် ထိုအချိန်တွင် အလုပ်မလုပ်ပါ။ ကျွန်ုပ်တို့သည် DCS အစုအဝေးတွင် ပြုပြင်ထိန်းသိမ်းမှုပြုလုပ်ပြီးနောက် ခေတ္တရပ်နားပြီး ဆက်လက်နေထိုင်သွားပါမည်။

အလွန်ကျေးဇူးတင်ပါသည်

သင့်အစီရင်ခံစာအတွက် အလွန်ကျေးဇူးတင်ပါသည်။ ဒေတာပျောက်ဆုံးခြင်းနှင့်ပတ်သက်၍ ထုတ်ကုန်အဖွဲ့သည် မည်သို့ခံစားရသနည်း။

ထုတ်ကုန်အဖွဲ့များသည် ဂရုမစိုက်ဘဲ အဖွဲ့ခေါင်းဆောင်များက စိုးရိမ်နေကြသည်။

ဘာအာမခံချက်ရှိလဲ။

အာမခံချက်တွေက အရမ်းခက်တယ်။ Alexander Kukushkin တွင် "RPO နှင့် RTO တွက်ချက်နည်း" အစီရင်ခံစာတစ်ခုရှိပြီး၊ ဆိုလိုသည်မှာ ပြန်လည်ရယူချိန်နှင့် ဒေတာမည်မျှဆုံးရှုံးနိုင်သည်။ ဒီ slides တွေကို ရှာပြီး လေ့လာဖို့ လိုမယ်ထင်တယ်။ ကျွန်တော်မှတ်မိသလောက်တော့ ဒီအချက်တွေကို တွက်ချက်နည်း အတိအကျရှိပါတယ်။ အရောင်းအဝယ်ဘယ်လောက်ဆုံးရှုံးနိုင်သလဲ၊ ဒေတာဘယ်လောက်ဆုံးရှုံးနိုင်မလဲ။ ရွေးချယ်စရာတစ်ခုအနေဖြင့် Patroni အဆင့်တွင် တစ်ပြိုင်နက်တည်း ကူးယူမှုကို ကျွန်ုပ်တို့အသုံးပြုနိုင်သည်၊ သို့သော် ၎င်းသည် နှစ်ဖက်သောဓားဖြစ်သည်- ကျွန်ုပ်တို့တွင် ဒေတာယုံကြည်စိတ်ချရမှုရှိသည် သို့မဟုတ် ကျွန်ုပ်တို့သည် မြန်နှုန်းဆုံးရှုံးသွားနိုင်သည်။ synchronous replication ပါရှိသော်လည်း ဒေတာဆုံးရှုံးခြင်းမှ 100% အကာအကွယ်ပေးခြင်းကိုလည်း အာမမခံနိုင်ပါ။

Alexey၊ ကောင်းမွန်တဲ့ အစီရင်ခံစာအတွက် ကျေးဇူးတင်ပါတယ်။ သုညအဆင့်ကာကွယ်ရေးအတွက် Patroni ကိုအသုံးပြုခြင်းအတွေ့အကြုံရှိပါသလား။ အဲဒါက synchronous standby နဲ့တွဲလား။ ဒါက ပထမမေးခွန်းပါ။ ဒုတိယမေးခွန်း။ သင်သည် မတူညီသော ဖြေရှင်းနည်းများကို အသုံးပြုခဲ့သည်။ ကျွန်ုပ်တို့သည် Repmgr ကိုအသုံးပြုခဲ့သည်၊ သို့သော် autofiler မပါဘဲ၊ ယခုကျွန်ုပ်တို့သည် autofiler ကိုထည့်သွင်းရန်စီစဉ်နေပါသည်။ ပြီးတော့ Patroni ကို အခြားရွေးချယ်စရာ ဖြေရှင်းချက်တစ်ခုအနေနဲ့ ကျွန်တော်တို့ ယူဆပါတယ်။ Repmgr နဲ့ ယှဉ်ရင် ဘာအားသာချက်တွေရှိလဲ။

ပထမမေးခွန်းမှာ synchronous ပုံတူများအကြောင်းဖြစ်သည်။ ဤနေရာတွင် synchronous replication ကို မည်သူမျှ မသုံးကြပေ၊ လူတိုင်း ကြောက်နေကြသောကြောင့် (ဖောက်သည်များစွာသည် ၎င်းကို အသုံးပြုနေကြပြီ၊ မူအရ၊ စွမ်းဆောင်ရည် ပြဿနာများကို သတိမထားမိကြပေ Speaker ၏မှတ်ချက်) သို့သော် synchronous replication cluster တွင် အနည်းဆုံး node သုံးခုရှိသင့်သည်ဟု ကျွန်ုပ်တို့ကိုယ်တိုင် စည်းမျဉ်းတစ်ခုကို ရေးဆွဲထားပြီးဖြစ်သောကြောင့်၊ ကျွန်ုပ်တို့တွင် node နှစ်ခုရှိပြီး မာစတာ သို့မဟုတ် ပုံစံတူပျက်သွားပါက Patroni သည် ဤ node ကို Standalone မုဒ်သို့ ပြောင်းပြီး အပလီကေးရှင်းဆက်လက်လုပ်ဆောင်နိုင်စေရန်၊ အလုပ်။ ဤကိစ္စတွင်၊ ဒေတာဆုံးရှုံးမှုအန္တရာယ်ရှိသည်။

ဒုတိယမေးခွန်းနှင့်ပတ်သက်၍၊ ကျွန်ုပ်တို့သည် Repmgr ကိုအသုံးပြုထားပြီး အချို့သော client များနှင့်လည်း သမိုင်းဆိုင်ရာအကြောင်းပြချက်များဖြင့် လုပ်ဆောင်နေဆဲဖြစ်သည်။ ဘာပြောနိုင်မလဲ။ Patroni သည် ဘောက်စ်အတွင်းမှ autofiler ပါ၀င်သည်၊ Repmgr ကိုဖွင့်ထားရန်လိုအပ်သည့်နောက်ထပ်အင်္ဂါရပ်တစ်ခုအနေဖြင့် autofiler ပါရှိသည်။ Node တစ်ခုစီတွင် Repmgr daemon ကို run ရန်လိုအပ်ပြီး autofiler ကို configure လုပ်နိုင်ပါသည်။

Repmgr သည် Postgres node များ အသက်ရှင်ခြင်းရှိမရှိ စစ်ဆေးသည်။ Repmgr လုပ်ငန်းစဉ်များသည် တစ်ခုနှင့်တစ်ခု တည်ရှိမှုကို စစ်ဆေးပါ၊ ဤသည်မှာ အလွန်ထိရောက်သော ချဉ်းကပ်မှုမဟုတ်ပါ။ ကြီးမားသော Repmgr အစုအဝေးကြီးသည် သေးငယ်သော အစုအဝေးများအဖြစ်သို့ ကွဲသွားပြီး ဆက်လက်လုပ်ဆောင်နိုင်သည့် ရှုပ်ထွေးသော ကွန်ရက်အထီးကျန်ကိစ္စများ ရှိနိုင်ပါသည်။ ကျွန်တော် Repmgr ကို မလိုက်ရတာကြာပြီ၊ ဖြစ်ကောင်းဖြစ်နိုင်သည်... သို့မဟုတ။ သို့သော် Stolon၊ Patroni ကဲ့သို့ DCS ရှိ အစုအဝေး၏အခြေအနေနှင့်ပတ်သက်သည့် အချက်အလက်များကို ဖယ်ရှားခြင်းသည် အထိရောက်ဆုံးရွေးချယ်မှုဖြစ်သည်။

Alexey၊ ငါ့မှာမေးစရာတစ်ခုရှိတယ်၊ မိုက်မဲတဲ့သူတစ်ယောက်ဖြစ်နိုင်တယ်။ ပထမနမူနာများထဲမှ တစ်ခုတွင်၊ သင်သည် DCS ကို စက်တွင်းစက်မှ အဝေးထိန်းဌာနတစ်ခုသို့ ပြောင်းရွှေ့ခဲ့သည်။ ကွန်ရက်သည် ၎င်း၏ကိုယ်ပိုင်ဝိသေသလက္ခဏာများရှိသည့်အရာဖြစ်ပြီး ၎င်းသည် သူ့ဘာသာသူနေထိုင်ကြောင်း ကျွန်ုပ်တို့နားလည်ပါသည်။ DCS အစုအဝေးသည် အကြောင်းတစ်ခုခုကြောင့် မရရှိနိုင်ပါက ဘာဖြစ်နိုင်သနည်း။ အကြောင်းရင်းကို မပြောပါဘူး၊ ကွန်ရက်သမားတွေရဲ့ ကောက်ကျစ်တဲ့လက်ကနေ တကယ့်ပြဿနာတွေအထိ အများကြီးရှိနိုင်ပါတယ်။

ငါအဲဒါကို အသံကျယ်ကျယ် မပြောခဲ့ဘူး၊ ဒါပေမယ့် quorum တစ်ခုကို ပြည့်မီဖို့အတွက် DCS cluster ဟာလည်း ပျက်ကွက်သွားရမှာ ဖြစ်ပါတယ်၊ ဆိုလိုသည်မှာ ၎င်းသည် အထွတ်အထိပ်တစ်ခုဖြစ်သည့် odd နံပါတ်တစ်ခုဖြစ်သည်။ DCS အစုအဝေးကို မရရှိနိုင်ပါက သို့မဟုတ် ကွန်ထရမ်တစ်ခု မပြည့်မီပါက၊ ဆိုလိုသည်မှာ ကွန်ရက်ခွဲခြမ်းခြင်း သို့မဟုတ် node ချို့ယွင်းမှု တစ်မျိုးမျိုး ဖြစ်ပါက မည်သို့ဖြစ်မည်နည်း။ ဤကိစ္စတွင်၊ Patroni အစုအဝေးသည် ဖတ်ရန်သာမုဒ်သို့ ရောက်သွားပါသည်။ Patroni အစုအဖွဲ့သည် အစုအဖွဲ့၏ အခြေအနေနှင့် ဘာလုပ်ရမည်ကို ဆုံးဖြတ်၍မရပါ။ ၎င်းသည် DCS ကိုဆက်သွယ်ပြီး အစုအဝေးအသစ်အခြေအနေကို ထိုနေရာတွင် သိမ်းဆည်း၍မရပါ၊ ထို့ကြောင့် အစုတစ်ခုလုံးသည် ဖတ်ရန်သာဖြစ်သည်။ အော်ပရေတာထံမှ ကိုယ်တိုင်ဝင်ရောက်စွက်ဖက်မှု သို့မဟုတ် DCS ပြန်လည်ရယူရန်အတွက် စောင့်ဆိုင်းနေသည်။

အကြမ်းဖျင်းပြောရလျှင် DCS သည် အခြေခံကိုယ်တိုင်ကဲ့သို့ပင် ကျွန်ုပ်တို့အတွက် အရေးကြီးသည့်ဝန်ဆောင်မှုတစ်ခု ဖြစ်လာပါသလား။

ဟုတ်ကဲ့ဟုတ်ကဲ့။ ခေတ်မီကုမ္ပဏီများစွာတွင်၊ Service Discovery သည် အခြေခံအဆောက်အအုံ၏ မရှိမဖြစ်အစိတ်အပိုင်းတစ်ခုဖြစ်သည်။ အခြေခံအဆောက်အဦများတွင် ဒေတာဘေ့စ်တစ်ခုပင်မရှိမီကပင် ၎င်းကို အကောင်အထည်ဖော်လျက်ရှိသည်။ နှိုင်းရပြောရလျှင် အခြေခံအဆောက်အအုံကို DC တွင် စတင်အသုံးပြုခဲ့ပြီး ကျွန်ုပ်တို့ချက်ချင်းတွင် ဝန်ဆောင်မှုရှာဖွေတွေ့ရှိမှုရှိသည်။ ၎င်းသည် ကောင်စစ်ဝန်ဖြစ်ပါက ၎င်းတွင် DNS ကို တည်ဆောက်နိုင်သည်။ ၎င်းသည် Etcd ဖြစ်ပါက၊ အခြားအရာအားလုံးကို အသုံးပြုမည့် Kubernetes အစုအဝေးမှ အစိတ်အပိုင်းတစ်ခု ရှိနိုင်သည်။ Service Discovery သည် ခေတ်မီအခြေခံအဆောက်အအုံများ၏ မရှိမဖြစ်အစိတ်အပိုင်းတစ်ခုဖြစ်နေပြီဟု ကျွန်တော်ထင်သည်။ ပြီးတော့ သူတို့ဟာ databases တွေအကြောင်းထက် အများကြီးစောပြီး စဉ်းစားကြတယ်။

Thank you!

source: www.habr.com