Failover Cluster PostgreSQL + Patroni။ အကောင်အထည်ဖော်မှုအတွေ့အကြုံ

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

ကျွန်ုပ်တို့တွင် အလွန်တင်ဆောင်ထားသော ဝန်ဆောင်မှုတစ်ခုရှိသည်- ကမ္ဘာတစ်ဝှမ်းရှိ သုံးစွဲသူ 2,5 သန်း၊ နေ့စဉ် 50K+ အသုံးပြုသူများ။ ဆာဗာများသည် အိုင်ယာလန်၏ ဒေသတစ်ခုရှိ Amazone တွင် တည်ရှိသည်- မတူညီသော ဆာဗာ 100+ သည် အဆက်မပြတ် အလုပ်လုပ်နေပြီး ၎င်းတို့ထဲမှ 50 နီးပါးသည် ဒေတာဘေ့စ်များနှင့်အတူ ရှိနေပါသည်။

နောက်ခံတစ်ခုလုံးသည် client နှင့် အဆက်မပြတ် websocket ချိတ်ဆက်မှုကို ထိန်းသိမ်းပေးသည့် ကြီးမားသော monolithic stateful Java အပလီကေးရှင်းတစ်ခုဖြစ်သည်။ အသုံးပြုသူအများအပြားသည် တူညီသောဘုတ်ပေါ်တွင် တစ်ချိန်တည်းအလုပ်လုပ်သောအခါ၊ ကျွန်ုပ်တို့သည် ဒေတာဘေ့စ်သို့ ပြောင်းလဲမှုတစ်ခုစီကို ရေးထားသောကြောင့် ၎င်းတို့အားလုံးသည် အချိန်နှင့်တပြေးညီ ပြောင်းလဲမှုများကို မြင်တွေ့ရသည်။ ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ဒေတာဘေ့စ်များသို့ တစ်စက္ကန့်လျှင် တောင်းဆိုမှု 10K ခန့်ရှိသည်။ Redis တွင် အထွတ်အထိပ်ရောက်ချိန်တွင်၊ ကျွန်ုပ်တို့သည် တစ်စက္ကန့်လျှင် တောင်းဆိုမှု 80-100K တောင်းဆိုချက်များကို ရေးသားပါသည်။

Redis မှ PostgreSQL သို့ ကျွန်ုပ်တို့ ဘာကြောင့် ပြောင်းခဲ့သနည်း။

ကနဦးတွင်၊ ကျွန်ုပ်တို့၏ဝန်ဆောင်မှုသည် ဆာဗာ၏ RAM တွင် ဒေတာအားလုံးကို သိမ်းဆည်းထားသည့် သော့တန်ဖိုးစတိုးတစ်ခုဖြစ်သည့် Redis နှင့် လုပ်ဆောင်ခဲ့သည်။

Redis ၏အားသာချက်များ

1. တုံ့ပြန်မှု အရှိန်မြင့်သောကြောင့် ဖြစ်သည်။ အရာအားလုံးကို မှတ်ဉာဏ်ထဲတွင် သိမ်းဆည်းထားသည်။
2. အရန်ကူးခြင်းနှင့် ပုံတူပွားခြင်း လွယ်ကူခြင်း။

ကျွန်ုပ်တို့အတွက် Redis ၏အားနည်းချက်များ

