“အခမဲ့” PostgreSQL ကို ကြမ်းတမ်းသော လုပ်ငန်းပတ်ဝန်းကျင်တွင် မည်သို့ အံဝင်ခွင်ကျလုပ်မည်နည်း။

လူအတော်များများသည် PostgreSQL DBMS နှင့်ရင်းနှီးကြပြီး၊ ၎င်းသည်သေးငယ်သောထည့်သွင်းမှုများဖြင့်သက်သေပြခဲ့သည်။ သို့သော်၊ ကုမ္ပဏီကြီးများနှင့် လုပ်ငန်းလိုအပ်ချက်များနှင့်ပတ်သက်လာလျှင်ပင် Open Source ဆီသို့ လမ်းကြောင်းသည် ပို၍ရှင်းလင်းလာသည်။ ဤဆောင်းပါးတွင် ကျွန်ုပ်တို့သည် Postgres ကို ကော်ပိုရိတ်ပတ်ဝန်းကျင်တွင် မည်သို့ပေါင်းစပ်ရမည်ကို ပြောပြပြီး နမူနာအဖြစ် Commvault အရန်သိမ်းစနစ်အား အသုံးပြုကာ ဤဒေတာဘေ့စ်အတွက် အရန်စနစ် (BSS) ဖန်တီးခြင်းဆိုင်ရာ ကျွန်ုပ်တို့၏အတွေ့အကြုံကို မျှဝေပါမည်။

PostgreSQL သည် ၎င်း၏တန်ဖိုးကို သက်သေပြခဲ့ပြီးဖြစ်သည် - DBMS သည် ကောင်းမွန်စွာအလုပ်လုပ်သည်၊ ၎င်းကို Alibaba နှင့် TripAdvisor ကဲ့သို့သော ခေတ်မီဒစ်ဂျစ်တယ်စီးပွားရေးလုပ်ငန်းများက အသုံးပြုကြပြီး လိုင်စင်ကြေးမရှိခြင်းကြောင့် ၎င်းကို MS SQL သို့မဟုတ် Oracle DB ကဲ့သို့သော ဘီလူးများအတွက် ဆွဲဆောင်မှုတစ်ခုဖြစ်စေသည်။ သို့သော် ကျွန်ုပ်တို့သည် လုပ်ငန်းအခင်းအကျင်းတွင် PostgreSQL အကြောင်း စတင်စဉ်းစားလာသည်နှင့်တပြိုင်နက် ကျွန်ုပ်တို့သည် တင်းကျပ်သောလိုအပ်ချက်များထံ ချက်ချင်းရောက်ရှိသွားသည်- "ဖွဲ့စည်းပုံအမှားကို သည်းခံနိုင်မှုကော။ သဘာဝဘေးဒဏ်ခံနိုင်ရည် ကျယ်ကျယ်ပြန့်ပြန့် စောင့်ကြည့်ရေးက ဘယ်မှာလဲ။ အလိုအလျောက် မိတ္တူကူးခြင်း ကကော။ တိပ်စာကြည့်တိုက်များကို တိုက်ရိုက်နှင့် ဆင့်ပွားသိုလှောင်မှုတွင် အသုံးပြုခြင်းနှင့်ပတ်သက်၍ကော။


တစ်ဖက်တွင်၊ PostgreSQL တွင် Oracle DB သို့မဟုတ် SAP Database Backup တွင် RMAN ကဲ့သို့သော "အရွယ်ရောက်ပြီးသူ" DBMS များကဲ့သို့ built-in အရန်ကိရိယာများမရှိပါ။ အခြားတစ်ဖက်တွင်၊ ကော်ပိုရိတ်အရန်စနစ်များ (Veeam၊ Veritas၊ Commvault) ၏ ပေးသွင်းသူများသည် PostgreSQL ကို ပံ့ပိုးပေးသော်လည်း၊ တကယ်တော့ ၎င်းတို့သည် သတ်မှတ်ထားသော (များသောအားဖြင့် တစ်ဦးတည်းသီးသန့်) ဖွဲ့စည်းမှုပုံစံနှင့် ကန့်သတ်ချက်အမျိုးမျိုးဖြင့်သာ လုပ်ဆောင်ပါသည်။

