1. နိဒါန်း SQL Server မြင့်မားသောရရှိနိုင်
ရရှိနိုင်မှု မြင့်မားခြင်း SQL Server ဟာ့ဒ်ဝဲချို့ယွင်းမှုများ၊ ဆော့ဖ်ဝဲပြဿနာများ သို့မဟုတ် စီစဉ်ထားသော ပြုပြင်ထိန်းသိမ်းမှုများနှင့် ရင်ဆိုင်ရသည့်အခါ အနည်းဆုံး downtime ဖြင့် လည်ပတ်နေနိုင်သည့် စနစ်၏စွမ်းရည်ကို ရည်ညွှန်းသည်။ ရရှိနိုင်မှုမြင့်မားခြင်း၏ အရေးပါမှုကို လွန်ကဲစွာပြော၍မရပါ။ ဒေတာဘေ့စ်များ မရရှိနိုင်တော့သည့်အခါ အဖွဲ့အစည်းများသည် ဝင်ငွေဆုံးရှုံးမှု၊ ထုတ်လုပ်မှုလျော့ကျခြင်းနှင့် ဖောက်သည်မကျေနပ်မှုအပါအဝင် လက်ငင်းအကျိုးဆက်များနှင့် ရင်ဆိုင်ရလေ့ရှိသည်။
High Availability (HA) နှင့် Disaster Recovery (DR) တို့ကို မကြာခဏ အပြန်အလှန်အသုံးပြုကြသော်လည်း ၎င်းတို့သည် မတူညီသော ပျက်ကွက်မှုအခြေအနေများကို ကိုင်တွယ်ဖြေရှင်းပါသည်။ HA သည် server သို့မဟုတ် instance crash များကဲ့သို့သော ဒေသတွင်းပျက်ကွက်မှုများကြောင့် ဖြစ်ပေါ်လာသော downtime ကို လျှော့ချရန် အာရုံစိုက်ပြီး DR သည် data center သို့မဟုတ် ဒေသတစ်ခုလုံးကို သက်ရောက်မှုရှိသော ကြီးမားသောဘေးအန္တရာယ်များမှ ပြန်လည်ကောင်းမွန်လာစေရန် ဒီဇိုင်းထုတ်ထားသည်။
အရေးကြီးသော မက်ထရစ်နှစ်ခုသည် HA စီမံကိန်းရေးဆွဲခြင်းကို လမ်းညွှန်ပေးသည်-
- ပြန်လည်ကောင်းမွန်လာချိန် ရည်မှန်းချက် (RTO) သည် ချို့ယွင်းမှုတစ်ခုပြီးနောက် အများဆုံးလက်ခံနိုင်သော ရပ်တန့်ချိန်ကို သတ်မှတ်ပေးသည်
- Recovery Point Objective (RPO) သည် အများဆုံး ခံနိုင်ရည်ရှိသော ဒေတာဆုံးရှုံးမှုကို သတ်မှတ်ပေးသည်။
ရရှိနိုင်မှုကို "ကိုး" ဖြင့် တိုင်းတာလေ့ရှိသည်- ၉၉.၉% (ကိုးသုံး) သည် တစ်နှစ်လျှင် ၈.၇၆ နာရီ ရပ်နားခွင့်ပြုပြီး ၉၉.၉၉% (ကိုးလေး) သည် ၅၂.၆ မိနစ် ရပ်နားခွင့်ပြုကာ ၉၉.၉၉၉% (ကိုးငါး) သည် တစ်နှစ်လျှင် ၅.၂၆ မိနစ်သာ ရပ်နားခွင့်ပြုသည်။
2. SQL Server ရရှိနိုင်မှုမြင့်မားသော ဖြေရှင်းချက်များ ခြုံငုံသုံးသပ်ချက်
၂.၁ HA ဖြေရှင်းချက်များ၏ အမျိုးအစားများ
SQL Server ရရှိနိုင်မှုမြင့်မားသော ဖြေရှင်းချက်များကို ရှုထောင့်အမျိုးမျိုးဖြင့် အမျိုးအစားခွဲခြားနိုင်သည်-
- Instance vs database level ကာကွယ်မှုများ- Failover Cluster Instances ကဲ့သို့သော instance-level ကာကွယ်မှုများသည် database များနှင့် server object အားလုံးအပါအဝင် instance တစ်ခုလုံးကို ကာကွယ်ပေးပြီး Always On Availability Groups ကဲ့သို့သော database-level ကာကွယ်မှုများသည် သီးခြား database များကို ကာကွယ်ပေးပါသည်။
- တစ်ပြိုင်နက်တည်းဒေတာရွေ့လျားမှု vs တစ်ပြိုင်နက်တည်းဒေတာရွေ့လျားမှု- တစ်ပြိုင်နက်တည်းဒေတာရွေ့လျားမှုသည် ဒေတာဆုံးရှုံးမှု သုညကိုသေချာစေသော်လည်း နှောင့်နှေးမှုကိုဖြစ်ပေါ်စေနိုင်ပြီး၊ တစ်ပြိုင်နက်တည်းရွေ့လျားမှုသည် စွမ်းဆောင်ရည်ကို အကောင်းဆုံးဖြစ်စေသော်လည်း ဒေတာဆုံးရှုံးမှုဖြစ်နိုင်ခြေကို လက်ခံပါသည်။
- အလိုအလျောက် ချို့ယွင်းချက်နှင့် ကိုယ်တိုင် ချို့ယွင်းချက်- အလိုအလျောက် ချို့ယွင်းချက်သည် ကိုယ်တိုင် ဝင်ရောက်စွက်ဖက်ခြင်းမရှိဘဲ ချို့ယွင်းချက်ဖြစ်ပေါ်ချိန်ကို လျှော့ချပေးပြီး၊ ကိုယ်တိုင် ချို့ယွင်းချက်ဖြစ်ပေါ်ခြင်းသည် ပိုမိုကြီးမားသော ထိန်းချုပ်မှုကို ပေးစွမ်းသော်လည်း စီမံခန့်ခွဲသူ၏ အရေးယူဆောင်ရွက်မှု လိုအပ်ပါသည်။
၂.၂ ဘုံ HA ဖြေရှင်းချက်များ
SQL Server အဓိက မြင့်မားသော ရရှိနိုင်မှုရှိသော ဖြေရှင်းချက် ရှစ်ခုကို ပေးစွမ်းပြီး တစ်ခုချင်းစီသည် သီးခြား အခြေအနေများကို ကိုင်တွယ်ဖြေရှင်းပေးသည်-
- အမြဲတမ်းရရှိနိုင်မှုအဖွဲ့များ
- ပါဝင်သော ရရှိနိုင်မှုအုပ်စုများ
- ဖြန့်ဝေထားသော ရရှိနိုင်မှုအုပ်စုများ
- Failover Cluster Instances များ
- SQL Server ပွား
- သစ်တင်ပို့ခြင်း
- Database Mirroring
- စီမံခန့်ခွဲထားသော ဖြစ်ရပ်လင့်ခ်
၃။ အမြဲတမ်းရရှိနိုင်မှုအဖွဲ့များ
Always On Availability Groups သည် ကိုယ်စားပြုသည် SQL Server၏ ထိပ်တန်း ဒေတာဘေ့စ်အဆင့် မြင့်မားစွာ ရရှိနိုင်မှုနှင့် ဘေးအန္တရာယ် ပြန်လည်ထူထောင်ရေး ဖြေရှင်းချက်ကို မိတ်ဆက်ခဲ့သည် SQL Server ၂၀၁၂။ ၎င်းသည် ဒေတာဘေ့စ်အုပ်စုများကို တစ်ခုတည်းသောယူနစ်အဖြစ် အတူတကွ fail over လုပ်နိုင်စေပြီး query offloading အတွက် ဖတ်နိုင်သော secondary replicas များကို ပံ့ပိုးပေးပါသည်။
Key ကိုအင်္ဂါရပ်များ
- စုစုပေါင်းမိတ္တူ ၉ ခုအထိ ပံ့ပိုးမှု (အဓိက ၁ ခု + ဒုတိယ ၈ ခု)
- synchronous-commit mode မှာ replica ၅ ခုအထိ (primary ၁ ခု + secondary ၄ ခု)
- synchronous mode မှာ data ဆုံးရှုံးမှု လုံးဝမရှိဘဲ automatic failover လုပ်ခြင်း
- query offloading အတွက် ဖတ်နိုင်သော ဒုတိယမိတ္တူများ
- ဒုတိယမိတ္တူများသို့ အရန်ကူးယူခြင်း
- အလိုအလျောက် ချိတ်ဆက်မှု လမ်းကြောင်းသတ်မှတ်ခြင်းအတွက် Availability Group listener
- load balancing read query များအတွက် read-only routing
- ဒေတာဘေ့စ်များစွာသည် အုပ်စုတစ်ခုအနေဖြင့် အတူတကွ ပျက်ကွက်သွားခြင်း
အကောင်အထည်ဖော်ရေး အဆင့်များ
- Windows Server Failover Clustering (WSFC) သို့မဟုတ် Linux Pacemaker cluster ကို configure လုပ်ပါ။
- အားလုံးတွင် Always On Availability Groups လုပ်ဆောင်ချက်ကို ဖွင့်ပါ SQL Server ဖစ်စဉ်များ
- ဒေတာဘေ့စ်များသည် အပြည့်အဝ ပြန်လည်ရယူသည့် မော်ဒယ်ကို အသုံးပြုကြောင်းနှင့် အပြည့်အဝ အရန်ကူးယူမှုများ ရှိကြောင်း သေချာပါစေ။
- ပုံတူတစ်ခုချင်းစီတွင် database mirroring endpoint များ ဖန်တီးပါ
- Availability Group ကို ဖန်တီးပြီး database များကို ထည့်သွင်းပါ
- လိုချင်သောမုဒ်များဖြင့် မူလနှင့် ဒုတိယမိတ္တူများကို ပြင်ဆင်ပါ
- Availability Group listener ကို ဖန်တီးပြီး configure လုပ်ပါ
- ဖတ်နိုင်သော ဒုတိယအဆင့်များကို အသုံးပြုပါက ဖတ်ရန်သာ routing ကို configure လုပ်ပါ
- ပျက်ကွက်မှုလုပ်ထုံးလုပ်နည်းများကို စမ်းသပ်ပြီး အပလီကေးရှင်းချိတ်ဆက်မှုကို အတည်ပြုပါ
သည်အကောင်းဆုံး
- အများဆုံး uptime လိုအပ်သော မစ်ရှင်-အရေးကြီးသော ဒေတာဘေ့စ်များ
- ဒေသတွင်း HA နှင့် ပထဝီဝင် DR နှစ်မျိုးလုံး လိုအပ်သော အဖွဲ့အစည်းများ
- ဖတ်ရှုမှုစကေးစွမ်းရည်များ လိုအပ်သောပတ်ဝန်းကျင်များ
- အစီရင်ခံမေးမြန်းချက်များကို လျှော့ချခြင်းမှ အကျိုးကျေးဇူးရရှိသော အပလီကေးရှင်းများ
- ဒေတာဆုံးရှုံးမှု သုညကာကွယ်မှု လိုအပ်သော ဒေတာဘေ့စ်များ
- ညှိနှိုင်းထားသော failover လိုအပ်သော multi-database application များ
Pros
- synchronous-commit mode ဖြင့် ဒေတာဆုံးရှုံးမှု သုည
- အလိုအလျောက် ပျက်ကွက်မှုက ရပ်တန့်ချိန် (ပုံမှန်အားဖြင့် စက္ကန့်ပိုင်း) ကို လျှော့ချပေးသည်
- ဖတ်နိုင်သော ဒုတိယအဆင့်များသည် အဓိကပေါ်ရှိ ဝန်ကို လျှော့ချပေးသည်
- မျှဝေသိုလှောင်မှု လိုအပ်ချက် မရှိပါ
- Windows နှင့် Linux ပလက်ဖောင်းနှစ်ခုလုံးကို ပံ့ပိုးပေးသည်
- ဘေးအန္တရာယ်ပြန်လည်ထူထောင်ရေးအတွက် ပထဝီဝင်ဆိုင်ရာဖြန့်ဖြူးမှု
- အရန်ကူးယူခြင်းလုပ်ဆောင်ချက်များကို ဒုတိယအဆင့်များသို့ လွှဲပြောင်းပေးနိုင်သည်
- အပလီကေးရှင်း ချိတ်ဆက်မှု စာကြောင်းများသည် ပျက်ကွက်ပြီးနောက်တွင် မပြောင်းလဲဘဲ ရှိနေပါသည်
အားနည်းချက်များ
- လုပ်ဆောင်ချက်အပြည့်အဝအတွက် Enterprise Edition လိုအပ်ပါသည်
- Standard Edition ကို Basic AG (ဒေတာဘေ့စ် ၁ ခု၊ ဒုတိယဒေတာဘေ့စ် ၁ ခု၊ ဖတ်နိုင်သော ဒုတိယဒေတာဘေ့စ် မရှိပါ) အတွက်သာ ကန့်သတ်ထားသည်။
- ရှုပ်ထွေးသော ဖွဲ့စည်းမှုနှင့် စီမံခန့်ခွဲမှု
- clustering infrastructure (WSFC သို့မဟုတ် Pacemaker) လိုအပ်သည်
- Instance-level object များ (logins၊ jobs) သည် manual synchronization လိုအပ်သည်
- တစ်ပြိုင်နက်တည်းမုဒ်သည် ငွေပေးငွေယူနှောင့်နှေးမှုကို ဖြစ်ပေါ်စေနိုင်သည်
- ဆာဗာများစွာအတွက် လိုင်စင်ကုန်ကျစရိတ်များ
ကိုးကား
- SQL Server အမြဲတမ်းဖွင့်ထားနိုင်သော ရရှိနိုင်မှုအဖွဲ့များ- အပြည့်အစုံလမ်းညွှန်
- Microsoft တရားဝင်စာရွက်စာတမ်း- Always On ရရှိနိုင်မှုအုပ်စုများ၏ ခြုံငုံသုံးသပ်ချက် (SQL Server)
၄။ ပါဝင်သော ရရှိနိုင်မှုအုပ်စုများ
ပါဝင်သော ရရှိနိုင်မှုအုပ်စုများ၊ မိတ်ဆက်ခဲ့သည် SQL Server ၂၀၂၂ ခုနှစ်တွင်၊ instance-level object များကို replicas များတစ်လျှောက် အလိုအလျောက် synchronize လုပ်ခြင်းဖြင့် ရိုးရာ Always On Availability Groups များကို တိုးချဲ့ပြီး logins၊ jobs နှင့် အခြား server-level object များကို ကိုယ်တိုင် replicate လုပ်ရန် မလိုအပ်တော့ပါ။
Key ကိုအင်္ဂါရပ်များ
- instance-level object များ (login များ၊ user များ၊ roles များ) ကို အလိုအလျောက် ထပ်တူပြုခြင်း
- SQL Server မိတ္တူအားလုံးတွင် အေးဂျင့်အလုပ်များကို ပုံတူပွားထားသည်
- ဒေတာဘေ့စ်ခွင့်ပြုချက်များကို အလိုအလျောက် ထပ်တူပြုထားသည်
- Always On AG လုပ်ဆောင်ချက်အားလုံး ပါဝင်သည်
- ပတ်ဝန်းကျင်မိတ္တူကူးခြင်းအပြည့်အစုံဖြင့် ရိုးရှင်းသော failover
- Windows နှင့် Linux ပလက်ဖောင်းနှစ်ခုလုံးအတွက် ပံ့ပိုးမှု
အကောင်အထည်ဖော်ရေး အဆင့်များ
- သေချာစေသည SQL Server ၂၀၂၂ သို့မဟုတ် နောက်ပိုင်းတွင် အားလုံးတွင်
- WSFC သို့မဟုတ် Pacemaker cluster အခြေခံအဆောက်အအုံကို ပြင်ဆင်ပါ
- အခြေအနေအားလုံးတွင် Always On လုပ်ဆောင်ချက်ကို ဖွင့်ပါ
- CONTAINED option ဖြင့် Contained Availability Group ကို ဖန်တီးပါ
- ပါဝင်သော AG သို့ ဒေတာဘေ့စ်များထည့်ပါ
- AG ဆက်စပ်မှုအတွင်း login များနှင့် အလုပ်အကိုင်များကို ဖန်တီးပါ
- နားထောင်သူကို ပြင်ဆင်သတ်မှတ်ပြီး ပျက်ကွက်မှုကို စမ်းသပ်ပါ
သည်အကောင်းဆုံး
- AG စီမံခန့်ခွဲမှုကို ရိုးရှင်းစေလိုသော အဖွဲ့အစည်းများ
- မကြာခဏ failover စမ်းသပ်ခြင်း သို့မဟုတ် လုပ်ဆောင်ချက်များရှိသည့် ပတ်ဝန်းကျင်များ
- instance-level object များစွာ လိုအပ်သော application များ
- နယူး SQL Server ၂၀၂၂+ ဖြန့်ကျက်မှုများ
- ပျက်ကွက်ပြီးနောက် ပြင်ဆင်မှုလျှော့ချလိုသော အဖွဲ့များ
Pros
- login များနှင့် jobs များကို manual synchronization လုပ်ခြင်းကို ဖယ်ရှားပေးသည်
- ပိုမိုမြန်ဆန်ပြီး ပိုမိုယုံကြည်စိတ်ချရသော failover
- အုပ်ချုပ်ရေးပိုင်းကို လျှော့ချလိုက်တယ်။
- အပလီကေးရှင်းများသည် failover ပြုလုပ်ပြီးနောက် ချက်ချင်းအလုပ်လုပ်ပါသည်
- ရိုးရှင်းသော ဘေးအန္တရာယ် ပြန်လည်ထူထောင်ရေး လုပ်ထုံးလုပ်နည်းများ
- ရိုးရာ AG အကျိုးခံစားခွင့်အားလုံး ပါဝင်သည်
အားနည်းချက်များ
- လိုအပ်သည် SQL Server 2022 သို့မဟုတ်နောက်မှ
- လုပ်ဆောင်ချက်အပြည့်အဝအတွက် Enterprise Edition လိုအပ်ပါသည်
- ရှိပြီးသား ရိုးရာ AG များကို ပါဝင်သော AG များအဖြစ် ပြောင်းလဲ၍မရပါ။
- ပုံတူပွားအားလုံးသည် ပါဝင်သော AG အင်္ဂါရပ်ကို ပံ့ပိုးပေးရမည်။
- ရိုးရာ AG များနှင့် နှိုင်းယှဉ်ပါက အပိုရှုပ်ထွေးမှုများ
ကိုးကား
၅။ ဖြန့်ဝေထားသော ရရှိနိုင်မှုအုပ်စုများ
ဖြန့်ဝေထားသော ရရှိနိုင်မှုအုပ်စုများ၊ မိတ်ဆက်ခဲ့သည် SQL Server ၂၀၁၆ ခုနှစ်တွင်၊ အဆင့်မြင့်ဘေးအန္တရာယ်ပြန်လည်ထူထောင်ရေးနှင့် ရွှေ့ပြောင်းခြင်းအခြေအနေများအတွက် သီးခြား cluster များတစ်လျှောက်ရှိ လွတ်လပ်သော AG နှစ်ခုကို ချိတ်ဆက်ပေးသည့် “ရရှိနိုင်မှုအုပ်စုများ၏ ရရှိနိုင်မှုအုပ်စုများ” ဗိသုကာကို ဖွင့်ပါ။
Key ကိုအင်္ဂါရပ်များ
- သီးခြားရရှိနိုင်မှုအဖွဲ့နှစ်ခုကို ချိတ်ဆက်ပေးသည်
- AG တစ်ခုစီသည် ၎င်း၏ကိုယ်ပိုင် လွတ်လပ်သော cluster ကို ထိန်းသိမ်းထားသည်
- ပလက်ဖောင်းအမျိုးမျိုး ပံ့ပိုးမှု (Windows မှ Linux အထိ)
- cluster membership ကို shared မလုပ်ဘဲ cross-cluster မိတ္တူကူးခြင်း
- AG တစ်ခုက အဓိကအဖြစ်ဆောင်ရွက်ပြီး ကျန်တစ်ခုက ဒုတိယအဖြစ်ဆောင်ရွက်သည်
- synchronous နှင့် asynchronous mode နှစ်မျိုးလုံးကို ထောက်ပံ့ပေးသည်
- ဒေသများ သို့မဟုတ် တိုက်ကြီးများတွင် ပထဝီဝင်ဆိုင်ရာ ဖြန့်ဖြူးမှု
အကောင်အထည်ဖော်ရေး အဆင့်များ
- ပထမဆုံး Availability Group (primary DAG) ကို ဖန်တီးပြီး configure လုပ်ပါ။
- ဒုတိယရရှိနိုင်မှုအဖွဲ့ (ဒုတိယ DAG) ကို ဖန်တီးပြီး ပြင်ဆင်သတ်မှတ်ပါ
- AG နှစ်ခုကို ချိတ်ဆက်ပေးသော ဖြန့်ဝေထားသော AG ကို ဖန်တီးပါ
- AG များအကြား ဒေတာ ထပ်တူပြုခြင်းကို ပြင်ဆင်သတ်မှတ်ပါ
- အပလီကေးရှင်းချိတ်ဆက်မှုအတွက် AG တစ်ခုစီတွင် listener ကို စနစ်ထည့်သွင်းပါ
- ပျက်ကွက်မှုမူဝါဒများနှင့် စမ်းသပ်မှုလုပ်ထုံးလုပ်နည်းများကို ပြင်ဆင်သတ်မှတ်ပါ
- cross-cluster ဆက်သွယ်ရေးနှင့် မိတ္တူကူးခြင်းကို အတည်ပြုပါ
သည်အကောင်းဆုံး
- လွတ်လပ်သောဒေတာစင်တာများအထိ ဒေသပေါင်းစုံဘေးအန္တရာယ်ပြန်လည်ထူထောင်ရေး
- Windows မှ Linux သို့မဟုတ် Linux သို့ cross-platform ပြောင်းရွှေ့ခြင်း
- Azure နှင့် on-premise ချိတ်ဆက်သည့် Hybrid cloud scenarios များ
- ရွှေ့ပြောင်းမှုကာလ တိုးချဲ့ရန် လိုအပ်သော အဓိကဗားရှင်း အဆင့်မြှင့်တင်မှုများ
- လွတ်လပ်သော failover cluster များစွာရှိသော အဖွဲ့အစည်းများ
- တိုက်ကြီးတစ်တိုက်လုံး ဖြန့်ကျက်ထားသော ပုံတူကူးချမှုများ လိုအပ်နေသော ကမ္ဘာလုံးဆိုင်ရာ လုပ်ငန်းကြီးများ
Pros
- ဆိုက်များအကြား cluster dependency များကို ခွဲထုတ်ပါ
- ပထဝီဝင်ဆိုင်ရာ ဖြန့်ဖြူးမှုကို မှန်ကန်စွာ ဖြစ်ပေါ်စေသည်
- ပလက်ဖောင်းများစွာရှိ အခြေအနေများကို ပံ့ပိုးပေးသည်
- AG တစ်ခုစီသည် သီးခြားစီ ကျရှုံးနိုင်သည်
- ရှုပ်ထွေးသော ရွှေ့ပြောင်းမှု ပရောဂျက်များအတွက် အသင့်တော်ဆုံး
- မျှဝေထားသော cluster အခြေခံအဆောက်အအုံ မလိုအပ်ပါ
- Windows domain အမျိုးမျိုး သို့မဟုတ် Linux distribution အမျိုးမျိုးကို လွှမ်းခြုံနိုင်သည်
အားနည်းချက်များ
- Enterprise Edition လိုအပ်သည်
- ဖွဲ့စည်းမှုနှင့် စီမံခန့်ခွဲမှုတွင် ရှုပ်ထွေးမှုမြင့်မားခြင်း
- clustering နှင့် AG နည်းပညာ နှစ်မျိုးလုံးကို နက်နက်နဲနဲ နားလည်ရန် လိုအပ်သည်
- စံ AG များထက် ပြဿနာရှာဖွေရန် ပိုမိုခက်ခဲသည်
- ဒေသဖြတ်ကျော် အခြေအနေများအတွက် နောက်ထပ် နှောင့်နှေးမှု
- failover လုပ်ထုံးလုပ်နည်းများကို ဂရုတစိုက်စီစဉ်ရန် လိုအပ်သည်
ကိုးကား
၆။ Failover Cluster Instances (FCI)
Failover Cluster Instances များသည် shared storage နှင့် Windows Server Failover Clustering ကို အသုံးပြု၍ instance-level high availability ကို ပေးစွမ်းပြီး တစ်ခုလုံးကို အလိုအလျောက် failover လုပ်နိုင်သည်။ SQL Server ဒေတာဘေ့စ်များနှင့် server-level object အားလုံးအပါအဝင် instance။
Key ကိုအင်္ဂါရပ်များ
- instance-level protection (ဒေတာဘေ့စ်အားလုံး အတူတကွ fail over ဖြစ်ခြင်း)
- မျှဝေသိုလှောင်မှုဖြင့် Active-passive ဖွဲ့စည်းမှု
- ပွင့်လင်းမြင်သာသော ပျက်ကွက်မှုအတွက် Virtual Network Name (VNN)
- တက်ကြွသော node ပျက်ကွက်သည့်အခါ အလိုအလျောက် failover
- ဒေတာဆုံးရှုံးမှု လုံးဝမရှိ (ဒေတာမိတ္တူတစ်စောင်)
- ဆာဗာအဆင့် အရာဝတ္ထုများ ပါဝင်သည် (လော့ဂ်အင်များ၊ အလုပ်များ၊ ချိတ်ဆက်ထားသော ဆာဗာများ)
- အားလုံးကို ထောက်ခံပါတယ်။ SQL Server ပြန်လည်ရယူရေးမော်ဒယ်များ
အကောင်အထည်ဖော်ရေး အဆင့်များ
- Windows Server Failover Cluster (WSFC) ကို ပြင်ဆင်သတ်မှတ်ခြင်း
- မျှဝေသိုလှောင်မှု (SAN၊ SMB၊ Storage Spaces Direct) ကို စနစ်ထည့်သွင်းပါ
- cluster quorum ဆက်တင်များကို ပြင်ဆင်ပါ
- Install SQL Server ပထမဆုံး node မှာ Failover Cluster Instance အနေနဲ့
- FCI မှာ node တွေထပ်ထည့်ပါ
- Virtual Network Name နှင့် IP address ကို configure လုပ်ပါ
- cluster node များအကြား failover စမ်းသပ်ခြင်း
- VNN ကိုအသုံးပြုရန် client application များကို configure လုပ်ပါ
သည်အကောင်းဆုံး
- ရှိပြီးသား shared storage infrastructure ရှိသော အဖွဲ့အစည်းများ
- instance-level protection လိုအပ်သော ပတ်ဝန်းကျင်များ
- တစ်ခုတည်းသော ဒေတာစင်တာအတွင်း ဒေသတွင်း မြင့်မားသော ရရှိနိုင်မှု
- ဒေတာဘေ့စ်အားလုံးကို အတူတကွ fail over လုပ်ရန် လိုအပ်သော application များ
- ဆာဗာအဆင့် အရာဝတ္ထုများကို ကာကွယ်ရမည့် အခြေအနေများ
- Windows-only environments (Linux သည် FCI အတွက် မပံ့ပိုးပါ)
Pros
- ပြီးပြည့်စုံသော instance-level protection
- ဒေတာဆုံးရှုံးမှု လုံးဝမရှိဟု အာမခံပါသည်
- အလိုအလျောက် ပျက်ကွက်မှုစွမ်းရည်
- login များ သို့မဟုတ် jobs များကို synchronize လုပ်ရန် မလိုအပ်ပါ။
- ဒေတာမိတ္တူတစ်စောင်တည်းသည် သိုလှောင်မှုကုန်ကျစရိတ်ကို လျှော့ချပေးသည်
- ပြန်လည်ထူထောင်ရေး မော်ဒယ်အားလုံးကို ပံ့ပိုးပေးသည်
- ပျက်ကွက်ပြီးနောက် အပလီကေးရှင်း ချိတ်ဆက်မှု စာကြောင်းများ မပြောင်းလဲပါ
အားနည်းချက်များ
- ဈေးကြီးတဲ့ shared storage infrastructure လိုအပ်ပါတယ်
- မျှဝေသိမ်းဆည်းခြင်းသည် တစ်ခုတည်းသော ပျက်ကွက်မှုဖြစ်သည်
- ဖတ်ရှုနိုင်သော စကေးစွမ်းရည် မရှိပါ (တက်ကြွသော node တစ်ခုသာ)
- သိုလှောင်မှုကန့်သတ်ချက်များကြောင့် ပထဝီဝင်အနေအထားအရ ဖြန့်ဖြူးမှုအကန့်အသတ်ရှိသည်
- Standard Edition ကို node ၂ ခုအထိသာ ကန့်သတ်ထားသည်
- Windows တွင်သာ (Linux ပံ့ပိုးမှုမရှိပါ)
- AG များနှင့် နှိုင်းယှဉ်ပါက failover အချိန် ပိုကြာသည် (ပုံမှန်အားဖြင့် မိနစ်ပိုင်း)
- ရှုပ်ထွေးသော သိုလှောင်မှု ပုံစံနှင့် စီမံခန့်ခွဲမှု
ကိုးကား
- SQL Server Failover Cluster: DBA အတွက် လမ်းညွှန်အပြည့်အစုံ
- Microsoft တရားဝင်စာရွက်စာတမ်း- Always On failover cluster instances များ (SQL Server)
7. SQL Server ပွား
SQL Server မိတ္တူကူးခြင်းသည် ဒေတာဖြန့်ဝေမှုနည်းပညာတစ်ခုဖြစ်ပြီး ရိုးရှင်းသော တစ်လမ်းသွားဖြန့်ဝေမှုမှ ရှုပ်ထွေးသော multi-master configuration များအထိ topology အမျိုးမျိုးကို ပံ့ပိုးပေးသော်လည်း အဓိကအားဖြင့် ရရှိနိုင်မှုမြင့်မားသော ဖြေရှင်းချက်အတွက်မဟုတ်ဘဲ အစီရင်ခံရန်အတွက် အသုံးပြုသည်။
Key ကိုအင်္ဂါရပ်များ
- ပုံတူကူးခြင်း အမျိုးအစားလေးမျိုး- Snapshot၊ Transactional၊ Merge၊ Peer-to-Peer
- အသေးစိတ်ဒေတာရွေးချယ်မှု (သတ်မှတ်ထားသောဇယားများ၊ ကော်လံများ၊ အတန်းများ)
- ထုတ်ဝေသူတစ်ဦးတည်းမှ စာရင်းသွင်းသူများစွာအတွက် ပံ့ပိုးမှု
- နှစ်လမ်းသွား နှင့် မာလ်တီမာစတာ တိုပိုလော်ဂျီများ ရရှိနိုင်ပါသည်
- ပြောင်းလွယ်ပြင်လွယ်ရှိသော အချိန်ဇယားဆွဲခြင်းနှင့် ထပ်တူပြုခြင်း ရွေးချယ်စရာများ
- ပေါင်းစည်းမှုမိတ္တူကူးခြင်းအတွက် ပဋိပက္ခဖြေရှင်းခြင်း
- WHERE predicates များဖြင့် filter လုပ်နိုင်စွမ်းများ
အကောင်အထည်ဖော်ရေး အဆင့်များ
- Distributor server ကို configure လုပ်ပါ (Publisher နှင့် သီးခြား သို့မဟုတ် အတူတူ ဖြစ်နိုင်သည်)
- Publisher ဒေတာဘေ့စ်တွင် ထုတ်ဝေမှု ဖန်တီးပါ
- လိုအပ်ချက်များအပေါ် အခြေခံ၍ ပုံတူကူးခြင်းအမျိုးအစားကို ရွေးချယ်ပါ
- ပုံတူကူးရန် ဆောင်းပါးများ (ဇယားများ၊ မြင်ကွင်းများ၊ သိုလှောင်ထားသော လုပ်ထုံးလုပ်နည်းများ) ကို ရွေးချယ်ပါ
- လိုအပ်ပါက filtering နှင့် data transformation ကို configure လုပ်ပါ
- Subscriber ဒေတာဘေ့စ်များ စနစ်ထည့်သွင်းပါ
- စာရင်းသွင်းမှုများ ဖန်တီးပါ (တွန်း သို့မဟုတ် ဆွဲပါ)
- snapshot ဖြင့် စာရင်းသွင်းမှုများကို စတင်ပါ
- မိတ္တူကူးအေးဂျင့်များနှင့် နှောင့်နှေးမှုကို စောင့်ကြည့်ပါ
သည်အကောင်းဆုံး
- အစီရင်ခံဆာဗာများစွာသို့ ဒေတာများဖြန့်ဝေခြင်း
- အစီရင်ခံခြင်း လုပ်ငန်းပမာဏများပါရှိသော ဖတ်ရှုမှုအတိုင်းအတာ အခြေအနေများ
- ဝေးလံခေါင်သီသောနေရာများသို့ အချက်အလက်တစ်စိတ်တစ်ပိုင်းဖြန့်ဝေခြင်း
- အရင်းအမြစ်များစွာမှ ဒေတာစုစည်းခြင်း
- ရံဖန်ရံခါ ချိတ်ဆက်ထားသော အခြေအနေများ (merge replication)
- ဘေးအန္တရာယ်ပြန်လည်ထူထောင်ရေး မဟာဗျူဟာတွင် ပံ့ပိုးကူညီမှုအခန်းကဏ္ဍ
Pros
- ပုံတူကူးယူထားသောဒေတာအပေါ် အသေးစိတ်ထိန်းချုပ်မှု
- စာရင်းသွင်းသူများစွာကို ပံ့ပိုးပေးထားသည်
- ပြောင်းလွယ်ပြင်လွယ်ရှိသော topology ရွေးချယ်မှုများ
- သတ်မှတ်ထားသော ဇယားများ သို့မဟုတ် ကော်လံများကို ပုံတူကူးယူနိုင်သည်
- စစ်ထုတ်ခြင်းက ကွန်ရက်အသွားအလာကို လျှော့ချပေးသည်
- မတူညီသော မိတ္တူကူးခြင်းကို ပံ့ပိုးပေးသည် (SQL Server အော်ရကယ်သို့)
- Standard Edition နဲ့ အလုပ်လုပ်ပါတယ်
အားနည်းချက်များ
- အလိုအလျောက် ပျက်ကွက်မှု လုပ်ဆောင်ချက် မရှိပါ
- ရှုပ်ထွေးသော ဖွဲ့စည်းမှုနှင့် စီမံခန့်ခွဲမှု
- ပုံတူကူးခြင်း ပဋိပက္ခများ (ပေါင်းစည်းခြင်းနှင့် peer-to-peer) ဖြစ်နိုင်ခြေ
- ဒေတာထပ်တူပြုခြင်းတွင် နှောင့်နှေးမှု
- Schema ပြောင်းလဲမှုများသည် ဂရုတစိုက် ညှိနှိုင်းဆောင်ရွက်ရန် လိုအပ်ပါသည်။
- အဓိက HA ဖြေရှင်းချက်အဖြစ် ဒီဇိုင်းထုတ်ထားခြင်းမဟုတ်ပါ
- ပြဿနာရှာဖွေဖြေရှင်းခြင်းသည် စိန်ခေါ်မှုတစ်ရပ် ဖြစ်နိုင်သည်
- Peer-to-Peer သည် Enterprise Edition လိုအပ်သည်
ကိုးကား
- SQL Server မိတ္တူကူးခြင်း- DBA အတွက် ပြီးမြောက်သောလမ်းညွှန်
- မိုက်ခရိုဆော့ဖ် တရားဝင်စာရွက်စာတမ်း- SQL Server ပွား
၈။ သစ်တင်ပို့ခြင်း
Log Shipping သည် အလိုအလျောက် ငွေပေးငွေယူမှတ်တမ်း အရန်ကူးယူခြင်း၊ မိတ္တူကူးခြင်းနှင့် ပြန်လည်ရယူခြင်းလုပ်ငန်းစဉ်များမှတစ်ဆင့် နွေးထွေးသော အသင့်အနေအထားဖြင့် ဘေးအန္တရာယ်ပြန်လည်ထူထောင်ရေးနှင့် မြင့်မားသောရရှိနိုင်မှုဖြေရှင်းချက်ကို ပေးစွမ်းပြီး ထပ်တူပြုထားသော ဒုတိယဒေတာဘေ့စ်များကို ထိန်းသိမ်းရန် ရိုးရှင်းပြီး ကုန်ကျစရိတ်သက်သာသော ချဉ်းကပ်မှုကို ပေးဆောင်ပါသည်။
Key ကိုအင်္ဂါရပ်များ
- SQL Agent မှတစ်ဆင့် အလိုအလျောက် အရန်ကူးယူခြင်း၊ ကူးယူခြင်းနှင့် ပြန်လည်ရယူခြင်း အလုပ်များ
- ဒုတိယဆာဗာများစွာအတွက် ပံ့ပိုးမှု
- Configure လုပ်လို့ရတဲ့ backup နဲ့ restore interval တွေ
- STANDBY မုဒ်သည် ဒုတိယအဆင့်ကို ဖတ်ရှုရန်သာ ဝင်ရောက်ခွင့်ပြုသည်။
- အမှားပြန်လည်ရယူခြင်းကာကွယ်မှုအတွက် နှောင့်နှေးသောမှတ်တမ်းပြန်လည်ရယူခြင်း
- ဗဟိုချုပ်ကိုင်မှုစောင့်ကြည့်ခြင်းအတွက် မော်နီတာဆာဗာ
- ငွေပေးငွေယူမှတ်တမ်း ချုံ့ခြင်းပံ့ပိုးမှု
အကောင်အထည်ဖော်ရေး အဆင့်များ
- မူလဒေတာဘေ့စ်သည် အပြည့်အဝပြန်လည်ရယူခြင်းပုံစံကို အသုံးပြုကြောင်း သေချာစေပါ
- မူလဒေတာဘေ့စ်၏ အပြည့်အဝ အရန်ကူးယူမှုတစ်ခု ဖန်တီးပါ
- NORECOVERY ဖြင့် ဒုတိယဆာဗာတွင် အရန်ကူးယူမှုကို ပြန်လည်ရယူပါ
- အဓိကဒေတာဘေ့စ်တွင် မှတ်တမ်းပို့ဆောင်မှုကို ပြင်ဆင်သတ်မှတ်ပါ
- ဆာဗာအားလုံး အသုံးပြုနိုင်သော မျှဝေထားသော အရန်ကူးယူမှုဖိုင်တွဲကို သတ်မှတ်ပါ
- အဓိကတွင် အရန်ကူးယူခြင်းအလုပ်အချိန်ဇယားကို ပြင်ဆင်သတ်မှတ်ပါ
- ဒုတိယအဆင့်တွင် ကူးယူခြင်းနှင့် ပြန်လည်ရယူခြင်း အလုပ်များကို စီစဉ်သတ်မှတ်ပါ
- မော်နီတာဆာဗာကို ရွေးချယ်၍ ပြင်ဆင်နိုင်သည်
- စမ်းသပ် failover လုပ်ထုံးလုပ်နည်းများ
သည်အကောင်းဆုံး
- ကုန်ကျစရိတ်သက်သာသော ဘေးအန္တရာယ်ပြန်လည်ထူထောင်ရေးဖြေရှင်းချက်များ
- Standard Edition လိုင်စင်ရရှိသော အဖွဲ့အစည်းများ
- မိနစ်ပိုင်းအတွင်း ဒေတာဆုံးရှုံးမှုကို ခံနိုင်ရည်ရှိသော အခြေအနေများ
- ကိုယ်တိုင် failover လုပ်ခြင်းဖြင့် အဆင်ပြေသောပတ်ဝန်းကျင်
- အမှားကာကွယ်မှုလိုအပ်ချက်များအတွက် ပြန်လည်ကောင်းမွန်လာမှုနှောင့်နှေးခြင်း
- STANDBY မုဒ်ကို အသုံးပြု၍ workloads များကို အစီရင်ခံခြင်း
- ရှုပ်ထွေးသော အခြေခံအဆောက်အအုံများမပါဘဲ ရိုးရှင်းသော DR လိုအပ်ချက်များ
Pros
- ရိုးရှင်းသော ဖွဲ့စည်းမှုပုံစံနှင့် လည်ပတ်မှု
- ဈေးနှုန်းသက်သာ (Standard Edition ပံ့ပိုးမှု)
- ဒုတိယဆာဗာများစွာကို ပံ့ပိုးပေးထားသည်
- ပြင်ဆင်သတ်မှတ်နိုင်သော နှောင့်နှေးမှုသည် ယုတ္တိဗေဒဆိုင်ရာ အမှားများမှ ကာကွယ်ပေးသည်
- STANDBY မုဒ်တွင် ဖတ်ရန်သာ အစီရင်ခံစာ
- ကွန်ရက်နှောင့်နှေးမှု မြင့်မားခြင်းကို သည်းခံသည်
- အဓိကဆာဗာအပေါ် အနည်းဆုံးသက်ရောက်မှု
- ကောင်းမွန်စွာတည်ထောင်ထားပြီး သက်သေပြနိုင်သောနည်းပညာ
အားနည်းချက်များ
- အလိုအလျောက် ပျက်ကွက်မှု လုပ်ဆောင်ချက် မရှိပါ
- ဒေတာဘေ့စ်တစ်ခုချင်းစီအတွက် သီးခြားစီ configure လုပ်ရမည်
- ထပ်တူပြုခြင်း နှောင့်နှေးမှု (မိနစ်မှ နာရီအထိ)
- အရန်ကူးယူချိန်ကြားကာလအပေါ်အခြေခံ၍ ဒေတာဆုံးရှုံးမှုဖြစ်နိုင်ခြေ
- ကိုယ်တိုင် failover လုပ်ခြင်းက RTO ကို တိုးစေသည်
- လိုအပ်သည် SQL Server ဆာဗာအားလုံးတွင် လုပ်ဆောင်နေသော အေးဂျင့်
- မှတ်တမ်းပြန်လည်ရယူစဉ်အတွင်း ဒုတိယဒေတာဘေ့စ်များကို ဝင်ရောက်ကြည့်ရှု၍မရပါ
- အပလီကေးရှင်းများသည် failover ပြုလုပ်ပြီးနောက် connection string ပြောင်းလဲမှုများ လိုအပ်သည်
ကိုးကား
- SQL Server သစ်တင်ပို့ခြင်း- DBA အတွက် ပြီးမြောက်သောလမ်းညွှန်
- Microsoft တရားဝင်စာရွက်စာတမ်း- သစ်တင်ပို့မှုအကြောင်း (SQL Server)
၉။ ဒေတာဘေ့စ် အတုယူခြင်း
Database Mirroring သည် ထိုအချိန်မှစ၍ မည်သည့်တိုးတက်မှုမျှ မရရှိခဲ့သည့် ရပ်ဆိုင်းထားသော database-level high availability solution တစ်ခုဖြစ်သည်။ SQL Server ၂၀၁၂ ခုနှစ်ထွက်ဗားရှင်းများဖြစ်သော်လည်း လက်ရှိဗားရှင်းများတွင် ရရှိနိုင်ဆဲဖြစ်သည်။ Microsoft သည် ဖြန့်ကျက်မှုအသစ်အားလုံးအတွက် Always On Availability Groups သို့ ပြောင်းရွှေ့ရန် အထူးအကြံပြုအပ်ပါသည်။
Key ကိုအင်္ဂါရပ်များ
- အဓိကနှင့် မှန်ဆာဗာဗိသုကာ
- အလိုအလျောက် ပျက်ကွက်မှုအတွက် ရွေးချယ်နိုင်သော သက်သေခံဆာဗာ
- လည်ပတ်မှုပုံစံနှစ်ခု- မြင့်မားသောဘေးကင်းရေးနှင့် မြင့်မားသောစွမ်းဆောင်ရည်
- တစ်ပြိုင်နက်တည်းနှင့် တစ်ပြိုင်နက်တည်း လည်ပတ်မှု ပံ့ပိုးမှု
- အလိုအလျောက်စာမျက်နှာပြုပြင်ခြင်းစွမ်းရည်
- ဒေတာဘေ့စ်အဆင့်ကာကွယ်မှု
- ဒေတာပို့လွှတ်မှုအတွက် ကုဒ်ဝှက်ခြင်းပံ့ပိုးမှု
အကောင်အထည်ဖော်ရေး အဆင့်များ
- ဒေတာဘေ့စ်ကို အပြည့်အဝ ပြန်လည်ရယူသည့် မော်ဒယ်ကို အသုံးပြုကြောင်း သေချာပါစေ
- NORECOVERY ဖြင့် full backup ဖန်တီးပြီး mirror server သို့ restore လုပ်ပါ
- principal နှင့် mirror တွင် mirroring endpoint များ ဖန်တီးပါ
- အထောက်အထားစိစစ်ခြင်းအတွက် လက်မှတ်များကို ပြင်ဆင်သတ်မှတ်ပါ
- ဆာဗာများအကြား mirroring session တစ်ခု တည်ဆောက်ပါ
- အလိုအလျောက် ပျက်ကွက်မှုအတွက် witness server ကို ရွေးချယ်၍ configure လုပ်ပါ
- လည်ပတ်မှုမုဒ်ကို သတ်မှတ်ပါ (မြင့်မားသောဘေးကင်းရေး သို့မဟုတ် မြင့်မားသောစွမ်းဆောင်ရည်)
- စမ်းသပ် failover လုပ်ထုံးလုပ်နည်းများ
သည်အကောင်းဆုံး
- Database Mirroring ကို အသုံးပြုပြီးသား Legacy စနစ်များ
- ရွှေ့ပြောင်းနိုင်သည်အထိ ရှိပြီးသား አዲስ ...
- အခြားအခြေအနေများကို အကြံပြုထားခြင်း မရှိပါ။ (အင်္ဂါရပ်ကို ရပ်ဆိုင်းလိုက်ပါပြီ)
Pros
- သက်သေပြချက်ဖြင့် မြင့်မားသောဘေးကင်းရေးမုဒ်တွင် မြန်ဆန်သော အလိုအလျောက် ချွတ်ယွင်းမှု
- မြင့်မားသော ဘေးကင်းရေးမုဒ်တွင် ဒေတာဆုံးရှုံးမှု သုည
- ပါတနာထံမှ အလိုအလျောက် စာမျက်နှာပြုပြင်ခြင်း
- တစ်ခုတည်းသော database အတွက် Availability Groups ထက် ပိုမိုရိုးရှင်းသည်
- ထုတ်လွှင့်မှုအတွက် ကုဒ်ဝှက်ခြင်းကို ပံ့ပိုးပေးသည်
- အနည်းဆုံး downtime ဖြင့် rolling upgrade များ
အားနည်းချက်များ
- ရပ်ဆိုင်းထားသည့်အချိန်မှစ၍ SQL Server ၂၀၁၂ (ဖယ်ရှားနိုင်သည်)
- ဒေတာဘေ့စ်တစ်ခုချင်းစီအတွက် ပြင်ဆင်မှုနှင့် ပျက်ကွက်မှု
- ဖတ်နိုင်သော မှန်မရှိပါ (စကေးဖတ်နိုင်စွမ်းမရှိပါ)
- ဒေတာဘေ့စ်တစ်ခုစီသည် သီးခြားစီ ပျက်ကွက်သွားသည်
- Failover ပြုလုပ်ပြီးနောက် ချိတ်ဆက်မှု စာကြောင်း အပ်ဒိတ်များ လိုအပ်ပါသည်
- ဆာဗာနှစ်ခု (အဓိကနှင့် မှန်) အထိသာ ကန့်သတ်ထားသည်
- မြှင့်တင်မှုများ သို့မဟုတ် အင်္ဂါရပ်အသစ်များ မရှိပါ
- Microsoft က Always On AG ကို ပြောင်းရွှေ့ဖို့ အကြံပြုထားပါတယ်
ကိုးကား
၁၀။ စီမံခန့်ခွဲထားသော ဖြစ်ရပ်လင့်ခ်
Managed Instance Link သည် hybrid connection တစ်ခုကို ဖန်တီးပေးသည် SQL Server နှင့် Azure SQL Managed Instance သည် distributed availability group နည်းပညာကို အသုံးပြုထားပြီး၊ disaster recovery၊ migration နှင့် cloud integration scenarios များအတွက် near real-time data replication ကို လုပ်ဆောင်နိုင်စေပါသည်။
Key ကိုအင်္ဂါရပ်များ
- ဖြန့်ဝေထားသော AG နည်းပညာကို အသုံးပြု၍ အချိန်နှင့်တပြေးညီ မိတ္တူကူးခြင်း
- တစ်လမ်းသွားမိတ္တူကူးခြင်း (SQL Server ၂၀၁၆-၂၀၁၉ အထိ Azure)
- failback ဖြင့် နှစ်လမ်းသွား မိတ္တူကူးခြင်း (SQL Server 2022+)
- လင့်ခ်တစ်ခုလျှင် ဒေတာဘေ့စ်တစ်ခု (လင့်ခ်များစွာကို ပံ့ပိုးပေးထားသည်)
- Azure SQL Managed Instance မှာ ဖတ်လို့ရတဲ့ ပုံတူတွေ
- လိုင်စင်မဲ့ passive DR ပုံတူရွေးချယ်မှု
- အနည်းဆုံး downtime ဖြင့် အွန်လိုင်း migration
အကောင်အထည်ဖော်ရေး အဆင့်များ
- ပြင်ဆင်ပါ SQL Server ပတ်ဝန်းကျင် (VPN သို့မဟုတ် ExpressRoute မှ Azure သို့)
- Azure SQL Managed Instance ကို ပြင်ဆင်သတ်မှတ်ပါ
- Always On AG လုပ်ဆောင်ချက်ကို ဖွင့်ပါ SQL Server
- ဒေတာဘေ့စ် mirroring endpoint ဖန်တီးပါ
- အကြား လက်မှတ်များ လဲလှယ်ခြင်း SQL Server နှင့် MI
- SSMS သို့မဟုတ် script များကို အသုံးပြု၍ Managed Instance Link ဖန်တီးပါ
- မိတ္တူကူးခြင်းနှင့် ထပ်တူပြုခြင်းကို အတည်ပြုပါ
- read-scale အတွက်အသုံးပြုပါက read-only routing ကို configure လုပ်ပါ
- စမ်းသပ် failover လုပ်ထုံးလုပ်နည်းများ
သည်အကောင်းဆုံး
- cloud-based secondary ဖြင့် Hybrid disaster recovery ပြုလုပ်ခြင်း
- Azure SQL Managed Instance သို့ အွန်လိုင်းပြောင်းရွှေ့ခြင်း
- Azure သို့ analytics နှင့် reporting များကို offload လုပ်ခြင်း
- Hybrid cloud မဟာဗျူဟာကို လက်ခံကျင့်သုံးနေတဲ့ အဖွဲ့အစည်းတွေ
- Azure ဝန်ဆောင်မှုပေါင်းစပ်မှု လိုအပ်သော အခြေအနေများ
- လိုင်စင်မဲ့ passive DR ဖြင့် ကုန်ကျစရိတ် အကောင်းဆုံးဖြစ်အောင် လုပ်ဆောင်ခြင်း
Pros
- အထိရောက်ဆုံးနှင့် အနည်းဆုံး downtime Azure သို့ migration လုပ်ခြင်း
- Business Critical အဆင့်သို့ စစ်မှန်သော အွန်လိုင်းပြောင်းရွှေ့ခြင်း
- နှစ်လမ်းသွား ပျက်ကွက်မှုဖြင့် SQL Server 2022 +
- လိုင်စင်မဲ့ passive DR ပုံတူသည် ကုန်ကျစရိတ်များကို လျှော့ချပေးသည်
- အပြည့်အဝ ပြောင်းရွှေ့ခြင်းမရှိဘဲ Azure ဝန်ဆောင်မှုများနှင့် ပေါင်းစပ်ခြင်း
- Azure မိတ္တူများကို အသုံးပြု၍ ဖတ်ရှုနိုင်သော စကေးစွမ်းရည်
- Azure ဘက်ခြမ်းတွင် အလိုအလျောက် အရန်ကူးယူခြင်း
- Azure ဒေသများသို့ ပထဝီဝင်ဆိုင်ရာ ဖြန့်ဖြူးမှု
အားနည်းချက်များ
- လင့်ခ်တစ်ခုလျှင် ဒေတာဘေ့စ်တစ်ခုသာ ကန့်သတ်ချက်ရှိသည်
- MI မှာ failover group တွေနဲ့ သုံးလို့မရပါဘူး
- စနစ်ဒေတာဘေ့စ်များကို ပုံတူကူးယူ၍မရပါ
- Instance-level object များသည် manual synchronization လိုအပ်သည်
- SQL Server ၂၀၁၆-၂၀၁၉ တစ်လမ်းသွားသာ (ပြန်လှည့်ခွင့်မရှိ)
- စီမံခန့်ခွဲထားသော Instance အတွက် Azure ကုန်ကျစရိတ်များ
- ကွန်ရက်ချိတ်ဆက်မှုလိုအပ်ချက်များ (VPN/ExpressRoute)
- အင်္ဂါရပ်ကန့်သတ်ချက်များ (ဖိုင်ဇယားများ၊ ဖိုင်စီးကြောင်းကို မပံ့ပိုးပါ)
ကိုးကား
၁၁။ ရရှိနိုင်မှုမြင့်မားသော ဖြေရှင်းချက်များ နှိုင်းယှဉ်ခြင်း
၁၁.၁ အင်္ဂါရပ်နှိုင်းယှဉ်ဇယား
| လက္ခဏာ | အမြဲတမ်းဖွင့်ထားသော AG | AG ပါဝင်သည် | ဖြန့်ဝေထားသော AG | FCI | ပွား | သစ်တင်ပို့ခြင်း | ထင်ဟပ်ပေးနေ | MI လင့်ခ် |
|---|---|---|---|---|---|---|---|---|
| Edition ကို | အကျိတ်/ရောဂါလက္ခဏာ | အကျိတ်/ရောဂါလက္ခဏာ | ENT | အကျိတ်/ရောဂါလက္ခဏာ | အကျိတ်/ရောဂါလက္ခဏာ | အကျိတ်/ရောဂါလက္ခဏာ | အကျိတ်/ရောဂါလက္ခဏာ | အကျိတ်/ရောဂါလက္ခဏာ |
| ကာကွယ်စောင့်ရှောက်မှုအဆင့် | ဒေတာဘေ့စ | ဒေတာဘေ့စ်+Instance | ဒေတာဘေ့စ | ဥပမာ | ဒေတာဘေ့စ်/အရာဝတ္ထုများ | ဒေတာဘေ့စ | ဒေတာဘေ့စ | ဒေတာဘေ့စ |
| ဒေတာထပ်တူပြုခြင်း | ထပ်တူပြုခြင်း/ထပ်တူပြုခြင်းမဟုတ်ခြင်း | ထပ်တူပြုခြင်း/ထပ်တူပြုခြင်းမဟုတ်ခြင်း | ထပ်တူပြုခြင်း/ထပ်တူပြုခြင်းမဟုတ်ခြင်း | shared | async | async | ထပ်တူပြုခြင်း/ထပ်တူပြုခြင်းမဟုတ်ခြင်း | async |
| အလိုအလျောက် ပျက်ကွက်ခြင်း | Yes | Yes | Yes | Yes | အဘယ်သူမျှမ | အဘယ်သူမျှမ | Yes | အဘယ်သူမျှမ |
| ဖတ်ရှုမှုစကေး | Yes | Yes | Yes | အဘယ်သူမျှမ | Yes | ကန့်သတ် | အဘယ်သူမျှမ | Yes |
| OTR | စက္ကန့် | စက္ကန့် | စက္ကန့် | မိနစ် | လက်စွဲ | လက်စွဲ | စက္ကန့် | လက်စွဲ |
| RPO | သုည/မိနစ် | သုည/မိနစ် | သုည/မိနစ် | သုည | အနည်းဆုံး | မိနစ် | သုည/မိနစ် | အနည်းဆုံး |
| ပံ့ပိုးမှုအခြေအနေ | လှုပ်ရှားသော | လှုပ်ရှားသော | လှုပ်ရှားသော | လှုပ်ရှားသော | လှုပ်ရှားသော | လှုပ်ရှားသော | ကန့်ကွက်ခံထား | လှုပ်ရှားသော |
၁၁.၂ HA ဖြေရှင်းချက်ကို ရွေးချယ်ပါ
ဖြေရှင်းချက်ကို ရွေးချယ်သည့်အခါ အောက်ပါအချက်များကို ထည့်သွင်းစဉ်းစားပါ။
- ဘတ်ဂျက်ထည့်သွင်းစဉ်းစားမှုများသည် ဖြေရှင်းချက်ရွေးချယ်မှုကို သိသိသာသာသက်ရောက်မှုရှိသည်- Enterprise Edition လိုအပ်ချက်များသည် လိုင်စင်ကုန်ကျစရိတ်များကို သက်ရောက်မှုရှိပြီး၊ အခြေခံအဆောက်အအုံလိုအပ်ချက်များသည် FCI များအတွက် စျေးကြီးသော shared storage မှ Availability Group များအတွက် commodity server များအထိ ကွဲပြားသည်။
- ရှုပ်ထွေးမှုမှာ သိသိသာသာ ကွာခြားပါသည်- Log Shipping သည် အရိုးရှင်းဆုံး အကောင်အထည်ဖော်မှုကို ပေးစွမ်းပြီး Distributed Availability Groups သည် ကျယ်ပြန့်သော ကျွမ်းကျင်မှု လိုအပ်ပါသည်။
- RTO လိုအပ်ချက်များသည် နည်းပညာရွေးချယ်မှုများကို မောင်းနှင်ပါသည်။ စက္ကန့်ပိုင်းအတွင်း downtime demand သည် Always On Availability Groups သို့မဟုတ် FCIs များကို အလိုအလျောက် failover လုပ်နိုင်သည်။ မိနစ်အနည်းငယ်သည်းခံနိုင်စွမ်းသည် Log Shipping ကဲ့သို့သော manual failover ဖြေရှင်းချက်များကို ခွင့်ပြုသည်။
- RPO လိုအပ်ချက်များသည် အညီအမျှအရေးပါသည်- သုညဒေတာဆုံးရှုံးမှုသည် တစ်ပြိုင်နက်တည်းဖြေရှင်းချက်များကို မဖြစ်မနေလိုအပ်ပြီး မိနစ်အလိုက်သည်းခံနိုင်မှုသည် Log Shipping ကိုဖြစ်စေသည်။
- အခြေခံအဆောက်အအုံ ကန့်သတ်ချက်များ၊ ဖတ်ရှုမှုအတိုင်းအတာ လိုအပ်ချက်များ၊ ပထဝီဝင်ဆိုင်ရာ ဖြန့်ဖြူးမှု လိုအပ်ချက်များနှင့် cloud hybrid အခြေအနေများအားလုံးသည် အကောင်းဆုံး ဖြေရှင်းချက် ရွေးချယ်မှုကို လွှမ်းမိုးပါသည်။
12. အကောင်းဆုံးအလေ့အကျင့်များ SQL Server မြင့်မားသောရရှိနိုင်
12.1 စီမံကိန်းနှင့် ဒီဇိုင်း
ဒေတာဘေ့စ်တစ်ခုစီအတွက် ဂရုတစိုက် RTO နှင့် RPO ခွဲခြမ်းစိတ်ဖြာမှုမှတစ်ဆင့် စီးပွားရေးလိုအပ်ချက်များကို အကဲဖြတ်ပါ။ အဆင့်မြင့်ဆုံးရွေးချယ်မှုများကို လျစ်လျူရှုမည့်အစား လိုအပ်ချက်များနှင့် ကိုက်ညီသော သင့်လျော်သောဖြေရှင်းချက်များကို ရွေးချယ်ပါ။ အလွှာလိုက်ချဉ်းကပ်မှုများကို အသုံးပြု၍ ဒေသတွင်း မြင့်မားသောရရှိနိုင်မှုနှင့် ပထဝီဝင်ဆိုင်ရာဘေးအန္တရာယ်ပြန်လည်ထူထောင်ရေး နှစ်မျိုးလုံးကို စီစဉ်ပါ။ ကွန်ရက်ပုံကြမ်းများ၊ failover လုပ်ထုံးလုပ်နည်းများနှင့် ပြန်လည်ထူထောင်ရေးလုပ်ငန်းစဉ်စာအုပ်များအပါအဝင် ဗိသုကာလက်ရာကို ပြည့်စုံစွာ မှတ်တမ်းတင်ပါ။
၁၂.၂ အကောင်အထည်ဖော်မှုလမ်းညွှန်ချက်များ
အတည်ပြုရန်အတွက် စီစဉ်ထားသော စမ်းသပ်မှုများနှင့် သရုပ်ဖော်ထားသော ပျက်ကွက်မှုများမှတစ်ဆင့် failover လုပ်ထုံးလုပ်နည်းများကို ပုံမှန်စမ်းသပ်ပါ။ SQL Server ရရှိနိုင်မှုမြင့်မားသော ဖြေရှင်းချက်များနှင့် အဖွဲ့လိုက် အသင့်ဖြစ်မှု။ ကျန်းမာရေးနှင့် စွမ်းဆောင်ရည်ကို အဆက်မပြတ် စောင့်ကြည့်ခြင်းကို အသုံးပြု၍ SQL Server၏ built-in tool များဖြစ်သည့် SQL Server အရည်အသွေး နှင့် DMV များ။ synchronization lag၊ failover events နှင့် health degradation အတွက် ပြည့်စုံသော alerting များကို configure လုပ်ပါ။ ထိန်းသိမ်းပါ SQL Server အရန်ဗျူဟာများ HA အကောင်အထည်ဖော်နေသော်လည်း၊ အရန်ကူးယူမှုများသည် ယုတ္တိဗေဒဆိုင်ရာ ပျက်စီးမှုနှင့် မတော်တဆဖျက်ခြင်းများမှ နောက်ဆုံးကာကွယ်မှုမျဉ်းအဖြစ် ဆက်လက်တည်ရှိနေသောကြောင့်ဖြစ်သည်။ စုပေါင်းအပ်ဒိတ်များ၊ လုံခြုံရေးပြင်ဆင်မှုများနှင့် firmware အပ်ဒိတ်များဖြင့် စနစ်များကို အပ်ဒိတ်လုပ်ပါ။ ပြန်လည်ရယူခြင်းနှင့် အပလီကေးရှင်းစမ်းသပ်မှုများမှတစ်ဆင့် ပြန်လည်ရယူခြင်းလုပ်ငန်းစဉ်များကို အခါအားလျော်စွာ အတည်ပြုပြီးကဲ့သို့သော အခြေအနေများကို မည်သို့ကိုင်တွယ်ရမည်ကို သိရှိပါ။ ဒေတာဘေ့စ်များသည် recovery mode တွင် ပိတ်မိနေပါသည်.
12.3 စောင့်ကြည့်ထိန်းသိမ်းခြင်း။
ကဲ့သို့သောကိရိယာများကိုအသုံးပြုပါ။ SQL Server Activity ကိုစောင့်ကြည့်, SQL Server performance ု့ကပ်ရေးနှင့် ကျန်းမာရေးစောင့်ကြည့်မှုအတွက် Dynamic Management Views များကို ကျယ်ကျယ်ပြန့်ပြန့် အသုံးပြုပြီး လုပ်ဆောင်ပါ။ DBCC စစ်ဆေးရန် ဒေတာဘေ့စ်၏ တည်တံ့မှုကို မှန်မှန်စစ်ဆေးပါ။ Availability Group ၏ ကျန်းမာရေးကို မြင်သာအောင် အကဲဖြတ်ရန်အတွက် Always On Dashboard ကို အသုံးပြုပါ။ အထူးသဖြင့် asynchronous replicas များနှင့် Log Shipping အတွက် synchronization lag ကို ဂရုတစိုက် စောင့်ကြည့်ပါ။ failover events များကို အသုံးပြု၍ ဂရုတစိုက် ခြေရာခံပါ SQL Server တိုးချဲ့ပွဲများ ပုံစံများအတွက် အကြောင်းရင်းများကို ခွဲခြမ်းစိတ်ဖြာပါ။ ပုံမှန်လည်ပတ်မှုအတွက် စွမ်းဆောင်ရည်အခြေခံများကို ချမှတ်ပြီး အလားအလာရှိသော ပြဿနာများကို ညွှန်ပြသည့် သွေဖည်မှုများကို စောင့်ကြည့်ပါ။ အခြေခံအဆောက်အအုံသည် ကြီးထွားလာသော အလုပ်ပမာဏကို ပံ့ပိုးပေးကြောင်း သေချာစေရန် ပုံမှန်စွမ်းရည်စီမံကိန်းရေးဆွဲခြင်း ပြန်လည်သုံးသပ်မှုများ ပြုလုပ်ပါ။
13 ။ အမြဲမေးလေ့ရှိသောမေးခွန်းများ
မေး- မြင့်မားသောရရှိနိုင်မှုနှင့် ဘေးအန္တရာယ်ပြန်လည်ထူထောင်ရေးအကြား ကွာခြားချက်ကား အဘယ်နည်း။ SQL Server?
A: ရရှိနိုင်မှုမြင့်မားခြင်းသည် ဒေတာစင်တာအတွင်းရှိ ဒေသတွင်းချို့ယွင်းမှုများအတွက် downtime ကို လျှော့ချပေးပြီး အလိုအလျောက် failover နှင့် RTO များကို စက္ကန့် သို့မဟုတ် မိနစ်အတွင်း လုပ်ဆောင်ပေးပါသည်။ ဘေးအန္တရာယ်ပြန်လည်ထူထောင်ရေးသည် ဒေသတွင်းဘေးအန္တရာယ်များမှ ကာကွယ်ပေးပြီး များသောအားဖြင့် manual failover နှင့် ပိုရှည်သော RTO များဖြင့် လုပ်ဆောင်ပေးသော်လည်း အဆောက်အအုံတစ်ခုလုံးကို ထိခိုက်စေသော ဖြစ်ရပ်များကို လွှမ်းခြုံထားပါသည်။
မေး- High Availability (HA) နှင့် Read-Scale Solutions တို့၏ ကွာခြားချက်ကား အဘယ်နည်း။
A: High Availability solutions များသည် ပျက်ကွက်မှုများအတွင်း database များကို ဝင်ရောက်အသုံးပြုနိုင်စေရန် သေချာစေပြီး uptime နှင့် automatic failover စွမ်းရည်များကို အဓိကထားသည်။ Read-Scale solutions များသည် database replicas များစွာတွင် read-only workloads များကို ဖြန့်ဝေခြင်းဖြင့် query စွမ်းဆောင်ရည်ကို တိုးတက်စေပြီး throughput နှင့် response time များကို အဓိကထားသည်။ ၎င်းတို့သည် မတူညီသော ရည်ရွယ်ချက်များကို ဆောင်ရွက်ပေးသော်လည်း Always On Availability Groups ကဲ့သို့သော နည်းပညာတစ်ခုတည်းသည် အကျိုးကျေးဇူးနှစ်မျိုးလုံးကို တစ်ပြိုင်နက်တည်း ပေးစွမ်းနိုင်သည်- readable secondary replicas များသည် read-scale စွမ်းရည်များကို ပေးစွမ်းသည့်အပြင် high availability အတွက် failover targets များအဖြစ်လည်း ဆောင်ရွက်ပေးပါသည်။
Q: ဘယ်ဟာလဲ။ SQL Server ရရှိနိုင်မှုမြင့်မားတဲ့ ဖြေရှင်းချက်က ကျွန်တော့်လိုအပ်ချက်တွေအတွက် အကောင်းဆုံးလား။
A: အကောင်းဆုံးဖြေရှင်းချက်သည် RTO နှင့် RPO ပစ်မှတ်များ၊ ဘတ်ဂျက်၊ ထုတ်ဝေမှုရရှိနိုင်မှု၊ အခြေခံအဆောက်အအုံနှင့် ကျွမ်းကျင်မှုတို့ပေါ်တွင် မူတည်ပါသည်။ Always On Availability Groups သည် enterprise အခြေအနေအများစုနှင့် ကိုက်ညီပြီး Log Shipping သည် ကုန်ကျစရိတ်ထိခိုက်လွယ်သောပတ်ဝန်းကျင်များအတွက် ကောင်းစွာအလုပ်လုပ်ပါသည်။ လိုအပ်ချက်များကို နှိုင်းယှဉ်ဇယားနှင့် အကဲဖြတ်ပါ။
မေး- Always On Availability Groups သည် Enterprise Edition လိုအပ်ပါသလား။
A: Standard Edition သည် Basic Availability Groups ကို သိသာထင်ရှားသော ကန့်သတ်ချက်များဖြင့် ပံ့ပိုးပေးသည်- အုပ်စုတစ်ခုလျှင် database တစ်ခု၊ ဒုတိယမိတ္တူတစ်ခုနှင့် ဖတ်နိုင်သော ဒုတိယမိတ္တူ မရှိပါ။ ဒေတာဘေ့စ်များစွာ၊ ဒုတိယမိတ္တူရှစ်ခုနှင့် ဖတ်နိုင်သောမိတ္တူများ အပါအဝင် လုပ်ဆောင်ချက်အပြည့်အစုံအတွက် Enterprise Edition လိုအပ်ပါသည်။
မေး- Log Shipping ကို အသုံးပြုလို့ရပါသလား။ SQL Server စံထုတ်ဝေမှုလား။
A: ဟုတ်ကဲ့၊ Log Shipping ကို Standard Edition တွင် အပြည့်အဝ ပံ့ပိုးပေးထားသောကြောင့် Enterprise Edition လိုင်စင်မရှိသော အဖွဲ့အစည်းများအတွက် ဆွဲဆောင်မှုရှိသော ကုန်ကျစရိတ်သက်သာသော ဘေးအန္တရာယ်ပြန်လည်ထူထောင်ရေးဖြေရှင်းချက်တစ်ခု ဖြစ်စေပါသည်။
မေး- Always On Availability Groups နဲ့ Database Mirroring ရဲ့ ကွာခြားချက်က ဘာလဲ။
A: Database Mirroring ကို ရပ်ဆိုင်းထားပြီး ဖတ်ရှုနိုင်သော ဒုတိယဝင်ရောက်ခွင့်မရှိဘဲ တစ်ဦးချင်းဒေတာဘေ့စ်အဆင့်တွင် လုပ်ဆောင်ပါသည်။ Always On Availability Groups သည် ဒေတာဘေ့စ်အုပ်စုများ၊ ဒုတိယရှစ်ခုအထိ၊ ဖတ်ရှုနိုင်သောမိတ္တူများနှင့် မြှင့်တင်ထားသောစောင့်ကြည့်ခြင်းကို ပံ့ပိုးပေးပါသည်။ Microsoft သည် Always On သို့ ပြောင်းရွှေ့ရန် အကြံပြုထားသည်။
မေး- Failover Cluster Instances နှင့် Availability Groups အကြား မည်သို့ရွေးချယ်ရမည်နည်း။
A: shared storage infrastructure ပါရှိသော instance-level protection အတွက် FCI များကို ရွေးချယ်ပါ။ database-level protection၊ read-scale capabilities နှင့် shared storage မပါဘဲ geographic distribution အတွက် Availability Groups များကို ရွေးချယ်ပါ။ အဖွဲ့အစည်းများသည် ပြည့်စုံသောကာကွယ်မှုအတွက် နှစ်မျိုးလုံးကို ပေါင်းစပ်အသုံးပြုလေ့ရှိသည်။
မေး- အများကြီး ပေါင်းစပ်လို့ရလား SQL Server ရရှိနိုင်မှုမြင့်မားသော ဖြေရှင်းချက်များလား။
A: ဟုတ်ကဲ့၊ ဖြေရှင်းချက်များကို ပေါင်းစပ်အသုံးပြုခြင်းသည် အဖြစ်များပါသည်။ FCI များသည် Availability Group မိတ္တူများအဖြစ် ဆောင်ရွက်နိုင်ပြီး instance-level local HA နှင့် database-level geographic DR များကို ပံ့ပိုးပေးနိုင်ပါသည်။ Log Shipping သည် နောက်ထပ် အဝေးထိန်းကာကွယ်မှုအတွက် Availability Group များကို ဖြည့်စွက်ပေးနိုင်ပါသည်။ ပေါင်းစပ်ထားသော configure များကို သေချာစွာ စမ်းသပ်ပါ။
မေး- synchronous နှင့် asynchronous replication တို့၏ ကွာခြားချက်ကား အဘယ်နည်း။
A: synchronous replication သည် commit မလုပ်မီ secondary acknowledgement ကို စောင့်ပြီး data loss လုံးဝမရှိကြောင်း အာမခံသော်လည်း latency ကို ဖြစ်ပေါ်စေနိုင်သည်။ Asynchronous replication သည် စောင့်ဆိုင်းခြင်းမရှိဘဲ ဆက်လက်လုပ်ဆောင်ပြီး စွမ်းဆောင်ရည်ကို အကောင်းဆုံးဖြစ်အောင် ပြုလုပ်ပေးသော်လည်း failover လုပ်နေစဉ်အတွင်း data loss ဖြစ်နိုင်ခြေကို ဖြစ်ပေါ်စေသည်။
မေး- အရန်ကူးယူမှုများ ရှိပါက ကျွန်ုပ် အရန်ကူးယူရန် လိုအပ်ပါသေးပါသလား။ SQL Server ရရှိနိုင်မှု မြင့်မားစွာ ပြင်ဆင်ထားပါသလား။
A: လုံးဝဟုတ်ကဲ့။ ရရှိနိုင်မှုမြင့်မားခြင်းသည် ဟာ့ဒ်ဝဲချို့ယွင်းမှုများကို ကာကွယ်ပေးသော်လည်း ယုတ္တိဗေဒဆိုင်ရာပျက်စီးမှု၊ မတော်တဆဖျက်ခြင်း သို့မဟုတ် မိတ္တူအားလုံးသို့ ပုံတူပွားသည့် အန္တရာယ်ရှိသောလုပ်ဆောင်ချက်များမှ ကာကွယ်နိုင်မည်မဟုတ်ပါ။ အရန်ကူးယူမှုများသည် အချိန်နှင့်တပြေးညီ ပြန်လည်ရယူခြင်းနှင့် လိုက်နာမှုလိုအပ်ချက်များအတွက် မရှိမဖြစ်လိုအပ်နေဆဲဖြစ်သည်။
မေး- အရန်ကူးယူမှုများ ရှိပါက ကျွန်ုပ် အရန်ကူးယူရန် လိုအပ်ပါသေးပါသလား။ SQL Server ရရှိနိုင်မှု မြင့်မားစွာ ပြင်ဆင်ထားပါသလား။
A: လုံးဝဟုတ်ကဲ့။ ရရှိနိုင်မှုမြင့်မားခြင်းသည် ဟာ့ဒ်ဝဲချို့ယွင်းမှုများကို ကာကွယ်ပေးသော်လည်း ဒေတာဘေ့စ်ပျက်စီးခြင်း၊ မတော်တဆဖျက်ခြင်း သို့မဟုတ် မကောင်းသောလုပ်ဆောင်ချက်များမှ ကာကွယ်နိုင်မည်မဟုတ်ပါ။ အရန်ကူးယူမှုများသည် အချိန်နှင့်တပြေးညီ ပြန်လည်ရယူခြင်းနှင့် လိုက်နာမှုလိုအပ်ချက်များအတွက် မရှိမဖြစ်လိုအပ်ပါသည်။ ဒေတာဘေ့စ်ဖိုင်များ ပျက်စီးသွားခြင်းနှင့် အရန်ကူးယူမှုများ ရရှိနိုင်ခြင်းမရှိခြင်း သို့မဟုတ် ပျက်စီးသွားခြင်းကဲ့သို့သောကိစ္စများတွင် အထူးပြုထားသည် SQL ဒေတာဘေ့စ်ပြုပြင်ရေးဆော့ဖ်ဝဲ ပျက်စီးနေသော MDF၊ NDF နှင့် အရန်ကူးယူထားသောဖိုင်များမှ ဒေတာများကို ပြန်လည်ရယူရန် ကူညီပေးနိုင်ပါသည်။
မေး- Contained Availability Group ဆိုတာ ဘာလဲ။ ပုံမှန် Availability Group နဲ့ ဘယ်လိုကွာခြားလဲ။
A: ပါဝင်သော ရရှိနိုင်မှုအုပ်စုများ၊ မိတ်ဆက်ထားသည် SQL Server ၂၀၂၂ ခုနှစ်တွင်၊ logins၊ jobs နှင့် metadata ကဲ့သို့သော instance-level object များကို အလိုအလျောက် synchronize လုပ်ပေးပါသည်။ Regular Availability Groups သည် database object များကိုသာ synchronize လုပ်ပေးပြီး instance object များကို ကိုယ်တိုင်မိတ္တူကူးရန် လိုအပ်ပါသည်။
မေး- ဒေတာကို ပုံတူကူးယူလို့ရပါသလား SQL Server Azure SQL Managed Instance ကိုသုံးမလား။
A: ဟုတ်ကဲ့၊ Managed Instance Link သည် အောက်ပါတို့အကြား hybrid replication ကို ပံ့ပိုးပေးသည် SQL Server နှင့် Azure။ SQL Server ၂၀၁၆-၂၀၁၉ သည် တစ်လမ်းသွား မိတ္တူကူးခြင်းကို ပံ့ပိုးပေးသည်၊ SQL Server ၂၀၂၂+ သည် ဘေးအန္တရာယ်ပြန်လည်ထူထောင်ရေး၊ ရွှေ့ပြောင်းခြင်းနှင့် hybrid အခြေအနေများအတွက် failback ဖြင့် နှစ်လမ်းသွားမိတ္တူကူးခြင်းကို လုပ်ဆောင်နိုင်စေပါသည်။
မေး။ ဘာဖြစ်သွားလဲ SQL Server failover လုပ်နေစဉ်အတွင်း Agent အလုပ်တွေလား။
A: ရိုးရာ Availability Groups များဖြင့်၊ အလုပ်များကို ဒုတိယမိတ္တူများတွင် ကိုယ်တိုင်ဖန်တီးရမည်။ ပါဝင်သော Availability Groups (SQL Server ၂၀၂၂+) အလုပ်များကို အလိုအလျောက် ထပ်တူပြုပါ။ Failover Cluster Instances များတွင် instance-level protection ၏ တစ်စိတ်တစ်ပိုင်းအဖြစ် အလုပ်များ ပါဝင်သည်။
14 ။ ကောက်ချက်
SQL Server ဌာနဆိုင်ရာဒေတာဘေ့စ်များမှသည် မစ်ရှင်အရေးကြီးသော လုပ်ငန်းစနစ်များအထိ မတူညီသောလိုအပ်ချက်များကို ကိုင်တွယ်ဖြေရှင်းပေးသည့် ပြည့်စုံသော မြင့်မားသောရရှိနိုင်မှုဖြေရှင်းချက်များကို ပံ့ပိုးပေးပါသည်။ ဖြေရှင်းချက်တစ်ခုစီသည် ဒေတာဘေ့စ်စီမံခန့်ခွဲသူများအနေဖြင့် အသိပေးဆုံးဖြတ်ချက်များအတွက် နားလည်ရမည့် မတူညီသောစွမ်းရည်များနှင့် အပေးအယူများကို ပေးဆောင်ပါသည်။
Always On Availability Groups သည် ခေတ်မီဖြန့်ကျက်မှုများအတွက် အဓိကနည်းပညာကို ကိုယ်စားပြုပြီး Contained Availability Groups သည် စီမံခန့်ခွဲမှုကို ရိုးရှင်းစေပြီး Distributed Availability Groups သည် ရှုပ်ထွေးသော cross-platform scenarios များကို ဖွင့်ပေးသည်။ Failover Cluster Instances များသည် instance-level protection လိုအပ်ချက်များကို ဆက်လက်ဖြည့်ဆည်းပေးနေပြီး Log Shipping သည် ကုန်ကျစရိတ်ထိခိုက်လွယ်သော scenarios များအတွက် သက်ဆိုင်နေဆဲဖြစ်သည်။ Managed Instance Link သည် on-premises များကို ပေါင်းကူးပေးသည့် cloud hybrid ဖြစ်နိုင်ခြေများကို ဖွင့်ပေးသည်။ SQL Server Azure နှင့်အတူ။
သီးခြားစီးပွားရေးလိုအပ်ချက်များနှင့် ကိုက်ညီသော ဖြေရှင်းချက်များကို ကိုက်ညီစေခြင်းသည် အရေးကြီးသော အောင်မြင်မှုအချက်ကို ကိုယ်စားပြုသည်။ တစ်ခုတည်းသော ချဉ်းကပ်မှုမရှိပါ။ အဖွဲ့အစည်းများသည် RTO နှင့် RPO လိုအပ်ချက်များ၊ ဘတ်ဂျက်ကန့်သတ်ချက်များ၊ အခြေခံအဆောက်အအုံစွမ်းရည်များနှင့် အုပ်ချုပ်ရေးဆိုင်ရာကျွမ်းကျင်မှုများကို ဂရုတစိုက် အကဲဖြတ်ရမည်။ မကြာခဏဆိုသလို အကောင်းဆုံးဗိသုကာလက်ရာသည် ပြီးပြည့်စုံသောကာကွယ်မှုအတွက် ဖြေရှင်းချက်များစွာကို ပေါင်းစပ်ထားသည်။ သင်၏ HA ဗျူဟာသည် ပိုမိုကျယ်ပြန့်သော cloud adoption အစီအစဉ်များနှင့် မည်သို့ကိုက်ညီသည်ကို စဉ်းစားပြီး သင်၏... SQL Server အခြေခံအဆောက်အအုံသည် သင့်လုပ်ငန်းလိုအပ်သော ယုံကြည်စိတ်ချရမှုကို ပေးစွမ်းသည်။
အာဘော်အကြောင်း
Yuan Sheng 10 နှစ်အထက်အတွေ့အကြုံရှိသောအကြီးတန်းဒေတာဘေ့စစီမံခန့်ခွဲသူ (DBA) SQL Server ပတ်ဝန်းကျင်နှင့် လုပ်ငန်းဒေတာဘေ့စ်စီမံခန့်ခွဲမှု။ သူသည် ဘဏ္ဍာရေးဝန်ဆောင်မှုများ၊ ကျန်းမာရေးစောင့်ရှောက်မှုနှင့် ကုန်ထုတ်လုပ်ငန်းအဖွဲ့အစည်းများရှိ ရာနှင့်ချီသော ဒေတာဘေ့စ်ပြန်လည်ရယူရေးအခြေအနေများကို အောင်မြင်စွာဖြေရှင်းနိုင်ခဲ့သည်။
Yuan သည် အထူးပြုသည်။ SQL Server ဒေတာဘေ့စ်ပြန်လည်ရယူခြင်း၊ မြင့်မားသောရရှိနိုင်မှုဖြေရှင်းချက်များနှင့် စွမ်းဆောင်ရည် ပိုမိုကောင်းမွန်အောင်ပြုလုပ်ခြင်း။ ၎င်း၏ကျယ်ပြန့်သောလက်တွေ့အတွေ့အကြုံတွင် multi-terabyte ဒေတာဘေ့စ်များကိုစီမံခန့်ခွဲခြင်း၊ Always On Availability Groups များကိုအကောင်အထည်ဖော်ခြင်းနှင့် မစ်ရှင်အရေးပါသောစီးပွားရေးစနစ်များအတွက် အလိုအလျောက်အရန်ကူးခြင်းနှင့် ပြန်လည်ရယူခြင်းမဟာဗျူဟာများ ဖော်ဆောင်ခြင်းတို့ပါဝင်သည်။
သူ၏ နည်းပညာကျွမ်းကျင်မှုနှင့် လက်တွေ့ကျသောချဉ်းကပ်မှုမှတစ်ဆင့် Yuan သည် ဒေတာဘေ့စ်စီမံခန့်ခွဲသူများနှင့် အိုင်တီပညာရှင်များ၏ရှုပ်ထွေးမှုကို ဖြေရှင်းရာတွင် အထောက်အကူဖြစ်စေမည့် ပြည့်စုံသောလမ်းညွှန်ချက်များကို ဖန်တီးရန် အာရုံစိုက်ထားသည်။ SQL Server စိန်ခေါ်မှုများကို ထိထိရောက်ရောက် သူသည် နောက်ဆုံးပေါ်နှင့် လက်ရှိရှိနေပါသည်။ SQL Server ထုတ်ဝေမှုများနှင့် Microsoft ၏ တိုးတက်ပြောင်းလဲနေသော ဒေတာဘေ့စ်နည်းပညာများ၊ သူ၏ အကြံပြုချက်များသည် လက်တွေ့ကမ္ဘာ၏ အကောင်းဆုံးအလေ့အကျင့်များကို ထင်ဟပ်ကြောင်း သေချာစေရန် ပြန်လည်ရယူခြင်းဆိုင်ရာ အခြေအနေများကို ပုံမှန်စမ်းသပ်နေသည်။
နှင့်ပတ်သက်သောမေးခွန်းများရှိသည်။ SQL Server ပြန်လည်ရယူခြင်း သို့မဟုတ် နောက်ထပ်ဒေတာဘေ့စ်ပြဿနာဖြေရှင်းခြင်းလမ်းညွှန်ချက် လိုအပ်ပါသလား။ ယွမ်က ကြိုဆိုပါတယ်။ အကြံပြုချက်များနှင့် အကြံပြုချက်များ ဤနည်းပညာဆိုင်ရာ အရင်းအမြစ်များ တိုးတက်စေရန်။