1. အစစ်အမှန် အရောင်းအဝယ်များ မရှိပါ။ ကျွန်ုပ်တို့၏ လျှောက်လွှာအဆင့်တွင် ၎င်းတို့ကို အတုယူရန် ကြိုးစားခဲ့သည်။ ကံမကောင်းစွာဖြင့်၊ ၎င်းသည် အမြဲတမ်း ကောင်းမွန်စွာ အလုပ်မလုပ်နိုင်ဘဲ အလွန်ရှုပ်ထွေးသော ကုဒ်ကို ရေးသားရန် လိုအပ်ပါသည်။
2. ဒေတာပမာဏကို မမ်မိုရီပမာဏဖြင့် ကန့်သတ်ထားသည်။ ဒေတာပမာဏများလာသည်နှင့်အမျှ၊ မှတ်ဉာဏ်ကြီးထွားလာမည်ဖြစ်ပြီး၊ အဆုံးတွင်၊ ကျွန်ုပ်တို့သည် ရွေးချယ်ထားသော instance ၏ဝိသေသလက္ခဏာများဆီသို့ လည်ပတ်သွားမည်ဖြစ်ပြီး၊ AWS တွင် instance အမျိုးအစားကိုပြောင်းလဲရန် ကျွန်ုပ်တို့၏ဝန်ဆောင်မှုကို ရပ်တန့်ရန်လိုအပ်ပါသည်။
3. အဘယ်ကြောင့်ဆိုသော် low latency level ကို အမြဲထိန်းထားရန် လိုအပ်ပါသည်။ ကျွန်ုပ်တို့တွင် တောင်းဆိုချက်များစွာရှိသည်။ ကျွန်ုပ်တို့အတွက် အကောင်းဆုံးနှောင့်နှေးမှုအဆင့်မှာ 17-20 ms ဖြစ်သည်။ 30-40 ms အဆင့်တွင်၊ ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ လျှောက်လွှာမှ တောင်းဆိုမှုများနှင့် ဝန်ဆောင်မှုကို ပျော့ပျောင်းစေသော ရှည်လျားသော တုံ့ပြန်မှုများကို ရရှိပါသည်။ ကံမကောင်းစွာဖြင့်၊ Redis နှင့် ပတ်သက်သည့် သာဓကတစ်ခုသည် ပုံမှန်ထက် ၂ ဆ ပိုမိုကြာနေချိန်ကို ရရှိသောအခါတွင် ဝမ်းနည်းပါသည်။ ပြဿနာကိုဖြေရှင်းရန် ကျွန်ုပ်တို့သည် အချိန်ဇယားဆွဲမထားဘဲ ပြုပြင်ထိန်းသိမ်းမှုအတွက် ဝန်ဆောင်မှုကို နေ့လယ်ပိုင်းတွင် ရပ်လိုက်ပြီး ပြဿနာရှိသော Redis ဥပမာကို အစားထိုးခဲ့သည်။
4. ကုဒ်တွင် သေးငယ်သော အမှားအယွင်းများနှင့်ပင် ဒေတာမညီညွတ်မှုကို ရရှိရန် လွယ်ကူပြီး ဤဒေတာကို ပြုပြင်ရန် ကုဒ်ရေးရန် အချိန်များစွာ သုံးစွဲပါ။

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

ကျွန်ုပ်တို့သည် ဒေတာဘေ့စ်အသစ်သို့ ပြောင်းရွှေ့နေသည်မှာ 1,5 နှစ်ရှိပြီဖြစ်ပြီး ဒေတာ၏ အနည်းငယ်မျှသာ ပြောင်းရွှေ့ထားသောကြောင့် ယခု ကျွန်ုပ်တို့သည် Redis နှင့် PostgreSQL တို့နှင့် တပြိုင်နက် လုပ်ဆောင်နေပါသည်။ ဒေတာဘေ့စ်များကြား ဒေတာရွေ့လျားခြင်းနှင့် ကူးပြောင်းခြင်း အဆင့်များအကြောင်း နောက်ထပ် အချက်အလက်များကို ရေးထားသည်။ ငါ့လုပ်ဖော်ကိုင်ဖက်ရဲ့ဆောင်းပါး.

ကျွန်ုပ်တို့ စတင်လှုပ်ရှားသောအခါ၊ ကျွန်ုပ်တို့၏ အပလီကေးရှင်းသည် ဒေတာဘေ့စ်နှင့် တိုက်ရိုက်အလုပ်လုပ်ပြီး မာစတာ Redis နှင့် PostgreSQL ကို ဝင်ရောက်ကြည့်ရှုခဲ့သည်။ PostgreSQL အစုအဝေးတွင် မာစတာတစ်ခုနှင့် ပုံတူတစ်ခု ပါ၀င်သည် ။ ဤသည်မှာ ဒေတာဘေ့စ်အစီအစဥ်နှင့် မည်ကဲ့သို့ပုံသဏ္ဍန်ဖြစ်သည်-

PgBouncer ကို အကောင်အထည်ဖော်ခြင်း။

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

ချိတ်ဆက်မှုမန်နေဂျာအတွက် ရွေးချယ်စရာနှစ်ခုရှိသည်- Pgpool နှင့် PgBouncer။ ဒါပေမယ့် ပထမတစ်ခုက ဒေတာဘေ့စ်နဲ့ အလုပ်လုပ်တဲ့ အရောင်းအ၀ယ်ပုံစံကို မပံ့ပိုးတဲ့အတွက် PgBouncer ကို ရွေးချယ်ခဲ့ပါတယ်။

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


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