Barman, Wal-g, pg_probackup ကဲ့သို့သော PostgreSQL အတွက် အထူးဒီဇိုင်းထုတ်ထားသော အရန်စနစ်များသည် PostgreSQL DBMS ၏ အသေးစားတပ်ဆင်မှုများတွင် အလွန်ရေပန်းစားသည် သို့မဟုတ် IT အခင်းအကျင်း၏ အခြားဒြပ်စင်များ၏ လေးလံသော အရန်သိမ်းဆည်းမှုများ မလိုအပ်သည့်နေရာတွင် အလွန်ရေပန်းစားပါသည်။ ဥပမာအားဖြင့်၊ PostgreSQL အပြင် အခြေခံအဆောက်အဦတွင် ရုပ်ပိုင်းဆိုင်ရာနှင့် virtual ဆာဗာများ၊ OpenShift၊ Oracle၊ MariaDB၊ Cassandra စသည်ဖြင့် ပါဝင်နိုင်သည်။ ဤအရာအားလုံးကို ဘုံတူးလ်တစ်ခုဖြင့် အရန်သိမ်းရန် အကြံပြုလိုပါသည်။ PostgreSQL အတွက် သီးခြားဖြေရှင်းချက်တစ်ခုကို သီးသန့်ထည့်သွင်းခြင်းသည် မကောင်းသော အကြံဥာဏ်ဖြစ်သည်- ဒေတာများကို ဒစ်ခ်တစ်နေရာသို့ ကူးယူမည်ဖြစ်ပြီး၊ ထို့နောက် ၎င်းကို တိပ်ခွေအဖြစ် ဖယ်ရှားရန် လိုအပ်သည်။ ဤနှစ်ဆသော အရန်သိမ်းမှုသည် အရန်သိမ်းချိန်ကို တိုးစေပြီး ပြန်လည်ရယူချိန်ကိုလည်း ပိုအရေးကြီးပါသည်။

လုပ်ငန်းဖြေရှင်းချက်တစ်ခုတွင်၊ သီးသန့်အစုအဝေးတစ်ခုရှိ အချို့သော node အရေအတွက်ဖြင့် တပ်ဆင်ခြင်း၏ အရန်ကူးခြင်းကို ဖြစ်ပေါ်သည်။ ဥပမာအားဖြင့်၊ တစ်ချိန်တည်းတွင်၊ Commvault သည် Primary နှင့် Secondary ကို အချို့သော node များတွင် တင်းကြပ်စွာ သတ်မှတ်ပေးထားသည့် two-node cluster ဖြင့်သာ အလုပ်လုပ်နိုင်သည်။ အလယ်တန်းမှ မိတ္တူကူးခြင်းမှာ အကန့်အသတ်များ ရှိနေသောကြောင့် Primary မှ Backup လုပ်ခြင်းသည်သာ အဓိပ္ပါယ်ရှိပါသည်။ DBMS ၏ထူးခြားချက်များကြောင့်၊ အမှိုက်ပုံသည် Secondary တွင်ဖန်တီးထားခြင်းမဟုတ်သောကြောင့်၊ ဖိုင်အရန်ကူးယူနိုင်ခြေသာကျန်ရှိတော့သည်။

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

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

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

နောက်ဆုတ်စရာနေရာမရှိ။ မော်စကို developer များနောက်ကွယ်မှ။

သို့သော်၊ မကြာသေးမီက ကျွန်ုပ်တို့၏အဖွဲ့သည် ခက်ခဲသောစိန်ခေါ်မှုတစ်ခုကို ရင်ဆိုင်ခဲ့ရသည်- ကျွန်ုပ်တို့သည် IT အခြေခံအဆောက်အအုံကို ဖန်တီးခဲ့သည့် AIS OSAGO 2.0 ကိုဖန်တီးရန် ပရောဂျက်တွင် ဆော့ဖ်ဝဲအင်ဂျင်နီယာများသည် စနစ်သစ်အတွက် PostgreSQL ကို ရွေးချယ်ခဲ့သည်။

ဆော့ဖ်ဝဲ developer ကြီးများအတွက် “ခေတ်မှီသော” open-source solutions များကို အသုံးပြုရန် ပိုမိုလွယ်ကူသည်။ Facebook တွင် ဤ DBMS လုပ်ဆောင်ချက်ကို ပံ့ပိုးရန် ကျွမ်းကျင်သူများ အလုံအလောက်ရှိသည်။ RSA ၏အခြေအနေတွင်၊ "ဒုတိယနေ့" ၏တာဝန်များအားလုံးသည်ကျွန်ုပ်တို့၏ပခုံးပေါ်သို့ကျသွားသည်။ အမှားအယွင်းကို ခံနိုင်ရည်ရှိစေရန်၊ အစုအဝေးတစ်ခုကို စုစည်းပြီး အရန်သိမ်းခြင်းကို စနစ်ထည့်သွင်းရန် လိုအပ်ပါသည်။ လုပ်ဆောင်ချက်၏ယုတ္တိမှာ အောက်ပါအတိုင်းဖြစ်သည်။

• အစုအဝေး၏ Primary node မှ အရန်ကူးယူရန် SRK ကို သင်ပေးပါ။ ၎င်းကိုလုပ်ဆောင်ရန်၊ SRK သည် ၎င်းကိုရှာဖွေရမည် - ဆိုလိုသည်မှာ PostgreSQL အစုအဝေးစီမံခန့်ခွဲမှုဖြေရှင်းချက်တစ်ခု သို့မဟုတ် အခြားတစ်ခုနှင့် ပေါင်းစည်းရန် လိုအပ်သည်။ RSA ကိစ္စတွင်၊ Patroni ဆော့ဖ်ဝဲကို ၎င်းအတွက် အသုံးပြုခဲ့သည်။
• ဒေတာပမာဏနှင့် ပြန်လည်ရယူရေးလိုအပ်ချက်များအပေါ် အခြေခံ၍ အရန်ကူးယူမှုအမျိုးအစားကို ဆုံးဖြတ်ပါ။ ဥပမာအားဖြင့်၊ စာမျက်နှာများကို အသေးစိပ်ပြန်လည်ရယူရန် လိုအပ်သည့်အခါ၊ အမှိုက်ပုံးကို အသုံးပြုပါ၊ ဒေတာဘေ့စ်များသည် ကြီးမားပြီး အသေးစိပ်ပြန်လည်ရယူရန် မလိုအပ်ပါက၊ ဖိုင်အဆင့်တွင် လုပ်ဆောင်ပါ။
• Multi-threaded မုဒ်တွင် အရန်မိတ္တူတစ်ခုကို ဖန်တီးရန် ဖြေရှင်းချက်တွင် ပိတ်ဆို့အရန်ကူးခြင်း ဖြစ်နိုင်ခြေကို ပူးတွဲပါ။

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

စီးပွားရေးလုပ်ငန်းအတွက် မှော်ပညာလေးတစ်ခု