PgBouncer ရှုံးနိမ့်မှု

တစ်ခုတည်းသော PgBouncer သာဓကသေဆုံးသည့်အချိန်အထိ ဤအစီအစဉ်သည် အလုပ်လုပ်ပါသည်။ ကျွန်ုပ်တို့သည် အခါအားလျော်စွာ သေဆုံးသော ဟာ့ဒ်ဝဲပေါ်တွင် သာဓကများအားလုံးကို လုပ်ဆောင်နေသည့် AWS တွင်ရှိပါသည်။ ထိုသို့သောအခြေအနေမျိုးတွင်၊ ဥပမာသည် ဟာ့ဒ်ဝဲအသစ်သို့ ရွေ့လျားပြီး ပြန်အလုပ်လုပ်သည်။ ၎င်းသည် PgBouncer ဖြင့် ဖြစ်ပွားခဲ့သော်လည်း မရနိုင်ပါ။ ဤဆောင်းဦးရာသီ၏ရလဒ်မှာ ကျွန်ုပ်တို့၏ဝန်ဆောင်မှုကို 25 မိနစ်ကြာအောင် မရရှိနိုင်ခြင်းဖြစ်သည်။ AWS သည် ထိုအချိန်က ကျွန်ုပ်တို့နိုင်ငံ၌ အကောင်အထည်မဖော်ခဲ့သော ထိုသို့သောအခြေအနေများအတွက် အသုံးပြုသူဘက်သို့ ထပ်လောင်းခြင်းကို အသုံးပြုရန် အကြံပြုထားသည်။

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

ကျွန်ုပ်တို့သည် အောက်ပါအတိုင်း PgBouncer အမှားခံနိုင်ရည်ရှိမှုအစီအစဉ်ကို တည်ဆောက်ခဲ့သည်- PgBouncer နှစ်ခုပါရှိသည့် နောက်ကွယ်တွင် အပလီကေးရှင်းဆာဗာများအားလုံးသည် Network Load Balancer ကို ဝင်ရောက်ကြည့်ရှုပါသည်။ PgBouncer တစ်ခုစီသည် shard တစ်ခုစီ၏တူညီသော PostgreSQL မာစတာကိုကြည့်ရှုသည်။ AWS သာဓကတစ်ခု ပျက်ယွင်းမှု ထပ်မံဖြစ်ပွားပါက၊ အသွားအလာအားလုံးကို အခြားသော PgBouncer မှတဆင့် ပြန်ညွှန်းပါသည်။ Network Load Balancer ကျရှုံးမှုကို AWS မှ ပံ့ပိုးပေးပါသည်။

ဤအစီအစဥ်သည် PgBouncer ဆာဗာအသစ်များကို ထည့်သွင်းရန် လွယ်ကူစေသည်။

PostgreSQL Failover Cluster တစ်ခုဖန်တီးပါ။

ဤပြဿနာကိုဖြေရှင်းသောအခါ၊ ကျွန်ုပ်တို့သည် မတူညီသောရွေးချယ်မှုများကို ထည့်သွင်းစဉ်းစားခဲ့သည်- ကိုယ်တိုင်ရေးထားသော ပျက်ကွက်မှု၊ repmgr၊ AWS RDS၊ Patroni။

ကိုယ်တိုင်ရေးထားသော ဇာတ်ညွှန်းများ

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

ဤချဉ်းကပ်နည်း၏ အားသာချက်များမှာ အမြင့်ဆုံးရိုးရှင်းမှုဖြစ်သည်၊ အဘယ်ကြောင့်ဆိုသော် သင်သည် Script များကို ကိုယ်တိုင်ရေးသားပြီး ၎င်းတို့လုပ်ဆောင်ပုံကို အတိအကျနားလည်သောကြောင့်ဖြစ်သည်။

cons:

• ကွန်ရက်ချို့ယွင်းမှုဖြစ်မည့်အစား သခင်မသေဆုံးနိုင်ပါ။ ဒါကို သတိမထားမိဘဲ Failover သည် ပုံစံတူကို သခင်ထံ မြှင့်တင်မည်ဖြစ်ပြီး၊ သခင်ဟောင်းသည် ဆက်လက်လုပ်ဆောင်နေမည်ဖြစ်သည်။ ရလဒ်အနေဖြင့်၊ ကျွန်ုပ်တို့သည် မာစတာ၏အခန်းကဏ္ဍတွင် ဆာဗာနှစ်ခုကိုရရှိမည်ဖြစ်ပြီး ၎င်းတို့အနက်မှ မည်သည့်နောက်ဆုံးပေါ်ဒေတာများပါရှိသည်ကို ကျွန်ုပ်တို့မသိနိုင်ပါ။ ဤအခြေအနေကို ဦးနှောက်ခွဲခြင်းဟုလည်း ခေါ်သည်။
• တုံ့ပြန်မှုမရှိဘဲ ကျွန်ုပ်တို့ ကျန်ရစ်ခဲ့သည်။ ကျွန်ုပ်တို့၏ဖွဲ့စည်းပုံတွင်၊ မာစတာနှင့်ပုံတူတစ်ပုံကို ပြောင်းပြီးနောက်၊ ပုံစံတူသည် မာစတာအထိ ရွေ့သွားပြီး ကျွန်ုပ်တို့တွင် ပုံတူများမရှိတော့သောကြောင့် ကျွန်ုပ်တို့သည် ပုံစံတူအသစ်တစ်ခုကို ကိုယ်တိုင်ထည့်သွင်းရမည်ဖြစ်ပါသည်။
• ကျွန်ုပ်တို့တွင် PostgreSQL shards 12 ခုရှိသော်လည်း ပျက်ကွက်သည့်လုပ်ဆောင်ချက်ကို ထပ်လောင်းစောင့်ကြည့်ရန် လိုအပ်သည်၊ ဆိုလိုသည်မှာ ကျွန်ုပ်တို့သည် အစုအဝေး 12 ခုကို စောင့်ကြည့်ရမည်ဖြစ်ပါသည်။ shards အရေအတွက် တိုးလာသည်နှင့်အမျှ failover ကို update လုပ်ရန်လည်း မမေ့သင့်ပါ။

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

Repmgr

PostgreSQL အစုအဝေးတစ်ခု၏ လုပ်ဆောင်ချက်ကို စီမံခန့်ခွဲနိုင်သည့် PostgreSQL အစုအဝေးများအတွက် ကူးယူမှုမန်နေဂျာ။ တစ်ချိန်တည်းမှာပင်၊ ၎င်းသည် box မှအလိုအလျောက်ပျက်ကွက်မှုမရှိပါကအလုပ်အတွက်အချောသတ်ဖြေရှင်းချက်၏ထိပ်တွင်သင်၏ကိုယ်ပိုင် "wrapper" ကိုရေးရန်လိုအပ်သည်။ ဒါကြောင့် အားလုံးက ကိုယ်တိုင်ရေးထားတဲ့ script တွေထက်တောင် ပိုရှုပ်ထွေးလာနိုင်ပါတယ်၊ ဒါကြောင့် Repmgr ကိုတောင် မစမ်းကြည့်ခဲ့ပါဘူး။

AWS RDS

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

အားနည်းချက်များတွင် ကောင်းမွန်သော ချိန်ညှိမှု မရှိခြင်း ပါဝင်သည်။ ကောင်းစွာချိန်ညှိခြင်း၏ဥပမာတစ်ခုအနေဖြင့်- ကျွန်ုပ်တို့၏ဥပမာများတွင် tcp ချိတ်ဆက်မှုများအတွက် ကန့်သတ်ချက်များရှိသည်၊ ကံမကောင်းစွာဖြင့် RDS တွင်လုပ်ဆောင်၍မရပါ။

net.ipv4.tcp_keepalive_time=10
net.ipv4.tcp_keepalive_intvl=1
net.ipv4.tcp_keepalive_probes=5
net.ipv4.tcp_retries2=3

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

Patroni

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

Patroni ၏အားသာချက်များ

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

cons:

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

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

Patroni အကောင်အထည်ဖော်ရေးလုပ်ငန်းစဉ်