ထို့ကြောင့်၊ အရန်ဒေတာစင်တာတွင် တူညီသောအခြေခံအဆောက်အဦများဖြင့် တူညီသောအခြေခံအဆောက်အဦများဖြင့် 10 node အစုအဝေး 3 ခုအတွက် ယုံကြည်စိတ်ချရသောအရန်ကူးယူမှုကို အာမခံရန် လိုအပ်ပါသည်။ PostgreSQL ၏ စည်းကမ်းချက်များအရ ဒေတာစင်တာများသည် တက်ကြွသော passive နိယာမအရ လုပ်ဆောင်သည်။ စုစုပေါင်းဒေတာဘေ့စ်အရွယ်အစားမှာ 50 TB ဖြစ်သည်။ မည်သည့်ကော်ပိုရိတ်အဆင့် ထိန်းချုပ်မှုစနစ်မဆို ယင်းကို အလွယ်တကူ ရင်ဆိုင်နိုင်သည်။ သို့သော် သတိပေးချက်မှာ အစပိုင်းတွင် Postgres သည် အရန်စနစ်များနှင့် အပြည့်အ၀ နက်ရှိုင်းစွာ တွဲဖက်အသုံးပြုနိုင်ရန် သဲလွန်စမရှိပေ။ ထို့ကြောင့်၊ ကျွန်ုပ်တို့သည် PostgreSQL နှင့်တွဲဖက်၍ အစပိုင်းတွင် အမြင့်ဆုံးလုပ်ဆောင်နိုင်စွမ်းရှိသည့် အဖြေကိုရှာဖွေကာ စနစ်အား ပြန်လည်ပြင်ဆင်ရန် လိုအပ်ပါသည်။

ကျွန်ုပ်တို့သည် အတွင်းပိုင်း “hackathon” 3 ခုကို ကျင်းပခဲ့သည် - တိုးတက်မှုပေါင်း XNUMX ကျော်ကို ကြည့်ရှုခဲ့ပြီး ၎င်းတို့ကို စမ်းသပ်ပြီး၊ ကျွန်ုပ်တို့၏ ယူဆချက်များနှင့် ဆက်စပ်၍ ပြောင်းလဲမှုများ ပြုလုပ်ခဲ့ပြီး ၎င်းတို့ကို ထပ်မံစမ်းသပ်ခဲ့သည်။ ရရှိနိုင်သောရွေးချယ်မှုများကို ပြန်လည်သုံးသပ်ပြီးနောက်၊ ကျွန်ုပ်တို့သည် Commvault ကို ရွေးချယ်ခဲ့သည်။ ဤထုတ်ကုန်သည် အရိုးရှင်းဆုံး PostgreSQL အစုလိုက်အပြုံလိုက် တပ်ဆင်မှုဖြင့် လုပ်ဆောင်နိုင်ပြီး၊ ၎င်း၏ ပွင့်လင်းသော ဗိသုကာလက်ရာသည် အောင်မြင်သော ဖွံ့ဖြိုးတိုးတက်မှုနှင့် ပေါင်းစပ်မှုအတွက် (တရားမျှတသော) မျှော်လင့်ချက်များ တိုးပွားစေပါသည်။ Commvault သည် PostgreSQL မှတ်တမ်းများကို အရန်သိမ်းနိုင်သည်။ ဥပမာအားဖြင့်၊ PostgreSQL ၏စည်းကမ်းချက်များအရ Veritas NetBackup သည် အပြည့်အဝအရန်ကူးခြင်းကိုသာ ပြုလုပ်နိုင်သည်။

ဗိသုကာပညာအကြောင်း။ CommServ HA စီစဉ်သတ်မှတ်မှုတွင် ဒေတာစင်တာနှစ်ခုမှ တစ်ခုစီတွင် Commvault စီမံခန့်ခွဲမှုဆာဗာများကို ထည့်သွင်းထားသည်။ စနစ်သည် ကွန်ဆိုးလ်တစ်ခုမှတစ်ဆင့် စီမံခန့်ခွဲပြီး HA ရှုထောင့်မှ လုပ်ငန်းလိုအပ်ချက်အားလုံးကို ဖြည့်ဆည်းထားသည်။

ကျွန်ုပ်တို့သည် Fiber Channel မှတဆင့် SAN မှတဆင့် အရန်ကူးယူရန်အတွက် အထူးသီးသန့် ရည်ရွယ်ထားသော disk array များနှင့် တိပ်စာကြည့်တိုက်များကို ချိတ်ဆက်ပေးသည့် ဒေတာစင်တာတစ်ခုစီတွင် ရုပ်ပိုင်းဆိုင်ရာမီဒီယာဆာဗာနှစ်ခုကိုလည်း လွှင့်တင်ထားပါသည်။ တိုးချဲ့ထားသော ကူးယူဖော်ပြသည့် ဒေတာဘေ့စ်များသည် မီဒီယာဆာဗာများ၏ အမှားအယွင်းကို ခံနိုင်ရည်ရှိစေကြောင်းနှင့် ဆာဗာတစ်ခုစီကို CSV တစ်ခုစီသို့ ချိတ်ဆက်ခြင်းဖြင့် အစိတ်အပိုင်းတစ်ခုမှ မအောင်မြင်ပါက ဆက်တိုက်လုပ်ဆောင်မှုကို လုပ်ဆောင်နိုင်မည်ဖြစ်သည်။ ဒေတာစင်တာတစ်ခုကျသွားလျှင်ပင် စနစ်တည်ဆောက်ပုံသည် အရန်သိမ်းခြင်းကို ဆက်လက်လုပ်ဆောင်နိုင်စေသည်။

Patroni သည် အစုအဝေးတစ်ခုစီအတွက် Primary node တစ်ခုကို သတ်မှတ်သည်။ ၎င်းသည် ဒေတာစင်တာရှိ မည်သည့် အခမဲ့ node ဖြစ်နိုင်သည် - သို့သော် အများအားဖြင့်သာ။ အရန်သိမ်းဆည်းမှုတွင်၊ node များအားလုံးသည် Secondary ဖြစ်သည်။

Commvault သည် မည်သည့် cluster node သည် Primary ဖြစ်သည်ကို နားလည်ရန်အတွက် Postgres နှင့် စနစ် (ဖြေရှင်းချက်၏ ဖွင့်ထားသော ဗိသုကာလက်ရာကြောင့်) ကို ကျွန်ုပ်တို့ ပေါင်းစပ်ထားသည်။ ဤရည်ရွယ်ချက်အတွက်၊ Primary node ၏ လက်ရှိတည်နေရာကို Commvault စီမံခန့်ခွဲမှုဆာဗာသို့ အစီရင်ခံမည့် script တစ်ခုကို ဖန်တီးထားသည်။

ယေဘုယျအားဖြင့်၊ လုပ်ငန်းစဉ်သည် ဤကဲ့သို့ ဖြစ်သည်-

Patroni သည် Primary → Keepalived ကို ရွေးချယ်ပြီး IP အစုအဝေးကို ကောက်ယူပြီး ရွေးချယ်ထားသော အစုအဝေးမှ Commvault အေးဂျင့်သည် ဇာတ်ညွှန်းကို လုပ်ဆောင်သည်

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

ဖြေရှင်းချက်သည် စံနမူနာဖြစ်ဟန်မဆောင်ဘဲ ၎င်း၏ကိုယ်ပိုင် ကွဲပြားမှုများရှိသည်။ Commvault သည် ဥပမာတစ်ခုလုံးကိုသာ အရန်သိမ်းဆည်းနိုင်ပြီး ဒေတာဘေ့စ်တစ်ခုချင်းစီကို ကူးယူခြင်းမပြုနိုင်ပါ။ ထို့ကြောင့် ဒေတာဘေ့စ်တစ်ခုစီအတွက် သီးခြားဥပမာတစ်ခုကို ဖန်တီးထားသည်။ တကယ့် client များကို virtual pseudo-clients များအဖြစ် ပေါင်းစပ်ထားသည်။ Commvault pseudo-client တစ်ခုစီသည် UNIX အစုအဝေးတစ်ခုဖြစ်သည်။ Postgres အတွက် Commvault အေးဂျင့်ကို ထည့်သွင်းထားသည့် အစုအဝေးများကို ၎င်းတွင် ထည့်သွင်းထားသည်။ ရလဒ်အနေဖြင့်၊ pseudo-client ၏ virtual node အားလုံးကို ဥပမာတစ်ခုအဖြစ် အရန်သိမ်းထားသည်။