Patroni မတိုင်မီတွင်၊ ကျွန်ုပ်တို့တွင် မာစတာတစ်ခုနှင့် ပုံစံတူတစ်ခု၏ဖွဲ့စည်းပုံတွင် PostgreSQL shard 12 ခုရှိသည်။ အပလီကေးရှင်းဆာဗာများသည် PgBouncer နှင့် သာဓကနှစ်ခုဖြစ်သည့် နောက်ကွယ်ရှိ Network Load Balancer မှတစ်ဆင့် ဒေတာဘေ့စ်များကို ဝင်ရောက်ကြည့်ရှုခဲ့ပြီး ၎င်းတို့နောက်ကွယ်တွင် PostgreSQL ဆာဗာများ အားလုံးပါဝင်ခဲ့သည်။


Patroni ကိုအကောင်အထည်ဖော်ရန်၊ ဖြန့်ဝေထားသောသိုလှောင်မှုအစုအဝေးဖွဲ့စည်းမှုပုံစံကို ရွေးချယ်ရန် လိုအပ်ပါသည်။ Patroni သည် etcd၊ Zookeeper၊ Consul ကဲ့သို့သော ဖြန့်ဝေထားသော ဖွဲ့စည်းမှုပုံစံ သိုလှောင်မှုစနစ်များဖြင့် အလုပ်လုပ်ပါသည်။ ကျွန်ုပ်တို့တွင် Vault နှင့် တွဲဖက်အလုပ်လုပ်သော စျေးကွက်တွင် ပြည့်စုံသော Consul အစုအဝေးတစ်ခုမျှသာရှိပြီး ၎င်းကို ကျွန်ုပ်တို့ အသုံးမပြုတော့ပါ။ ၎င်း၏ ရည်ရွယ်ထားသည့် ရည်ရွယ်ချက်အတွက် ကောင်စစ်ဝန်ကို စတင်အသုံးပြုရန် အကြောင်းပြချက်ကောင်းတစ်ခု။

Patroni ကောင်စစ်ဝန်နှင့်မည်သို့အလုပ်လုပ်သနည်း။

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

Patroni ကို Consul နှင့်ချိတ်ဆက်ရန်၊ ကောင်စစ်ဝန်နှင့်ကျွန်ုပ်တို့မည်သို့အလုပ်လုပ်ပုံနှင့်ချိတ်ဆက်မှုအစီအစဉ်ကိုရွေးချယ်နိုင်သည်အပေါ် မူတည်၍ http သို့မဟုတ် https ဖော်မတ်တွင် host တစ်ခုကိုသတ်မှတ်ရန်လိုအပ်သည်ဟုပြောထားသည့်တရားဝင်စာရွက်စာတမ်းများကိုလေ့လာရန်လုံလောက်သည်-

host: the host:port for the Consul endpoint, in format: http(s)://host:port
scheme: (optional) http or https, defaults to http

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

consul:
  host: https://server.production.consul:8080 
  verify: true
  cacert: {{ consul_cacert }}
  cert: {{ consul_cert }}
  key: {{ consul_key }}

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

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

consul:
  host: server.production.consul:8080
  scheme: https
  verify: true
  cacert: {{ consul_cacert }}
  cert: {{ consul_cert }}
  key: {{ consul_key }}

ကောင်စစ်ဝန်-ပုံစံ

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

အဖြေကိုရှာဖွေရာတွင် PgBouncer နှင့် Patroni တွဲချိတ်ရာတွင် များစွာအထောက်အကူဖြစ်စေသည်ဟု Сonsul-template ရေးထားသည့် ဆောင်းပါးတစ်ပုဒ် (ကံမကောင်းစွာဖြင့် ကျွန်ုပ်မမှတ်မိတော့ပါ)။ ယင်းက Consul-template အလုပ်လုပ်ပုံကို စုံစမ်းစစ်ဆေးရန် ကျွန်ုပ်တို့အား လှုံ့ဆော်ခဲ့သည်။

Consul-template သည် Consul ရှိ PostgreSQL အစုအဝေး၏ဖွဲ့စည်းပုံကို အဆက်မပြတ်စောင့်ကြည့်နေသောကြောင့်ဖြစ်သည်။ ခေါင်းဆောင်ပြောင်းသောအခါ၊ ၎င်းသည် PgBouncer ဖွဲ့စည်းမှုပုံစံကို အပ်ဒိတ်လုပ်ကာ ၎င်းကို ပြန်လည်စတင်ရန် အမိန့်တစ်ခု ပေးပို့သည်။

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

Patroni နှင့်အတူဗိသုကာအသစ်

ရလဒ်အနေဖြင့်၊ ကျွန်ုပ်တို့သည် အောက်ပါလုပ်ငန်းအစီအစဉ်ကို ရရှိခဲ့ပါသည်။


အပလီကေးရှင်းဆာဗာများအားလုံးသည် ချိန်ခွင်လျှာကိုဝင်ရောက်ကြည့်ရှုခြင်း → ၎င်းနောက်ကွယ်တွင် PgBouncer ၏ဖြစ်ရပ်နှစ်ခုရှိပါသည် → တစ်ခုစီတွင်၊ ကောင်စစ်ဝန်ပုံစံကိုဖွင့်ထားသည်၊ Patroni အစုအဝေးတစ်ခုစီ၏အခြေအနေကိုစောင့်ကြည့်ပြီး လက်ရှိခေါင်းဆောင်ထံတောင်းဆိုမှုများကိုပေးပို့သည့် PgBouncer config ၏ဆက်စပ်မှုကိုစောင့်ကြည့်ပေးသည် အစုအဖွဲ့တစ်ခုစီ၏

ကိုယ်တိုင်စမ်းသပ်ခြင်း။

စမ်းသပ်မှုပတ်ဝန်းကျင်တွင် မစတင်မီ ဤအစီအစဥ်ကို လုပ်ဆောင်ခဲ့ပြီး အလိုအလျောက်ပြောင်းခြင်း၏ လုပ်ဆောင်ချက်ကို စစ်ဆေးခဲ့သည်။ သူတို့က ဘုတ်ကိုဖွင့်၊ စတစ်ကာကိုရွှေ့ပြီး အဲဒီအခိုက်အတန့်မှာ အစုအဖွဲ့ခေါင်းဆောင်ကို “သတ်” လိုက်ကြတယ်။ AWS တွင်၊ ၎င်းသည် console မှတဆင့် instance ကိုပိတ်လိုက်သကဲ့သို့ရိုးရှင်းသည်။

စတစ်ကာသည် 10-20 စက္ကန့်အတွင်း ပြန်လာပြီး၊ ထို့နောက် ပုံမှန်အတိုင်း ပြန်လှုပ်ရှားလာသည်။ ဆိုလိုသည်မှာ Patroni အစုအဝေးသည် မှန်ကန်စွာအလုပ်လုပ်ခဲ့သည်- ၎င်းသည် ခေါင်းဆောင်ကိုပြောင်းပြီး Сonsul သို့ အချက်အလက်များ ပေးပို့ကာ၊ Сonsul-template သည် ဤအချက်အလက်များကို ချက်ချင်းကောက်ယူပြီး၊ PgBouncer ဖွဲ့စည်းမှုပုံစံကို အစားထိုးပြီး ပြန်လည်စတင်ရန် အမိန့်ကို ပေးပို့ခဲ့သည်။

မြင့်မားသောဝန်အောက်တွင် ရှင်သန်ရန်နှင့် စက်ရပ်ချိန်ကို နည်းပါးအောင် မည်သို့ထိန်းသိမ်းနိုင်မည်နည်း။

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

ကျွန်ုပ်တို့လုပ်ဆောင်သည့် ဝန်စမ်းသပ်မှုပတ်ဝန်းကျင်သည် ကျွန်ုပ်တို့အား ပထမမေးခွန်းကိုဖြေဆိုရန် ကူညီပေးပါသည်။ ၎င်းသည် ဗိသုကာပညာအရ ထုတ်လုပ်မှုနှင့် လုံးဝတူညီပြီး ထုတ်လုပ်မှုနှင့် ထုထည်နှင့် အနီးစပ်ဆုံးတူညီသော စမ်းသပ်ဒေတာကို ထုတ်ပေးထားသည်။ စမ်းသပ်နေစဉ်အတွင်း PostgreSQL မာစတာများထဲမှ တစ်ဦးကို "သတ်" ရန် ဆုံးဖြတ်ပြီး ဘာဖြစ်မည်ကို ကြည့်ရှုရန် ဆုံးဖြတ်ခဲ့သည်။ သို့သော် ၎င်းမတိုင်မီတွင်၊ အလိုအလျောက်လှိမ့်ခြင်းကို စစ်ဆေးရန် အရေးကြီးသည်၊ အကြောင်းမှာ ဤပတ်ဝန်းကျင်တွင် ကျွန်ုပ်တို့တွင် PostgreSQL shards များစွာရှိသောကြောင့် ထုတ်လုပ်ခြင်းမပြုမီ configuration scripts များကို ကောင်းမွန်သောစမ်းသပ်မှုကို ရရှိမည်ဖြစ်ပါသည်။