pseudo-client တစ်ခုစီအတွင်း၊ အစုအဝေး၏ တက်ကြွသော node ကို ညွှန်ပြသည်။ ၎င်းသည် Commvault အတွက် ကျွန်ုပ်တို့၏ ပေါင်းစပ်ဖြေရှင်းချက်ဟု သတ်မှတ်သည်။ ၎င်း၏လုပ်ဆောင်ချက်၏နိယာမသည်အတော်လေးရိုးရှင်းသည်- အစုအဝေး IP တစ်ခုကို node တစ်ခုပေါ်တွင်တင်ပါက၊ script သည် Commvault agent binary တွင် "active node" parameter ကိုသတ်မှတ်သည် - တကယ်တော့၊ script သည် memory ၏လိုအပ်သောအပိုင်းတွင် "1" ကိုသတ်မှတ်သည်။ . အေးဂျင့်သည် ဤဒေတာကို CommServe သို့ပို့ပြီး Commvault သည် အလိုရှိသော node မှ အရန်ကူးယူသည်။ ထို့အပြင်၊ အရန်ကူးယူခြင်းကို စတင်သောအခါ အမှားအယွင်းများကို ရှောင်ရှားရန် ကူညီပေးသည့် ဖွဲ့စည်းမှုစနစ်၏ မှန်ကန်မှုကို script အဆင့်တွင် စစ်ဆေးပါသည်။

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

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

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

လောလောဆယ်တွင် IBS သည် ကုန်ထုတ်စွမ်းအားဝန်ဆောင်မှုများကို မထိခိုက်စေသော်လည်း အခြေအနေပြောင်းလဲပါက Commvault သည် load limiting ကိုဖွင့်နိုင်သည်။

ကောင်းသလား။ ကောင်းတယ်!

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

1 နာရီနှင့် 2 နာရီများ၏ RPO နှင့် RTO ဘောင်များကို အနားသတ်ဖြင့် ဖုံးအုပ်ထားပြီး ဆိုလိုသည်မှာ စနစ်သည် သိမ်းဆည်းထားသည့် ဒေတာပမာဏ သိသိသာသာ တိုးလာသည့်တိုင် ၎င်းတို့ကို လိုက်နာနိုင်မည်ဖြစ်သည်။ သံသယများစွာနှင့်ဆန့်ကျင်ဘက် PostgreSQL နှင့် လုပ်ငန်းပတ်ဝန်းကျင်သည် အတော်လေးသဟဇာတဖြစ်ခဲ့သည်။ ယခု ကျွန်ုပ်တို့သည် ထိုကဲ့သို့သော DBMS များအတွက် မိတ္တူကူးယူခြင်းကို ပုံစံအမျိုးမျိုးဖြင့် ပြုလုပ်နိုင်သည်ကို ကျွန်ုပ်တို့၏ကိုယ်ပိုင်အတွေ့အကြုံမှ သိရှိပါသည်။

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

ကော်ပိုရိတ်ပတ်ဝန်းကျင်တွင် PostgreSQL နှင့်အလုပ်လုပ်ရန် သင်ကြိုးစားဖူးပါသလား။

စာရေးသူများ -

ဒေတာသိုလှောင်မှုစနစ်၊ Jet Infosystems ၏ ဒီဇိုင်းအင်ဂျင်နီယာ Oleg Lavrenov

Jet Infosystems မှ ကွန်ပျူတာစနစ်များ၏ ဒီဇိုင်းအင်ဂျင်နီယာ Dmitry Erykin

source: www.habr.com