အလုပ်နှစ်ခုလုံးသည် ရည်မှန်းချက်ကြီးပုံပေါက်သော်လည်း ကျွန်ုပ်တို့တွင် PostgreSQL 9.6 ရှိသည်။ ကျွန်ုပ်တို့သည် 11.2 သို့ ချက်ချင်း အဆင့်မြှင့်တင်နိုင်ပါသလား။

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

PostgreSQL အပ်ဒိတ်

PostgreSQL ဗားရှင်းကို လျင်မြန်စွာ အပ်ဒိတ်လုပ်ရန်၊ ရွေးချယ်ခွင့်ကို အသုံးပြုပါ။ -kဟာ့ဒ်လင့်ခ်များကို ဒစ်ခ်ပေါ်တွင် ဖန်တီးထားပြီး သင့်ဒေတာကို ကူးယူရန် မလိုအပ်ပါ။ 300-400 GB ကိုအခြေခံ၍ အပ်ဒိတ်သည် 1 စက္ကန့်ကြာသည်။

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

/usr/lib/postgresql/11/bin/pg_upgrade 
<b>--link </b>
--old-datadir='' --new-datadir='' 
 --old-bindir=''  --new-bindir='' 
 --old-options=' -c config_file=' 
 --new-options=' -c config_file='

အဆင့်မြှင့်တင်မှုမစတင်မီ၊ သင်သည် ၎င်းကို ကန့်သတ်ချက်ဖြင့် လုပ်ဆောင်ရမည်ကို ဤနေရာတွင် သတိပြုရန် အရေးကြီးသည်။ --စစ်ဆေးပါ။အဆင့်မြှင့်နိုင်စေရန် သေချာစေရန်။ ကျွန်ုပ်တို့၏ script သည် အဆင့်မြှင့်တင်မှုကာလအတွက် configs များကို အစားထိုးပေးပါသည်။ ကျွန်ုပ်တို့၏ ဇာတ်ညွှန်းသည် စက္ကန့် 30 အတွင်း ပြီးမြောက်ခဲ့ပြီး အလွန်ကောင်းမွန်သော ရလဒ်ဖြစ်သည်။

Patroni ကိုဖွင့်ပါ။

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

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

rm -rf /var/lib/postgresql/

ကျွန်​​တော့်​အတွက်​ပဲ လုပ်​ရမှာ။

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

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

load စမ်းသပ်မှု

ကျွန်ုပ်တို့သည် ဘုတ်များပေါ်တွင် အသုံးပြုသူအတွေ့အကြုံကို အတုယူသည့် စမ်းသပ်မှုတစ်ခုကို စတင်လိုက်ပါပြီ။ ဝန်သည် ကျွန်ုပ်တို့၏ ပျမ်းမျှနေ့စဉ်တန်ဖိုးသို့ရောက်ရှိသောအခါ၊ ကျွန်ုပ်တို့သည် အတိအကျတူညီသောစမ်းသပ်မှုကို ထပ်ခါတလဲလဲလုပ်ကာ PostgreSQL ခေါင်းဆောင်နှင့် ဥပမာတစ်ခုကို ပိတ်လိုက်ပါသည်။ အလိုအလျောက် ပျက်ကွက်မှုသည် ကျွန်ုပ်တို့ မျှော်လင့်ထားသည့်အတိုင်း လုပ်ဆောင်ခဲ့သည်- Patroni သည် ခေါင်းဆောင်ကို ပြောင်းလဲခဲ့ပြီး၊ ကောင်စစ်ဝန်ပုံစံကို PgBouncer ဖွဲ့စည်းမှုပုံစံကို မွမ်းမံပြီး ပြန်လည်စတင်ရန် အမိန့်တစ်ခု ပေးပို့ခဲ့သည်။ Grafana ရှိ ကျွန်ုပ်တို့၏ဂရပ်ဖစ်များအရ၊ စက္ကန့် 20 မှ 30 အထိ နှောင့်နှေးမှုများရှိပြီး ဒေတာဘေ့စ်နှင့်ချိတ်ဆက်မှုနှင့်ဆက်စပ်သော ဆာဗာများမှ အမှားအယွင်းအနည်းငယ်ရှိကြောင်း ထင်ရှားပါသည်။ ဤသည်မှာ ပုံမှန်အခြေအနေဖြစ်သည်၊ ထိုကဲ့သို့သောတန်ဖိုးများသည် ကျွန်ုပ်တို့၏ပျက်ကွက်မှုအတွက် လက်ခံနိုင်ဖွယ်ရှိပြီး ဝန်ဆောင်မှုစက်ရပ်ချိန်ထက် ကျိန်းသေပိုကောင်းပါသည်။

Patroni ကို ထုတ်လုပ်ရေးသို့ ယူဆောင်လာသည်။

ရလဒ်အနေဖြင့်၊ ကျွန်ုပ်တို့သည် အောက်ပါအစီအစဉ်ကို ရရှိခဲ့ပါသည်။

• PgBouncer ဆာဗာများတွင် ကောင်စစ်ဝန်ပုံစံကို အသုံးပြုပြီး စတင်လိုက်ပါ။
• PostgreSQL ဗားရှင်း 11.2 သို့ မွမ်းမံမှုများ၊
• အစုအဝေး၏အမည်ကို ပြောင်းလဲပါ။
• Patroni Cluster ကို စတင်ခြင်း။

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

လျင်မြန်စွာ ဖြန့်ကျက်ခြင်းအတွက်၊ ကျွန်ုပ်တို့သည် စမ်းသပ်မှုပတ်ဝန်းကျင်တွင် playbooks အားလုံးကို စမ်းသပ်ပြီးဖြစ်သောကြောင့်၊ ဇာတ်ညွှန်းအပြည့်အစုံ၏လုပ်ဆောင်ချိန်သည် shard တစ်ခုစီအတွက် 1,5 မှ 2 မိနစ်အထိဖြစ်သည်။ ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ဝန်ဆောင်မှုကို မရပ်တန့်ဘဲ shard တစ်ခုစီဆီသို့ အရာအားလုံးကို ထုတ်ပေးနိုင်သော်လည်း၊ ကျွန်ုပ်တို့သည် PostgreSQL တစ်ခုစီကို မိနစ်အတော်ကြာ ပိတ်ထားရမည်ဖြစ်သည်။ ဤကိစ္စတွင်၊ ဤ Shard တွင်ရှိသောဒေတာအသုံးပြုသူများသည် ယခုအချိန်တွင် အပြည့်အဝအလုပ်မလုပ်နိုင်ပါ၊ ၎င်းသည် ကျွန်ုပ်တို့အတွက် လက်မခံနိုင်ပါ။

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


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


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

Patroni အစုအဝေးကို ပြန်လည်စတင်ပါ။

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

ERROR: get_cluster
Traceback (most recent call last):
...
RetryFailedError: 'Exceeded retry deadline'
ERROR: Error communicating with DCS
<b>LOG: database system is shut down</b>

Patroni အစုအဝေးသည် ၎င်း၏အစုအဝေးအကြောင်း အချက်အလက်များကို ပြန်လည်ရယူ၍ ပြန်လည်စတင်နိုင်ခြင်းမရှိခဲ့ပါ။

ဖြေရှင်းချက်ရှာရန်၊ ကျွန်ုပ်တို့သည် Github တွင် ပြဿနာတစ်ခုမှတစ်ဆင့် Patroni စာရေးဆရာများကို ဆက်သွယ်ခဲ့သည်။ ၎င်းတို့သည် ကျွန်ုပ်တို့၏ ဖွဲ့စည်းမှုပုံစံဖိုင်များအတွက် တိုးတက်မှုများကို အကြံပြုထားသည်-

consul:
 consul.checks: []
bootstrap:
 dcs:
   retry_timeout: 8

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

ပြဿနာက မဖြေရှင်းနိုင်သေးဘူး။ အောက်ပါဖြေရှင်းနည်းများကို စမ်းသုံးကြည့်ရန် စီစဉ်ထားပါသည်။

• Patroni အစုအဝေးတစ်ခုစီတွင် ကောင်စစ်ဝန်-အေးဂျင့်ကို အသုံးပြုပါ။
• ကုဒ်တွင် ပြဿနာကို ဖြေရှင်းပါ။

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

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

Patroni အသုံးပြုခြင်း၏ရလဒ်များ

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


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

Patroni ၏အသုံးပြုမှုအသေးစိတ်အကျဉ်းချုပ်

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

source: www.habr.com