SQL Server အမြဲတမ်းဖွင့်ထားနိုင်သော ရရှိနိုင်မှုအဖွဲ့များ [၂၀၂၆ လမ်းညွှန်]

Always On Availability Groups (AG) သည် SQL Server စီးပွားရေးလုပ်ငန်း မြင့်မားသောရရှိနိုင်မှု နှင့် ဒေတာဘေ့စ်အဆင့်တွင် လုပ်ဆောင်သော ဘေးအန္တရာယ်ပြန်လည်ထူထောင်ရေးဖြေရှင်းချက်။ ရရှိနိုင်မှုအုပ်စုတစ်ခုသည် အသုံးပြုသူဒေတာဘေ့စ်တစ်ခု သို့မဟုတ် တစ်ခုထက်ပိုသော ဒေတာဘေ့စ်များကို တစ်ခုတည်းသော failover unit တစ်ခုအဖြစ် အုပ်စုဖွဲ့ပြီး စဉ်ဆက်မပြတ် transaction log shipping မှတစ်ဆင့် ဒုတိယမိတ္တူရှစ်ခုအထိ ပုံတူကူးယူပေးသည်။ အဓိကမိတ္တူပျက်ကွက်သောအခါ၊ သတ်မှတ်ထားသော synchronous ဒုတိယမိတ္တူသည် အလိုအလျောက်လွှဲပြောင်းယူပြီး shared storage သို့မဟုတ် manual intervention မပါဘဲ စက္ကန့်ပိုင်းအတွင်း ဝင်ရောက်ခွင့်ကို ပြန်လည်ရယူသည်။

၁.၂ Always On Availability Groups နှင့် Failover Cluster Instances များ

SQL Server Always On တွင် ကွဲပြားသော နည်းပညာနှစ်ခု ပါဝင်သည်- Availability Groups (AG) နှင့် Failover Cluster Instances (FCI)။

	အမြဲတမ်းရရှိနိုင်မှုအဖွဲ့များ	အမြဲတမ်းဖွင့်ထားသော Failover Cluster Instances များ
ပျက်ကွက်မှုအတိုင်းအတာ	ဒေတာဘေ့စ်အဆင့်	Instance-level (ဒေတာဘေ့စ်အားလုံး အတူတကွ fail over ဖြစ်ခြင်း)
ဒေတာ ကူးယူခြင်း	ဒုတိယအဆင့်တစ်ခုစီသို့ Log-based မိတ္တူကူးခြင်း	မရှိပါ — node အားလုံးသည် သိုလှောင်မှုတစ်ခုတည်းကို မျှဝေကြသည်
မျှဝေထားသော သိုလှောင်မှု	မလိုအပ်ဘူး	လိုအပ်သည် (Storage Area Network (SAN)၊ iSCSI၊ S2D သို့မဟုတ် SMB)
ဖတ်နိုင်သော ဒုတိယစာများ	Yes	အဘယ်သူမျှမ
သဘာဝဘေးပြန်လည်နာလန်ထူ	တပ်ဆင်ပြီးသား (ဆိုက်များတစ်လျှောက်တွင် တစ်ပြိုင်နက်တည်းမိတ္တူကူးခြင်း)	AG နှင့် တွဲဖက်မပါဝင်ပါက built-in မပါဝင်ပါ။

တစ်ခုချင်းစီကို ဘယ်အချိန်မှာ အသုံးပြုရမလဲ- instance-level failover လိုအပ်ပြီး shared storage infrastructure ရှိပြီးသားဖြစ်တဲ့အခါ FCI ကိုသုံးပါ။ database-level granularity၊ readable secondary တွေ ဒါမှမဟုတ် disaster recovery လိုအပ်တဲ့အခါ AG ကိုသုံးပါ။ အပြည့်စုံဆုံးကာကွယ်မှုအတွက် နှစ်ခုလုံးကိုပေါင်းစပ်ပါ- replica တစ်ခုစီကို FCI node အနေနဲ့ run ပြီး AG မှာ link လုပ်ပါ။

၁.၃ အကျိုးကျေးဇူးများနှင့် ကန့်သတ်ချက်များ

အကျိုးကျေးဇူးများ:

synchronous replicas များအတွက် သုညနီးပါး Recovery Time Objective (RTO) ဖြင့် အလိုအလျောက် failover;
synchronous-commit mode တွင် ဒေတာဆုံးရှုံးမှု သုည (Recovery Point Objective (RPO) = 0)။
မျှဝေသိမ်းဆည်းရန် မလိုအပ်ပါ — ပုံတူတစ်ခုစီသည် သီးခြားဒေသခံသိမ်းဆည်းမှုကို အသုံးပြုသည်။
ဖတ်နိုင်သော ဒုတိယအဆင့်များသည် အဓိကမှ အစီရင်ခံခြင်းကို လျှော့ချပြီး အလုပ်ပမာဏများကို အရန်ကူးယူသည်။
တစ်ခုတည်းသော configuration အတွင်း local High Availability (HA) နှင့် cross-site Disaster Recovery (DR) နှစ်မျိုးလုံးကို ပံ့ပိုးပေးသည်။

ကန့်သတ်မှု:

မိတ္တူအားလုံးတွင် Windows Server Failover Clustering လိုအပ်ပါသည်။
အင်္ဂါရပ်အပြည့်အစုံအတွက် Enterprise Edition (Standard Edition သည် Basic AG ကို သိသာထင်ရှားသော ကန့်သတ်ချက်များဖြင့် ပံ့ပိုးပေးသည်)။
synchronous-commit မုဒ်သည် ကွန်ရက်သွားပြန်ချိန်နှင့် အချိုးကျသော ရေးသားလုပ်ဆောင်ချက်များအတွက် latency ကို ပေါင်းထည့်ပေးသည်။
logins များ၊ SQL Agent jobs များနှင့် ချိတ်ဆက်ထားသော server များကို အလိုအလျောက် synchronize မလုပ်ပါ။ SQL Server ၂၀၁၉ နှင့် ඊට අතරිය ... (ဖြေရှင်းပြီးသော SQL Server ၂၀၂၂ တွင် ရရှိနိုင်မှုအုပ်စုများ ပါဝင်သည်)။

၃။ အမြဲတမ်းရရှိနိုင်မှုအဖွဲ့များဗိသုကာ

၃.၁ အဓိက အစိတ်အပိုင်းများနှင့် အယူအဆများ

၃.၁.၁ ရရှိနိုင်မှုဒေတာဘေ့စ်များ

ရရှိနိုင်မှုဒေတာဘေ့စ်များသည် ရရှိနိုင်မှုအုပ်စုတွင်ပါဝင်သော အသုံးပြုသူဒေတာဘေ့စ်များဖြစ်သည်။ ဤဒေတာဘေ့စ်များသည် သတ်မှတ်ထားသောလိုအပ်ချက်များနှင့် ကိုက်ညီရမည်- ၎င်းတို့သည် full recovery model ကို အသုံးပြုရမည်ဖြစ်ပြီး၊ full backup ရှိရမည်ဖြစ်ပြီး၊ ရရှိနိုင်မှုအုပ်စုသို့ မထည့်သွင်းမီ primary replica တွင် ရှိနေရမည်။

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

၃.၁.၂ ရရှိနိုင်မှုမိတ္တူများ

ရရှိနိုင်မှုမိတ္တူများသည် SQL Server ရရှိနိုင်မှုဒေတာဘေ့စ်များ၏မိတ္တူများကို လက်ခံသိမ်းဆည်းသည့် instance များ။ ပုံတူတစ်ခုစီသည် ၎င်း၏ကိုယ်ပိုင်ဒေတာဘေ့စ်မိတ္တူကို transaction log record shipping မှတစ်ဆင့် ထပ်တူပြုထားသည်။ ရရှိနိုင်မှုအုပ်စုတစ်ခုတွင် ပုံတူကိုးခုအထိ ပါဝင်နိုင်သည်- အဓိကပုံတူတစ်ခုနှင့် ဒုတိယပုံတူရှစ်ခုအထိ။

၃.၁.၃ အဓိကမိတ္တူ

မူလမိတ္တူတွင် ရရှိနိုင်မှုဒေတာဘေ့စ်များ၏ ဖတ်ရှု-ရေးသားမိတ္တူကို သိမ်းဆည်းထားသည်။ ဒေတာပြုပြင်မွမ်းမံမှုအားလုံး (INSERT၊ UPDATE၊ DELETE) သည် မူလမိတ္တူတွင် ဖြစ်ပေါ်သည်။ Client application များသည် ရေးသားခြင်းလုပ်ဆောင်ချက်အားလုံးအတွက်နှင့် မူရင်းအားဖြင့် ဖတ်ရှုခြင်းလုပ်ဆောင်ချက်များအတွက်ပါ မူလမိတ္တူနှင့် ချိတ်ဆက်သည်။

၃.၁.၄ ဒုတိယမိတ္တူများ

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

၃.၂ ရရှိနိုင်မှုပုံစံများ

၃.၂.၁ တစ်ပြိုင်နက်တည်း-ကတိပြုမုဒ်

Synchronous-commit mode သည် primary replica အနေဖြင့် transaction log မှတ်တမ်းများကို commit မလုပ်မီ secondary replica တွင် harden လုပ်ထားကြောင်း အတည်ပြုချက်ကို စောင့်ဆိုင်းရန် လိုအပ်ခြင်းဖြင့် data loss protection ကို သုညပေးသည်။ ဤ mode သည် data loss ကို လက်မခံနိုင်သော high availability configuration များအတွက် မရှိမဖြစ်လိုအပ်သည်။

၃.၂.၂ တစ်ပြိုင်နက်တည်းမဟုတ်သော-ကတိပြုမုဒ်

Asynchronous-commit မုဒ်သည် ဒုတိယမိတ္တူများမှ log hardening ကို အသိအမှတ်ပြုရန် မစောင့်ဘဲ ငွေပေးငွေယူများကို commit လုပ်ခွင့်ပြုခြင်းဖြင့် primary replica စွမ်းဆောင်ရည်ကို ဦးစားပေးသည်။ ဤမုဒ်သည် disaster recovery replicas များအတွက် သို့မဟုတ် network latency ကြောင့် synchronous commit ကို လက်တွေ့မကျစေသည့်အခါတွင် သင့်လျော်သည်။

အပေးအယူလုပ်ရမယ့်အချက်ကတော့ failover လုပ်နေစဉ်အတွင်း ဒေတာဆုံးရှုံးမှုဖြစ်နိုင်ပါတယ်။ primary replica ပျက်ကွက်ခဲ့ရင်၊ committed transaction အချို့ဟာ secondary replica ကို မရောက်နိုင်သေးပါဘူး။ ဒေတာဆုံးရှုံးမှုပမာဏဟာ network bandwidth၊ secondary replica performance နဲ့ failure ရဲ့အချိန်ပေါ် မူတည်ပါတယ်။ asynchronous mode ကိုအသုံးပြုတဲ့အခါ အဖွဲ့အစည်းတွေဟာ ဒီအန္တရာယ်ကို လက်ခံရပါမယ်။

၃.၃ ပျက်ကွက်မှုအမျိုးအစားများ

၃.၃.၁ အလိုအလျောက် ပျက်ကွက်ခြင်း

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

ဒေတာဆုံးရှုံးမှု လုံးဝမရှိစေရန်အတွက် အလိုအလျောက် failover သည် synchronous-commit mode လိုအပ်သည်။ ဖွင့်ထားသောအခါ၊ availability group သည် primary replica ၏ အခြေအနေကို အဆက်မပြတ် စောင့်ကြည့်သည်။ primary သည် တုံ့ပြန်မှုမရှိခြင်း သို့မဟုတ် ပျက်ကွက်ပါက Windows Server Failover Cluster သည် သတ်မှတ်ထားသော secondary replica သို့ အလိုအလျောက် failover စတင်သည်။

၃.၃.၂ ကိုယ်တိုင် ပျက်ကွက်ခြင်း

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

synchronous-commit replicas များအတွက် data loss မရှိဘဲ manual failover ပြုလုပ်နိုင်ပါသည်။ administrator သည် failover ကို အောက်ပါတို့မှတစ်ဆင့် စတင်သည်- SQL Server Management Studio၊ Transact-SQL သို့မဟုတ် PowerShell။ အဓိကမိတ္တူသည် လက်ရှိငွေပေးငွေယူများကို စီမံဆောင်ရွက်ခြင်းပြီးဆုံးပြီး ကျန်ရှိနေသော မှတ်တမ်းမှတ်တမ်းအားလုံးကို ဒုတိယပစ်မှတ်ပစ်မှတ်သို့ ပေးပို့ကာ အဓိကအခန်းကဏ္ဍကို လွှဲပြောင်းခြင်းမပြုမီ အတည်ပြုချက်ကို စောင့်ဆိုင်းသည်။

asynchronous-commit replicas များတွင်လည်း manual failover ဖြစ်ပွားနိုင်သော်လည်း ၎င်းသည် ဒေတာဆုံးရှုံးမှုဖြစ်နိုင်ခြေရှိသော forced failover လိုအပ်သည်။ Administrator များသည် primary replica မရနိုင်သည့်အခါနှင့် ရှည်လျားသော downtime နှင့်နှိုင်းယှဉ်ပါက ဒေတာဆုံးရှုံးမှုကို လက်ခံနိုင်သည့် တကယ့်ဘေးအန္တရာယ်အခြေအနေများတွင်သာ forced manual failover ကို အသုံးပြုသင့်သည်။

၃.၃.၃ အတင်းအကျပ် ပျက်ကွက်ခြင်း

အတင်းအကြပ် failover လုပ်ခြင်းသည် asynchronous secondary replica သို့မဟုတ် အပြည့်အဝ synchronized မလုပ်ရသေးသော secondary replica သို့ failover လုပ်ခွင့်ပြုပြီး data ဆုံးရှုံးမှုဖြစ်နိုင်ခြေကို ရှင်းရှင်းလင်းလင်း အသိအမှတ်ပြုပါသည်။ ဤရွေးချယ်မှုသည် primary replica မရနိုင်သည့်အခါနှင့် synchronized secondary မရှိသည့်အခါ နောက်ဆုံးနည်းလမ်းအဖြစ် ဆောင်ရွက်ပါသည်။

၃.၄ ဒေတာ ထပ်တူပြုခြင်း

၃.၄.၁ ဒေတာ ထပ်တူပြုခြင်း မည်သို့အလုပ်လုပ်သည်

Always On Availability Groups များတွင် ဒေတာထပ်တူပြုခြင်းသည် အဓိကမိတ္တူမှ ဒုတိယမိတ္တူအားလုံးသို့ စဉ်ဆက်မပြတ် ငွေပေးငွေယူမှတ်တမ်းပို့ဆောင်ခြင်းမှတစ်ဆင့် ဖြစ်ပေါ်သည်။ ဤ log-based ထပ်တူပြုခြင်းသည် አዲስမိတ္တူတစ်ခုစီအတွက် သီးခြားသိုလှောင်မှုကို ခွင့်ပြုပေးစဉ် አዲስကိုက်ညီမှုကို သေချာစေသည်။

၃.၄.၂ ငွေပေးငွေယူမှတ်တမ်းများနှင့် ခိုင်မာအောင်ပြုလုပ်ခြင်း

Transaction log hardening သည် log မှတ်တမ်းများကို ဒုတိယမိတ္တူများပေါ်ရှိ တာရှည်ခံသိုလှောင်မှုသို့ ရေးသားသည့် အရေးကြီးသောအဆင့်ဖြစ်သည်။ Hardening သည် log မှတ်တမ်းများကို ဒုတိယမိတ္တူချို့ယွင်းမှုများမှ ကျော်လွှားနိုင်ပြီး ပြန်လည်ရယူစဉ်အတွင်း ပြန်လည်ဖွင့်နိုင်ကြောင်း သေချာစေသည်။

၃.၅ ဖတ်ရှုနိုင်သော စကေးနှင့် ဖတ်နိုင်သော ဒုတိယမိတ္တူများ

၃.၅.၁ Read-Only Workload များကို ဖြုတ်ချခြင်း

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

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

၃.၅.၂ ဒုတိယမိတ္တူများတွင် အရန်ကူးယူခြင်းလုပ်ဆောင်ချက်များ

ဒုတိယမိတ္တူများတွင် အရန်ကူးယူမှုများ လုပ်ဆောင်ခြင်းဖြင့် မူလမိတ္တူပေါ်ရှိ အဝင်/အထွက် (I/O) နှင့် ဗဟိုပရိုဆက်ဆာယူနစ် (CPU) ဝန်ထုပ်ဝန်ပိုးကို လျှော့ချပေးပြီး အရောင်းအဝယ်ဆိုင်ရာ အလုပ်ဝန်ထုပ်ဝန်ပိုးများကို အာရုံစိုက်နိုင်စေပါသည်။ ဤစွမ်းရည်သည် အဖွဲ့အစည်းများအား ထုတ်လုပ်မှုစွမ်းဆောင်ရည်ကို မထိခိုက်စေဘဲ အရန်ကူးယူမှုလိုအပ်ချက်များကို ဖြည့်ဆည်းရန် ကူညီပေးပါသည်။

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

အပေါ်အသေးစိတ်အတွက် SQL Server အရန်ကူးယူခြင်း၊ ကျွန်ုပ်တို့၏ ပြည့်စုံသောလမ်းညွှန်.

၃.၆ ရရှိနိုင်မှုအဖွဲ့ နားထောင်သူများ

၃.၆.၁ နားထောင်သူဆိုတာ ဘာလဲ။

Availability group listener ဆိုသည်မှာ client application များက availability group database များသို့ ချိတ်ဆက်ရန်အသုံးပြုသည့် virtual network name (VNN) နှင့် IP address တစ်ခုဖြစ်သည်။ listener သည် ချိတ်ဆက်မှုများကို လက်ရှိ primary replica သို့ အလိုအလျောက် ပြန်ညွှန်းပေးသောကြောင့် application များအနေဖြင့် လက်ရှိ primary server သည် မည်သည့် server ဖြစ်ကြောင်း ခြေရာခံရန် မလိုအပ်ပါ။

၃.၆.၂ ဖောက်သည်ချိတ်ဆက်မှုလမ်းကြောင်း

listener မှတစ်ဆင့် client ချိတ်ဆက်မှု routing သည် read-write နှင့် read-only connection intent နှစ်မျိုးလုံးကို ပံ့ပိုးပေးသည်။ listener သည် connection request ကို စစ်ဆေးပြီး application ၏ intent အပေါ်အခြေခံ၍ သင့်လျော်သော replica သို့ route လုပ်သည်။

၄။ ကြိုတင်လိုအပ်ချက်များနှင့် လိုအပ်ချက်များ

၄.၁ ရရှိနိုင်မှုအုပ်စုများအတွက် Windows Server Failover Clustering

၄.၁.၁ Windows Server Failover Clustering အခြေခံများ

Windows Server Failover Clustering (WSFC) သည် cluster membership၊ health monitoring နှင့် failover orchestration တို့ကို စီမံခန့်ခွဲခြင်းဖြင့် Always On Availability Groups အတွက် အခြေခံအုတ်မြစ်ကို ပံ့ပိုးပေးပါသည်။ Failover Cluster Instances များနှင့်မတူဘဲ၊ availability groups များသည် WSFC ကို cluster coordination အတွက်သာ အသုံးပြုပြီး shared storage management အတွက် မဟုတ်ပါ။

တစ်ခုချင်းစီကို SQL Server Availability group တွင်ပါဝင်သော instance သည် WSFC cluster ရှိ node တစ်ခုဖြစ်ရမည်။ cluster သည် quorum voting၊ node health detection နှင့် availability group resource state တို့ကို စီမံခန့်ခွဲသည်။ primary replica ပျက်ကွက်သောအခါ WSFC သည် failover လုပ်ငန်းစဉ်ကို ညှိနှိုင်းပြီး primary replica အသစ်ကို ထင်ဟပ်စေရန် cluster resources များကို အပ်ဒိတ်လုပ်သည်။

၄.၁.၂ Cluster Quorum ဖွဲ့စည်းမှု

Cluster quorum သည် ကွန်ရက်ချိတ်ဆက်မှုပြဿနာများပေါ်ပေါက်လာသည့်အခါ မည်သည့် node များလည်ပတ်နိုင်သည်ကို ဆုံးဖြတ်ပေးပြီး node များစွာသည် primary အဖြစ် သီးခြားစီပြောဆိုသည့် split-brain အခြေအနေများကို တားဆီးပေးသည်။ quorum configuration သည် cluster ဆုံးဖြတ်ချက်များအတွက် အများစုမဲကို မည်သို့သတ်မှတ်သည်ကို သတ်မှတ်ပေးသည်။

ရရှိနိုင်မှုအုပ်စုများအတွက် quorum မုဒ်များစွာ ရရှိနိုင်ပါသည်-

Node Majority သည် cluster node votes များကိုသာ အသုံးပြုပြီး node အရေအတွက် စုံသော cluster များအတွက် ကောင်းစွာ အလုပ်လုပ်သည်။
Node နှင့် File Share Majority သည် file share witness vote ကိုထည့်သွင်းပေးပြီး ၎င်းသည် စုံနံပါတ်တပ်ထားသော node cluster များအတွက် သင့်လျော်သည်။
Node နှင့် Disk Majority သည် disk witness ကို အသုံးပြုသော်လည်း shared storage မလိုအပ်သောကြောင့် availability group များအတွက် အသုံးနည်းပါသည်။

၄.၁.၃ များစွာသော Subnet Clustering

Multi-subnet clustering သည် availability group replicas များကို မတူညီသော network subnet များကို လွှမ်းခြုံနိုင်စေပြီး data center များတစ်လျှောက် ပထဝီဝင်အနေအထားအရ ဖြန့်ဝေထားသော deployments များကို ပံ့ပိုးပေးပါသည်။ ဤစွမ်းရည်သည် replicas များသည် သီးခြားနေရာများတွင် ရှိနေသည့် disaster recovery configuration များအတွက် မရှိမဖြစ်လိုအပ်ပါသည်။

3.2 SQL Server ထုတ်ဝေမှု လိုအပ်ချက်များ

၄.၂.၁ Enterprise Edition အင်္ဂါရပ်များ

SQL Server Enterprise Edition သည် ကန့်သတ်ချက်မရှိဘဲ ရရှိနိုင်မှုအုပ်စုများ၏ လုပ်ဆောင်ချက်အပြည့်အစုံကို ပေးဆောင်သည်။ Enterprise Edition သည် ဒုတိယမိတ္တူရှစ်ခု၊ ဖတ်နိုင်သော ဒုတိယအုပ်စုများ၊ အလိုအလျောက် seeding၊ ဖြန့်ဝေထားသော ရရှိနိုင်မှုအုပ်စုများနှင့် အဆင့်မြင့်အင်္ဂါရပ်အားလုံးကို ပံ့ပိုးပေးသည်။

၄.၂.၂ စံထုတ်ဝေမှု အင်္ဂါရပ်များ (အခြေခံရရှိနိုင်မှုအုပ်စုများ)

SQL Server ၂၀၁၆ Standard edition နှင့် နောက်ပိုင်းထုတ်ဝေမှုများသည် သိသာထင်ရှားသော ကန့်သတ်ချက်များရှိသော Basic Availability Groups များကို ပံ့ပိုးပေးပါသည်။ Basic Availability Groups များသည် core high availability လုပ်ဆောင်ချက်ကို ကုန်ကျစရိတ်နည်းပါးစွာဖြင့် ပေးစွမ်းပြီး ရိုးရှင်းသော လိုအပ်ချက်များရှိသော အဖွဲ့အစည်းများအတွက် သင့်လျော်ပါသည်။

၅။ အမြဲတမ်းရရှိနိုင်မှုအုပ်စုများကို ပြင်ဆင်သတ်မှတ်ခြင်း

၅.၁ ပတ်ဝန်းကျင်ပြင်ဆင်ခြင်း

ရရှိနိုင်မှုအုပ်စုတစ်ခု မဖန်တီးမီ၊ Active Directory အကောင့်များ၊ server ပြင်ဆင်မှုများနှင့် network infrastructure များဖြင့် ပတ်ဝန်းကျင်ကို ကောင်းမွန်စွာ ပြင်ဆင်ထားရမည်။

၅.၁.၁ ဒိုမိန်း ထိန်းချုပ်ကိရိယာ စနစ်ထည့်သွင်းခြင်း

Active Directory domain controller ကို availability group cluster ကို support လုပ်ဖို့ configure လုပ်ရပါမယ်။ SQL Server ဝန်ဆောင်မှုအကောင့်များ။

domain administrator အထောက်အထားများဖြင့် domain controller သို့ ဝင်ရောက်ပါ။
ဖွင့်လှစ် ဆာဗာမန်နေဂျာ နှင့်လမ်းညွှန် Tools များ -> Active Directory အသုံးပြုသူများနှင့် ကွန်ပျူတာများ.
အတွက် အဖွဲ့အစည်းဆိုင်ရာ ယူနစ်တစ်ခု ဖန်တီးပါ SQL Server တစ်ခုမရှိရင် အရာဝတ္ထုတွေ။
cluster node အားလုံးအတွက် computer object များ Active Directory တွင် ရှိကြောင်း အတည်ပြုပါ။
Domain Name System (DNS) ဝန်ဆောင်မှုများကို ကောင်းမွန်စွာ configure လုပ်ထားပြီး server အမည်အားလုံးကို မှန်ကန်စွာ ဖြေရှင်းကြောင်း သေချာပါစေ။

၅.၁.၂ ဝန်ဆောင်မှုအကောင့်များ ဖန်တီးခြင်း

သီးသန့် Active Directory ဝန်ဆောင်မှုအကောင့်များ ဖန်တီးပါ SQL Server node တစ်ခုချင်းစီတွင် ဝန်ဆောင်မှုများ။

ဖွင့်လှစ် Active Directory အသုံးပြုသူများနှင့် ကွန်ပျူတာများ ဒိုမိန်း ထိန်းချုပ်ကိရိယာပေါ်မှာ။
သင့်လျော်သော အဖွဲ့အစည်းယူနစ်ကို ညာဖက်နှိပ်ပြီး ရွေးချယ်ပါ နယူး -> အသုံးပြုသူ.
ဝန်ဆောင်မှုအကောင့်အမည် (ဥပမာ၊ svc_SQLServer) ကို ရိုက်ထည့်ပြီး သတ်မှတ်ပါ။ အသုံးပြုသူဝင်ရောက်သည့်အမည်.
ကလစ်နှိပ်ပါ နောက်တစ်ခု ပြီးတော့ ခိုင်မာတဲ့ စကားဝှက်တစ်ခု ရိုက်ထည့်ပါ။
ကို Select လုပ်ပါ အသုံးပြုသူသည် စကားဝှက်ကို ပြောင်းလဲ၍မရပါ နှင့် စကားဝှက် ဘယ်တော့မှ သက်တမ်းမကုန်ဘူး.
ကလစ်နှိပ်ပါ နောက်တစ်ခု ပြီးတော့ အပြီးသတ် အကောင့်ဖန်တီးရန်။
လိုအပ်သော နောက်ထပ်ဝန်ဆောင်မှုအကောင့်များအတွက် ထပ်ခါတလဲလဲလုပ်ဆောင်ပါ (SQL Server အေးဂျင့်၊ SSRS၊ စသည်)။

၅.၁.၃ စီမံခန့်ခွဲသူခွင့်ပြုချက်များကို ပြင်ဆင်သတ်မှတ်ခြင်း

ဝန်ဆောင်မှုအကောင့်များနှင့် configure လုပ်ရန်အသုံးပြုသောအကောင့်များ SQL Server cluster node အားလုံးတွင် သင့်လျော်သော ခွင့်ပြုချက်များ ရှိရမည်။

cluster node server တစ်ခုချင်းစီသို့ ဝင်ရောက်ပါ။
ဖွင့်လှစ် Computer ကိုစီမံခန့်ခွဲမှု မှ စတင် မီနူး သို့မဟုတ် ဆာဗာ မန်နေဂျာ။
Expand ဒေသခံသုံးစွဲသူများနှင့်အဖွဲ့များ နှင့်ကို select အဖွဲ့များ.
right-click နှိပ်ပြီး အုပ်ချုပ်ရေးမှူးများ နှင့်ကို select My Properties.
ကလစ်နှိပ်ပါ ပေါင်း ပြီးလျှင် ဝန်ဆောင်မှုအကောင့်အမည်ကို ရိုက်ထည့်ပါ။
ကလစ်နှိပ်ပါ အမည်များကို စစ်ဆေးပါ။ အကောင့်ကို အတည်ပြုရန်၊ ထို့နောက် နှိပ်ပါ OK.
ကလစ်နှိပ်ပါ OK Administrators Properties dialog box ကို ပိတ်ရန်။
cluster node အားလုံးတွင် ပြန်လုပ်ပါ။

၅.၂ WSFC ကို ထည့်သွင်းခြင်းနှင့် ပြင်ဆင်ခြင်း

Always On Availability Groups ကို မဖွင့်မီ node အားလုံးတွင် Windows Server Failover Clustering ကို ထည့်သွင်းပြီး configure လုပ်ရပါမည်။

၅.၂.၁ Failover Clustering Feature ကို ထည့်သွင်းခြင်း

Availability group တွင် ပါဝင်မည့် server တိုင်းတွင် Failover Clustering feature ကို install လုပ်ပါ။

ဖွင့်လှစ် ဆာဗာမန်နေဂျာ ပထမဆုံး cluster node ပေါ်မှာ။
ကလစ်နှိပ်ပါ စီမံခန့်ခွဲရန် -> အခန်းကဏ္ဍများနှင့် အင်္ဂါရပ်များ ထည့်ပါ.
ကလစ်နှိပ်ပါ နောက်တစ်ခု မိတ်ဆက်မျက်နှာပြင်များမှတစ်ဆင့်။
ကို Select လုပ်ပါ အခန်းကဏ္ဍအခြေပြု သို့မဟုတ် အင်္ဂါရပ်အခြေပြု ထည့်သွင်းခြင်း နှင့်ကိုကလစ်နှိပ်ပါ နောက်တစ်ခု.
ဒေသခံဆာဗာကို ရွေးချယ်ပြီး နှိပ်ပါ နောက်တစ်ခု.
Roles မျက်နှာပြင်ကို ကျော်ပြီး နှိပ်ပါ နောက်တစ်ခု.
အင်္ဂါရပ်များ မျက်နှာပြင်တွင်၊ ရွေးချယ်ပါ Failover Clustering.
ကလစ်နှိပ်ပါ အင်္ဂါရပ်များထည့်ပါ စီမံခန့်ခွဲမှုကိရိယာများကို ထည့်သွင်းရန် တောင်းဆိုသည့်အခါ။
ကလစ်နှိပ်ပါ နောက်တစ်ခု ပြီးတော့ Install.
ထည့်သွင်းမှုပြီးဆုံးသည်အထိစောင့်ပြီး နှိပ်ပါ ပိတ်.
cluster တွင် ပါဝင်မည့် server အားလုံးတွင် ပြန်လုပ်ပါ။

၅.၂.၂ Failover Cluster ဖန်တီးခြင်း

node အားလုံးတွင် Failover Clustering feature ကို install လုပ်ပြီးနောက်၊ node တစ်ခုမှ cluster တစ်ခုကို ဖန်တီးပါ။

ဖွင့်လှစ် Failover Cluster မန်နေဂျာ မှ ဆာဗာမန်နေဂျာ -> Tools များ.
ကလစ်နှိပ်ပါ Cluster ဖန်တီးပါ။ လုပ်ဆောင်ချက်များ အကန့်တွင်။
ကလစ်နှိပ်ပါ နောက်တစ်ခု မစတင်မီ စာမျက်နှာတွင်။
ကလစ်နှိပ်ပါ Browse ကို ပြီးတော့ cluster node တွေဖြစ်မယ့် server အားလုံးကို ထည့်ပါ။
ကလစ်နှိပ်ပါ နောက်တစ်ခု node အားလုံးကိုထည့်ပြီးနောက်။
ထွက်သွား စမ်းသပ်မှုအားလုံးကို လုပ်ဆောင်ပါ (အကြံပြုထားသည်) ရွေးချယ်ပြီး နှိပ်ပါ နောက်တစ်ခု.
အတည်ပြုချက် စမ်းသပ်မှုရလဒ်များကို ပြန်လည်သုံးသပ်ပြီး မည်သည့်အမှားအယွင်းများ သို့မဟုတ် သတိပေးချက်များကိုမဆို ကိုင်တွယ်ဖြေရှင်းပါ။
ကလစ်နှိပ်ပါ အပြီးသတ် အတည်ပြုခြင်း အောင်မြင်စွာပြီးဆုံးပြီးနောက်။
cluster နှင့် IP address အတွက် အမည်တစ်ခု ရိုက်ထည့်ပါ။
Uncheck အရည်အချင်းပြည့်မီသော သိုလှောင်မှုအားလုံးကို cluster ထဲသို့ထည့်ပါ မျှဝေသိမ်းဆည်းရန် မလိုအပ်သောကြောင့်။
ကလစ်နှိပ်ပါ နောက်တစ်ခု နှင့် အတည်ပြုချက်ကို ပြန်လည်သုံးသပ်ပါ။
ကလစ်နှိပ်ပါ အပြီးသတ် cluster ကို ဖန်တီးရန်။

၅.၂.၃ Cluster Configuration ကို အတည်ပြုခြင်း

node အားလုံး ကောင်းမွန်စွာ ဆက်သွယ်နိုင်ကြောင်းနှင့် cluster မှန်ကန်စွာ လည်ပတ်နိုင်ကြောင်း သေချာစေရန် cluster configuration ကို အတည်ပြုပါ။

In Failover Cluster မန်နေဂျာ, cluster အမည်ကို right-click လုပ်ပါ။
ကို Select လုပ်ပါ Cluster ကို အတည်ပြုပါ မီနူးကနေ။
ကလစ်နှိပ်ပါ နောက်တစ်ခု မစတင်မီ စာမျက်နှာတွင်။
ကို Select လုပ်ပါ စမ်းသပ်မှုအားလုံးကို လုပ်ဆောင်ပါ (အကြံပြုထားသည်) နှင့်ကိုကလစ်နှိပ်ပါ နောက်တစ်ခု.
ကလစ်နှိပ်ပါ နောက်တစ်ခု အတည်ပြုချက် စမ်းသပ်မှုများကို စတင်ရန်။
စမ်းသပ်မှုပြီးဆုံးသောအခါ အတည်ပြုချက်အစီရင်ခံစာကို ပြန်လည်သုံးသပ်ပါ။
အစီရင်ခံစာတွင် ဖော်ထုတ်တွေ့ရှိထားသည့် မည်သည့်ချို့ယွင်းချက်များ သို့မဟုတ် သတိပေးချက်များကိုမဆို ဖြေရှင်းပါ။
ကလစ်နှိပ်ပါ အပြီးသတ် wizard ကို ပိတ်ရန်။

4.3 ထည့်သွင်းခြင်း။ SQL Server ရရှိနိုင်မှုအဖွဲ့များအတွက်

Install SQL Server သီးခြားထည့်သွင်းမှုရွေးချယ်မှုကို အသုံးပြု၍ ရရှိနိုင်မှုအုပ်စုတွင် ပါဝင်မည့် node တစ်ခုချင်းစီတွင်။

အဆိုပါ run SQL Server ပထမဆုံး node ပေါ်ရှိ installation media။
ကို Select လုပ်ပါ နယူး SQL Server သီးခြားတပ်ဆင်ခြင်း.
ထုတ်ကုန်သော့ကို ရိုက်ထည့်ပါ သို့မဟုတ် အကဲဖြတ်ထုတ်ဝေမှုကို ရွေးချယ်ပါ။
လိုင်စင်စည်းကမ်းချက်များကို လက်ခံပြီး နှိပ်ပါ နောက်တစ်ခု.
ကြိုတင်စစ်ဆေးမှုများကို ပြီးမြောက်အောင်လုပ်ပြီး ပြဿနာများကို ဖြေရှင်းပါ။
Feature Selection စာမျက်နှာမှာ၊ select လုပ်ပါ။ ဒေတာဘေ့စ်အင်ဂျင်ဝန်ဆောင်မှုများ.
instance name ကို configure လုပ်ပါ။ (node အားလုံးတွင် instance name တစ်ခုတည်းကို အသုံးပြုပါ။)
Server Configuration စာမျက်နှာတွင်၊ ဝန်ဆောင်မှုအကောင့် အထောက်အထားများကို သတ်မှတ်ပါ။
ဝန်ဆောင်မှုစတင်မှုအမျိုးအစားများကို အောက်ပါအတိုင်း ပြင်ဆင်သတ်မှတ်ပါ automatic.
Database Engine Configuration စာမျက်နှာတွင်၊ authentication mode ကို ရွေးချယ်ပါ။
စီမံခန့်ခွဲသူအကောင့်များကို ထည့်ပါ။
node အားလုံးတွင် တသမတ်တည်းရှိသော လမ်းကြောင်းများကို အသုံးပြု၍ data directory များကို configure လုပ်ပါ။
ထည့်သွင်းမှုကို အပြီးသတ်ပြီး အောင်မြင်မှုကို အတည်ပြုပါ။
အခြား cluster node အားလုံးတွင် တူညီသော setting များဖြင့် ထပ်မံထည့်သွင်းပါ။

၅.၄ Always On Availability Groups လုပ်ဆောင်ချက်ကို ဖွင့်ခြင်း

တပ်ဆင်ပြီးနောက် SQL Server node အားလုံးတွင်၊ instance တစ်ခုချင်းစီတွင် Always On Availability Groups လုပ်ဆောင်ချက်ကို ဖွင့်ပါ။

၅.၄.၁ မှတစ်ဆင့် ဖွင့်ခြင်း SQL Server Configuration Manager

အသုံး SQL Server ဂရပ်ဖစ် အင်တာဖေ့စ်မှတစ်ဆင့် Always On Availability Groups ကို ဖွင့်ရန် Configuration Manager။

ဖွင့်လှစ် SQL Server Configuration Manager ပထမဆုံး node ပေါ်မှာ။
Expand SQL Server န်ဆောင်မှုများ လက်ဝဲ pane ထဲကကို။
Right-Click SQL Server ဥပမာနှင့် ရွေးချယ်ပါ My Properties.
အကိုကလစ်နှိပ်ပါ အမြဲတမ်းရရှိနိုင်မှု မြင့်မားခြင်း tab ကို။
စစ်ဆေးခြင်း AlwaysOn ရရှိနိုင်မှုအဖွဲ့များကို ဖွင့်ပါ.
Windows failover cluster အမည် မှန်ကန်ကြောင်း စစ်ဆေးပါ။
ကလစ်နှိပ်ပါ OK ပြောင်းလဲမှုများကို save ဖို့။
ကလစ်နှိပ်ပါ OK ဝန်ဆောင်မှုကို ပြန်လည်စတင်ရမည်ဟူသော သတိပေးချက်တွင်။
Right-Click SQL Server ဝန်ဆောင်မှုပေးပြီး ရွေးချယ်ပါ ပြန်စတင်သည်.
ဝန်ဆောင်မှု အောင်မြင်စွာ ပြန်လည်စတင်ရန် စောင့်ပါ။
cluster node အားလုံးတွင် ပြန်လုပ်ပါ။

၅.၄.၂ PowerShell မှတစ်ဆင့် ဖွင့်ခြင်း

PowerShell သည် node များစွာတွင် Always On Availability Groups ကိုဖွင့်ရန် scripted method တစ်ခုကိုပေးသည်။

ပထမဆုံး node မှာ PowerShell ကို Administrator အနေနဲ့ဖွင့်ပါ။
တင်သွင်းပါ SQL Server PowerShell မော်ဂျူး:
```
Import-Module SQLPS -DisableNameChecking
```
အမြဲတမ်းဖွင့်ထားနိုင်သော ရရှိနိုင်မှုအုပ်စုများကို ဖွင့်ပါ-
```
Enable-SqlAlwaysOn -ServerInstance "ServerName\InstanceName" -Force
```
Force parameter ကိုအသုံးပြုသည့်အခါ service သည် အလိုအလျောက် restart လုပ်ပါလိမ့်မည်။
အင်္ဂါရပ်ကို ဖွင့်ထားကြောင်း အတည်ပြုပါ-
```
Get-ItemProperty "SQLSERVER:\SQL\ServerName\InstanceName" | Select-Object IsHadrEnabled
```
သင့်လျော်သော server နှင့် instance name များကို အစားထိုးခြင်းဖြင့် cluster node တစ်ခုချင်းစီအတွက် ပြန်လုပ်ပါ။

၅.၄.၃ အင်္ဂါရပ်ကို ဖွင့်ထားကြောင်း အတည်ပြုခြင်း

စီစဉ်သတ်မှတ်ခြင်းမလုပ်ဆောင်မီ အခြေအနေအားလုံးတွင် Always On Availability Groups ကို ဖွင့်ထားကြောင်း အတည်ပြုပါ။

တစ်ခုချင်းစီကို ချိတ်ဆက်ပါ SQL Server ဥပမာကို အသုံးပြု၍ SQL Server စီမံခန့်ခွဲမှုစတူဒီယို။
query window အသစ်တစ်ခုဖွင့်ပြီး အောက်ပါအတိုင်း လုပ်ဆောင်ပါ-
```
SELECT SERVERPROPERTY('IsHadrEnabled')
```
ရလဒ်သည် ၁ (ဖွင့်ထားသည်) ဖြစ်ကြောင်း အတည်ပြုပါ။
ကြောင်းစစ်ဆေးပါ SQL Server instance သည် cluster roles အောက်ရှိ Failover Cluster Manager တွင် ပေါ်လာသည်။
အောက်ပါတို့ကို လုပ်ဆောင်ခြင်းဖြင့် availability group endpoint ရှိနေကြောင်း အတည်ပြုပါ-
```
SELECT * FROM sys.endpoints WHERE type_desc = 'DATABASE_MIRRORING'
```
အဆုံးမှတ်မရှိပါက ရရှိနိုင်မှုအဖွဲ့ဖန်တီးနေစဉ်အတွင်း ၎င်းကို ဖန်တီးသွားပါမည်။

၅.၅ ရရှိနိုင်မှုအုပ်စုများအတွက် ဒေတာဘေ့စ်များပြင်ဆင်ခြင်း

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

၅.၅.၁ ဒေတာဘေ့စ် ပြန်လည်ရယူခြင်း မော်ဒယ် လိုအပ်ချက်များ

availability group ထဲသို့ မထည့်မီ primary replica တွင် database recovery model ကို FULL သို့ ပြောင်းပါ။

အသုံးပြု၍ မူလမိတ္တူနှင့် ချိတ်ဆက်ပါ SQL Server စီမံခန့်ခွဲမှုစတူဒီယို။
ဒေတာဘေ့စ်ကို right click နှိပ်ပြီး select လုပ်ပါ။ My Properties.
ယင်းကို Select လုပ်ပါ Options ကို စာမျက်နှာ။
ပွောငျးလဲ ပြန်လည်ကောင်းမွန်လာမှုပုံစံ သို့ ပြည့်သော.
ကလစ်နှိပ်ပါ OK အပြောင်းအလဲကို သိမ်းဆည်းရန်။
တနည်းအားဖြင့် Transact-SQL ကိုသုံးပါ-
```
ALTER DATABASE DatabaseName SET RECOVERY FULL;
```

၅.၅.၂ ဒေတာဘေ့စ် အပြည့်အဝ အရန်ကူးယူခြင်း

ရရှိနိုင်မှုအုပ်စုများအတွက် လိုအပ်သော backup chain ကို တည်ဆောက်ရန်အတွက် database အပြည့်အစုံ backup ပြုလုပ်ပါ။

In SQL Server Management Studio မှာ database ကို right click နှိပ်ပါ။
ကို Select လုပ်ပါ လုပ်ငန်းတာဝန်များ -> Up ကို back.
Verify Backup အမျိုးအစား သတ်မှတ် ပြည့်သော.
အရန်နေရာတစ်ခုကို ရွေးချယ်ပါ သို့မဟုတ် နေရာအသစ်တစ်ခု ထည့်ပါ။
ကလစ်နှိပ်ပါ OK backup လုပ်ဖို့။
တနည်းအားဖြင့် Transact-SQL ကိုသုံးပါ-
```
BACKUP DATABASE DatabaseName TO DISK = 'C:\Backup\DatabaseName.bak';
```

၅.၅.၃ ငွေပေးငွေယူမှတ်တမ်း အရန်ကူးယူခြင်း

log chain တည်ဆောက်ပြီးဖြစ်ကြောင်း သေချာစေရန်နှင့် initialization အချိန်ကို လျှော့ချရန်အတွက် transaction log backup တစ်ခုယူထားပါ။

In SQL Server Management Studio မှာ database ကို right click နှိပ်ပါ။
ကို Select လုပ်ပါ လုပ်ငန်းတာဝန်များ -> Up ကို back.
ပွောငျးလဲ Backup အမျိုးအစား သို့ ငွေလွှဲမှတ်တမ်း.
အရန်ကူးယူရန် ဦးတည်ရာတစ်ခုကို ရွေးချယ်ပါ။
ကလစ်နှိပ်ပါ OK backup လုပ်ဖို့။
တနည်းအားဖြင့် Transact-SQL ကိုသုံးပါ-
```
BACKUP LOG DatabaseName TO DISK = 'C:\Backup\DatabaseName.trn';
```

၅.၆ ရရှိနိုင်မှုအဖွဲ့ ဖန်တီးခြင်း

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

၅.၆.၁ ရရှိနိုင်မှုအုပ်စုအသစ် Wizard ကိုအသုံးပြုခြင်း

ရရှိနိုင်မှုအုပ်စုအသစ် Wizard သည် ရရှိနိုင်မှုအုပ်စုများဖန်တီးရန်အတွက် ဂရပ်ဖစ်အင်တာဖေ့စ်တစ်ခုကို ပံ့ပိုးပေးသည်။

In SQL Server Management Studio၊ primary replica ကို host လုပ်မယ့် instance နဲ့ ချိတ်ဆက်ပါ။
Expand အမြဲတမ်းရရှိနိုင်မှု မြင့်မားခြင်း Object Explorer တွင်။
right-click နှိပ်ပြီး ရရှိနိုင်မှုအုပ်စုများ နှင့်ကို select ရရှိနိုင်မှုအဖွဲ့အသစ် ဝစ်ဇာ.
ကလစ်နှိပ်ပါ နောက်တစ်ခု မိတ်ဆက်စာမျက်နှာတွင်။
ရရှိနိုင်မှုအုပ်စုအတွက် အမည်တစ်ခုထည့်ပြီး နှိပ်ပါ နောက်တစ်ခု.
Select Databases စာမျက်နှာတွင်၊ ထည့်သွင်းမည့် database များကို ရွေးချယ်ပါ။
ဒေတာဘေ့စ်များသည် ကြိုတင်လိုအပ်ချက်အားလုံးနှင့် ကိုက်ညီကြောင်း အတည်ပြုပြီး နှိပ်ပါ နောက်တစ်ခု.
Specify Replicas စာမျက်နှာတွင်၊ နှိပ်ပါ ပုံတူထည့်ပါ.
ဒုတိယမိတ္တူတစ်ခုစီနှင့် ချိတ်ဆက်ပါ။
instance တစ်ခုစီ (availability mode၊ failover mode) အတွက် replica properties များကို configure လုပ်ပါ။
အကိုကလစ်နှိပ်ပါ အဆုံးမှတ် tab ကို နှိပ်ပြီး endpoint configure ကို ပြန်လည်သုံးသပ်ပါ။
အကိုကလစ်နှိပ်ပါ အရန်ကူးယူခြင်း ဦးစားပေးများ tab ကို နှိပ်ပြီး အရန်ကူးယူခြင်း ဦးစားပေးမှုများကို ပြင်ဆင်သတ်မှတ်ပါ။
အကိုကလစ်နှိပ်ပါ နားထောင်သူ tab ကို နှိပ်ပြီး ရွေးချယ်နိုင်သော listener တစ်ခုကို ဖန်တီးပါ။
ကလစ်နှိပ်ပါ နောက်တစ်ခု နှင့် ဒေတာ ထပ်တူပြုခြင်း နည်းလမ်းကို ရွေးချယ်ပါ။
အတည်ပြုချက်ရလဒ်များကို ပြန်လည်သုံးသပ်ပြီး ပြဿနာများကို ဖြေရှင်းပါ။
ကလစ်နှိပ်ပါ နောက်တစ်ခု နှင့် အနှစ်ချုပ်ကို ပြန်လည်သုံးသပ်ပါ။
ကလစ်နှိပ်ပါ အပြီးသတ် ရရှိနိုင်မှုအဖွဲ့ကို ဖန်တီးရန်။
တိုးတက်မှုကို စောင့်ကြည့်ပြီး အောင်မြင်သော ဖန်တီးမှုကို အတည်ပြုပါ။

၅.၆.၂ Transact-SQL ကို အသုံးပြုခြင်း

script လုပ်နိုင်သော၊ ထပ်ခါတလဲလဲ ဖြန့်ကျက်မှုများအတွက် Transact-SQL ကို အသုံးပြု၍ ရရှိနိုင်မှုအုပ်စုများကို ဖန်တီးပါ။

မူလမိတ္တူပေါ်တွင် ရရှိနိုင်မှုအုပ်စုကို ဖန်တီးပါ-

CREATE AVAILABILITY GROUP AG_Name
FOR DATABASE DatabaseName
REPLICA ON
  'PrimaryServer\Instance' WITH
    (ENDPOINT_URL = 'TCP://PrimaryServer:5022',
     AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
     FAILOVER_MODE = AUTOMATIC,
     SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL)),
  'SecondaryServer\Instance' WITH
    (ENDPOINT_URL = 'TCP://SecondaryServer:5022',
     AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
     FAILOVER_MODE = AUTOMATIC,
     SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL));

ဒုတိယမိတ္တူကို ရရှိနိုင်မှုအုပ်စုနှင့် ချိတ်ဆက်ပါ-
```
ALTER AVAILABILITY GROUP AG_Name JOIN;
```
ဒုတိယဒေတာဘေ့စ်သို့ ဝင်ရောက်ပါ-
```
ALTER DATABASE DatabaseName SET HADR AVAILABILITY GROUP = AG_Name;
```

၅.၆.၃ PowerShell အသုံးပြုခြင်း

PowerShell သည် ရရှိနိုင်မှုအုပ်စု ဖန်တီးခြင်းနှင့် စီမံခန့်ခွဲမှုအတွက် scripting စွမ်းရည်များကို ပံ့ပိုးပေးသည်။

ရရှိနိုင်မှုအုပ်စုအရာဝတ္ထုကို ဖန်တီးပါ-
```
$AG = New-SqlAvailabilityGroup -Name "AG_Name" -Path "SQLSERVER:\SQL\PrimaryServer\Instance"
```

ဒေတာဘေ့စ်များ ထည့်ရန်-

Add-SqlAvailabilityDatabase -Path "SQLSERVER:\SQL\PrimaryServer\Instance\AvailabilityGroups\AG_Name" -Database "DatabaseName"

New-SqlAvailabilityReplica cmdlet ကို အသုံးပြု၍ လိုချင်သော properties များဖြင့် ပုံတူများကို configure လုပ်ပါ။
Join-SqlAvailabilityGroup cmdlet ကို အသုံးပြု၍ ဒုတိယမိတ္တူများကို ချိတ်ဆက်ပါ။

၅.၇ Availability Group ထဲသို့ Replicas များထည့်သွင်းခြင်း

instance တစ်ခုစီသည် availability group တွင် မည်သို့ပါဝင်သည်ကို ထိန်းချုပ်သည့် replica-specific properties များကို configure လုပ်ပါ။

၅.၇.၁ ပုံတူဂုဏ်သတ္တိများကို ပြင်ဆင်ခြင်း

ရရှိနိုင်မှုအုပ်စုအတွင်း ၎င်း၏အခန်းကဏ္ဍနှင့် စွမ်းရည်များကို သတ်မှတ်ရန် ပုံတူတစ်ခုစီအတွက် ဂုဏ်သတ္တိများကို သတ်မှတ်ပါ။

In SQL Server စီမံခန့်ခွဲမှုစတူဒီယို၊ ချဲ့ထွင်ပါ။ အမြဲတမ်းရရှိနိုင်မှု မြင့်မားခြင်း -> ရရှိနိုင်မှုအုပ်စုများ.
ရရှိနိုင်မှုအုပ်စုကို ချဲ့ထွင်ပြီးနောက် ချဲ့ထွင်ပါ ရရှိနိုင်မှုမိတ္တူများ.
ပုံတူတစ်ခုကို right click နှိပ်ပြီး select လုပ်ပါ။ My Properties.
အဓိကနှင့် ဒုတိယအခန်းကဏ္ဍများအတွက် ချိတ်ဆက်မှုဆက်တင်များကို ပြန်လည်သုံးသပ်ပြီး ပြုပြင်ပါ။
လိုအပ်ပါက session timeout တန်ဖိုးများကို ပြင်ဆင်သတ်မှတ်ပါ။
ကလစ်နှိပ်ပါ OK ပြောင်းလဲမှုများကို save ဖို့။

၅.၇.၂ ရရှိနိုင်မှုမုဒ်များ သတ်မှတ်ခြင်း

ပုံတူများအကြား ထပ်တူပြုခြင်းအပြုအမူကို ထိန်းချုပ်ရန် ရရှိနိုင်မှုမုဒ်ကို ပြင်ဆင်သတ်မှတ်ပါ။

ရရှိနိုင်မှုအုပ်စုကို right-click နှိပ်ပြီး select လုပ်ပါ My Properties.
ထဲမှာ ယေဘုယျ စာမျက်နှာသို့သွားပါ။ ရရှိနိုင်မှုမိတ္တူများ အပိုင်း။
ပုံတူတစ်ခုချင်းစီအတွက် ရွေးချယ်ပါ တစ်ပြိုင်နက်တည်း ကတိပြုခြင်း or တစ်ပြိုင်နက်တည်းမဟုတ်သော ကတိကဝတ် dropdown ကနေ။
ဒေသတွင်း မြင့်မားသော ရရှိနိုင်မှုရှိသော ပုံတူများအတွက် synchronous commit ကို အသုံးပြုပါ။
ပထဝီအနေအထားအရ ဝေးကွာသော ဘေးအန္တရာယ်ပြန်လည်ထူထောင်ရေးမိတ္တူများအတွက် asynchronous commit ကိုသုံးပါ။
ကလစ်နှိပ်ပါ OK configuration ကို save လုပ်ဖို့။

၅.၇.၃ Failover မုဒ်များ သတ်မှတ်ခြင်း

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

ရရှိနိုင်မှုအုပ်စုကို right-click နှိပ်ပြီး select လုပ်ပါ My Properties.
ထဲမှာ ယေဘုယျ စာမျက်နှာသို့သွားပါ။ ရရှိနိုင်မှုမိတ္တူများ အပိုင်း။
synchronous commit replicas များအတွက်၊ ရွေးချယ်ပါ automatic or လက်စွဲ ပျက်ကွက်မှုမုဒ်။
အလိုအလျောက် failover သည် synchronous commit mode လိုအပ်ပြီး အလိုအလျောက် failover ကို ဖွင့်ပေးသည်။
asynchronous commit replicas များအတွက် manual failover ကိုသာ ရရှိနိုင်ပါသည်။
အလိုအလျောက် failover အတွက် ပုံတူသုံးခုအထိ ပြင်ဆင်သတ်မှတ်ပါ (အဓိကတစ်ခုနှင့် ဒုတိယနှစ်ခု)။
ကလစ်နှိပ်ပါ OK settings ကိုလျှောက်ထားရန်။

၅.၇.၄ အရန်ကူးယူခြင်း ဦးစားပေးမှုများကို ပြင်ဆင်သတ်မှတ်ခြင်း

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

ရရှိနိုင်မှုအုပ်စုကို right-click နှိပ်ပြီး select လုပ်ပါ My Properties.
ကို Select လုပ်ပါ အရန်ကူးယူခြင်း ဦးစားပေးများ လက်ဝဲ pane ထဲကကို။
အရန်ကူးယူခြင်း ဦးစားပေးမှုများထဲမှ တစ်ခုကို ရွေးချယ်ပါ-
- ဒုတိယဦးစားပေး: ရရှိနိုင်ပါက ဒုတိယအဆင့်တွင် အရန်ကူးယူပါ၊ မဟုတ်ပါက အဓိကအဆင့်တွင် သိမ်းဆည်းပါ
- ဒုတိယအဆင့်သာ: ဒုတိယမိတ္တူများတွင်သာ အရန်ကူးယူမှုများ
- မူလတန်း: မူလမိတ္တူတွင်သာ အရန်ကူးယူမှုများ
- မည်သည့်မိတ္တူမဆို: ရရှိနိုင်သော မည်သည့်မိတ္တူတွင်မဆို အရန်ကူးယူမှုများ
ပုံတူတစ်ခုစီအတွက် အရန်ကူးယူခြင်း ဦးစားပေးတန်ဖိုးများ (၀-၁၀၀) သတ်မှတ်ပါ။
ဦးစားပေးတန်ဖိုးများ ပိုမိုမြင့်မားခြင်းသည် ဦးစားပေး အရန်ပစ်မှတ်များကို ညွှန်ပြသည်။
ကလစ်နှိပ်ပါ OK ဦးစားပေးမှုများကို သိမ်းဆည်းရန်။

၅.၈ Availability Group Listener ကို configure လုပ်ခြင်း

လက်ရှိ primary replica သို့ အလိုအလျောက် ပြန်ညွှန်းပေးသည့် single connection point တစ်ခု ပံ့ပိုးပေးရန် listener တစ်ခု ဖန်တီးပါ။

၅.၈.၁ နားထောင်သူ ဖန်တီးခြင်း

client connection management အတွက် availability group တွင် listener တစ်ခုကို ထည့်ပါ။

In SQL Server Management Studio၊ ရရှိနိုင်မှုအဖွဲ့ကို တိုးချဲ့ပါ။
right-click နှိပ်ပြီး ရရှိနိုင်မှုအဖွဲ့ နားထောင်သူများ နှင့်ကို select နားထောင်သူထည့်ပါ။.
နားထောင်သူအတွက် DNS အမည်တစ်ခု ရိုက်ထည့်ပါ (ဥပမာ၊ AG_Listener)။
port နံပါတ်ကို ရိုက်ထည့်ပါ (ပုံသေအားဖြင့် 1433 ဖြစ်သည်)။
ကို Select လုပ်ပါ static IP ကို ကွန်ရက်မုဒ်အတွက်။
ကလစ်နှိပ်ပါ ပေါင်း subnet တစ်ခုစီအတွက် IP address တစ်ခုထည့်ရန်။
IP address ကို ရိုက်ထည့်ပြီး subnet ကို ရွေးချယ်ပါ။
ကလစ်နှိပ်ပါ OK နားထောင်သူကို ဖန်တီးရန်။
listener သည် Object Explorer တွင် ပေါ်လာပြီး အွန်လိုင်းတွင် ရှိနေကြောင်း အတည်ပြုပါ။

၅.၈.၂ DNS နှင့် IP ဆက်တင်များကို ပြင်ဆင်ခြင်း

နားထောင်သူအတွက် DNS မှတ်ပုံတင်ခြင်းနှင့် ကွန်ရက်ပြင်ဆင်မှုကို အတည်ပြုပါ။

ဒိုမိန်းထိန်းချုပ်ကိရိယာပေါ်ရှိ DNS Manager ကိုဖွင့်ပါ။
နားထောင်သူအမည်ကို IP လိပ်စာအားလုံးနှင့် မှတ်ပုံတင်ထားကြောင်း အတည်ပြုပါ။
client စက်များမှ DNS resolution ကို စမ်းသပ်ပါ-
```
nslookup ListenerName
```
ပြင်ဆင်ထားသော IP လိပ်စာအားလုံးကို ပြန်ပို့ပေးကြောင်း အတည်ပြုပါ။
Failover Cluster Manager မှာ ချဲ့ထွင်ပါ။ အခန်းကဏ္ဍ နှင့် ရရှိနိုင်မှုအုပ်စုကို ရွေးချယ်ပါ။
IP address အရင်းအမြစ်များ အွန်လိုင်းတွင်ရှိကြောင်း အတည်ပြုပါ။
ကွန်ရက်အမည်အရင်းအမြစ် အွန်လိုင်းတွင် ရှိနေကြောင်း စစ်ဆေးပါ။

၅.၈.၃ နားထောင်သူ ချိတ်ဆက်မှုကို စမ်းသပ်ခြင်း

client application များသည် listener မှတစ်ဆင့် ချိတ်ဆက်နိုင်ကြောင်း အတည်ပြုပါ။

client စက်ကနေ ဖွင့်လိုက်ပါ SQL Server စီမံခန့်ခွဲမှုစတူဒီယို။
server name အစား listener name ကိုသုံးပြီး ချိတ်ဆက်ပါ။
လက်ရှိ primary replica နှင့် ချိတ်ဆက်မှုကို အတည်ပြုရန် query တစ်ခုကို execute လုပ်ပါ-
```
SELECT @@SERVERNAME;
```
connection string တွင် ApplicationIntent=ReadOnly ကိုထည့်သွင်းခြင်းဖြင့် read-intent routing ကိုစမ်းသပ်ပါ။
ဖတ်နိုင်သော ဒုတိယမိတ္တူတစ်ခုသို့ ချိတ်ဆက်မှု ပြန်ညွှန်းခြင်းကို အတည်ပြုပါ။
ရရှိနိုင်မှုအုပ်စုကို ကိုယ်တိုင်ပျက်ကွက်ခြင်းဖြင့် failover ကို စမ်းသပ်ပြီး ပြန်လည်ချိတ်ဆက်မှုကို အတည်ပြုပါ။

၅.၉ ဒေတာ ထပ်တူပြုခြင်း နည်းလမ်းများ

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

၅.၉.၁ အလိုအလျောက် မျိုးစေ့ကြဲခြင်း

အလိုအလျောက် seeding သည် ကိုယ်တိုင် backup များနှင့် restore များ မလိုအပ်ဘဲ network မှတစ်ဆင့် database data များကို လွှဲပြောင်းပေးသည်။

ရရှိနိုင်မှုအဖွဲ့ ဖန်တီးနေစဉ်အတွင်း၊ ရွေးချယ်ပါ အလိုအလျောက် မျိုးစေ့ကြဲခြင်း synchronization နည်းလမ်းအဖြစ်။
ကွန်ရက်ချိတ်ဆက်မှုနှင့် ပုံတူပွားများအကြား လုံလောက်သော bandwidth ကို သေချာပါစေ။
primary replica က database data ကို secondary replicas တွေဆီ auto stream လုပ်ပေးပါတယ်။
ရရှိနိုင်မှုအဖွဲ့ ဒက်ရှ်ဘုတ် သို့မဟုတ် DMV များကို အသုံးပြု၍ စိုက်ပျိုးမှုတိုးတက်မှုကို စောင့်ကြည့်ပါ။
အလိုအလျောက် မျိုးစေ့ကြဲခြင်း လိုအပ်သည် SQL Server ၁၃.၂ သို့မဟုတ်နောက်ပိုင်း။
ဒေတာဘေ့စ်ကြီးများအတွက်၊ အသုံးပြုမှုနည်းသောကာလများအတွင်း ကွန်ရက်သက်ရောက်မှုနှင့် အချိန်ဇယားကို ထည့်သွင်းစဉ်းစားပါ။

၅.၉.၂ လက်စွဲထည့်သွင်းခြင်း (အရန်ကူးယူခြင်းနှင့် ပြန်လည်ရယူခြင်း)

ကိုယ်တိုင် seeding လုပ်ခြင်းတွင် primary တွင် backup များယူပြီး secondary replicas များတွင် restore လုပ်ခြင်း ပါဝင်သည်။

မူလမိတ္တူတွင်၊ အပြည့်အဝ backup လုပ်ပါ-
```
BACKUP DATABASE DatabaseName TO DISK = '\\SharePath\DatabaseName.bak';
```
ငွေပေးငွေယူမှတ်တမ်းကို အရန်ကူးယူပါ-
```
BACKUP LOG DatabaseName TO DISK = '\\SharePath\DatabaseName.trn';
```
ဒုတိယမိတ္တူတစ်ခုစီတွင်၊ အပြည့်အဝ backup ကိုပြန်လည်ရယူပါ-
```
RESTORE DATABASE DatabaseName FROM DISK = '\\SharePath\DatabaseName.bak' WITH NORECOVERY;
```
မှတ်တမ်းအရန်ကူးယူမှုကို ပြန်လည်ရယူပါ-
```
RESTORE LOG DatabaseName FROM DISK = '\\SharePath\DatabaseName.trn' WITH NORECOVERY;
```
ဒေတာဘေ့စ်ကို ရရှိနိုင်မှုအဖွဲ့သို့ ချိတ်ဆက်ပါ-
```
ALTER DATABASE DatabaseName SET HADR AVAILABILITY GROUP = AG_Name;
```
ထပ်တူပြုခြင်းစတင်ပြီး ဒေတာဘေ့စ်သည် SYNCHRONIZED အခြေအနေသို့ ရောက်ရှိကြောင်း အတည်ပြုပါ။

၅.၉.၃ ဒေတာဘေ့စ် လျှပ်တစ်ပြက်ဖိုင်များ

ရှိပြီးသား database ဖိုင်များမှ secondary replicas များကို initialize လုပ်ရန် database snapshot ဖိုင်များကို အသုံးပြုပါ။

မူလမိတ္တူပေါ်ရှိ ဒေတာဘေ့စ်ကို ဖြုတ်ချပါ သို့မဟုတ် အရန်ကူးယူပါ။
ဒေတာဘေ့စ်ဖိုင်များကို တူညီသောဖိုင်လမ်းကြောင်းများကို အသုံးပြု၍ ဒုတိယမိတ္တူတစ်ခုစီသို့ ကူးယူပါ။
ဒုတိယမိတ္တူများတွင်၊ ဒေတာဘေ့စ်ကို ပူးတွဲပါ သို့မဟုတ် ပြန်လည်ရယူခြင်းမရှိဘဲ ပြန်လည်ရယူပါ။
ဒေတာဘေ့စ်သည် RESTORING အခြေအနေတွင် ရှိနေကြောင်း သေချာပါစေ။
ဒေတာဘေ့စ်ကို ရရှိနိုင်မှုအဖွဲ့သို့ ချိတ်ဆက်ပါ။
ဒီနည်းလမ်းဟာ network transfer လုပ်လို့မရတဲ့ အလွန်ကြီးမားတဲ့ database တွေအတွက် အသုံးဝင်ပါတယ်။

5 ။ အမြဲမေးလေ့ရှိသောမေးခွန်းများ

5.1 အထွေထွေမေးခွန်းများ

မေး- Always On FCI နဲ့ Always On AG ရဲ့ ကွာခြားချက်က ဘာလဲ။

A: Always On Failover Cluster Instances များသည် shared storage ကို အသုံးပြု၍ instance-level high availability ကို ပေးစွမ်းပြီး Always On Availability Groups များသည် shared storage မပါဘဲ database-level high availability ကို ပေးစွမ်းသည်။ AG သည် ဖတ်ရှုနိုင်သော secondary များနှင့် ပိုမိုပြောင်းလွယ်ပြင်လွယ်ရှိသော ပထဝီဝင်ဆိုင်ရာ ဖြန့်ဖြူးမှုကို ပေးစွမ်းသည်။

မေး- Always On Availability Groups ကို အောက်ပါတို့ဖြင့် အသုံးပြုလို့ရပါသလား။ SQL Server စံထုတ်ဝေမှုလား။

A: ဟုတ်ကဲ့၊ SQL Server ၂၀၁၆ Standard Edition နှင့် နောက်ပိုင်းထုတ်ဝေမှုများသည် Basic Availability Groups ကို ပံ့ပိုးပေးပြီး AG တစ်ခုလျှင် database တစ်ခု၊ အများဆုံးမိတ္တူနှစ်ခုနှင့် ဖတ်နိုင်သော ဒုတိယပံ့ပိုးမှုမရှိခြင်း အပါအဝင် ကန့်သတ်ချက်များရှိသည်။

မေး- Always On Availability Groups အတွက် shared storage လိုအပ်ပါသလား။

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

မေး- ရရှိနိုင်မှုအုပ်စုတွင် အများဆုံးမိတ္တူအရေအတွက်က ဘယ်လောက်လဲ။

A: SQL Server Enterprise Edition တွင် ပုံတူကိုးခုအထိ (အဓိကတစ်ခုနှင့် ဒုတိယရှစ်ခု) ပံ့ပိုးပေးပါသည်။ ဖြန့်ဝေထားသော ရရှိနိုင်မှုအုပ်စုများသည် ရရှိနိုင်မှုအုပ်စုနှစ်ခုတွင် စုစုပေါင်းပုံတူ ၁၈ ခုအထိ ပံ့ပိုးပေးနိုင်ပါသည်။

၆.၂ ဖွဲ့စည်းပုံဆိုင်ရာ မေးခွန်းများ

မေး- synchronous နဲ့ asynchronous commit mode တွေကို ဘယ်လိုရွေးချယ်ရမလဲ။

A: တူညီသောဒေတာစင်တာ သို့မဟုတ် latency နိမ့်သောကွန်ရက်များအတွင်းရှိ သုညဒေတာဆုံးရှုံးမှုလိုအပ်ချက်များအတွက် synchronous commit ကိုသုံးပါ။ synchronous commit သည် စွမ်းဆောင်ရည်ကို သက်ရောက်မှုရှိနိုင်သည့် ဝေးလံသောဘေးအန္တရာယ်ပြန်လည်ရယူခြင်းမိတ္တူများအတွက် asynchronous commit ကိုသုံးပါ။

မေး- တူညီတဲ့ ရရှိနိုင်မှုအုပ်စုမှာ synchronous နဲ့ asynchronous replicas တွေကို ရောနှောလို့ရပါသလား။

A: ဟုတ်ကဲ့၊ ရရှိနိုင်မှုအုပ်စုများသည် synchronous နှင့် asynchronous replicas နှစ်မျိုးလုံးဖြင့် ရောနှောထားသော configuration များကို ပံ့ပိုးပေးပါသည်။ ၎င်းသည် synchronous replicas များဖြင့် local high availability နှင့် asynchronous replicas များဖြင့် disaster recovery ကို ဖြစ်စေသည်။

မေး- failover လုပ်နေစဉ်အတွင်း ကျွန်တော့်ရဲ့ ချိတ်ဆက်မှုတွေ ဘာဖြစ်သွားလဲ။

A: failover ဖြစ်ပေါ်သောအခါ ရှိပြီးသား ချိတ်ဆက်မှုများ ပြတ်တောက်သွားပါသည်။ connection retry logic ရှိသော application များသည် listener မှတစ်ဆင့် primary အသစ်သို့ အလိုအလျောက် ပြန်လည်ချိတ်ဆက်ပါသည်။ failover လုပ်ငန်းစဉ်သည် ပုံမှန်အားဖြင့် စက္ကန့်ပိုင်းမှ မိနစ်ပိုင်းအတွင်း ပြီးစီးပါသည်။

မေး- ပုံတူပွားများတစ်လျှောက် login များနှင့် အလုပ်များကို ထပ်တူပြုရန် လိုအပ်ပါသလား။

ဖြေ။ SQL Server ၂၀၁၉ နှင့် အစောပိုင်းကာလများတွင်၊ ဟုတ်ကဲ့ - logins များ၊ SQL Agent အလုပ်များနှင့် ချိတ်ဆက်ထားသော server များကို ကိုယ်တိုင် synchronize လုပ်ရပါမည်။ SQL Server ၂၀၂၂ ခုနှစ်တွင် ဤအရာဝတ္ထုများကို အလိုအလျောက်ထည့်သွင်းသည့် ပါ၀င်နိုင်သော အုပ်စုများကို မိတ်ဆက်ပေးခဲ့သည်။

၆.၃ စီမံခန့်ခွဲမှုဆိုင်ရာ မေးခွန်းများ

မေး- ဒုတိယမိတ္တူများတွင် backup များ လုပ်ဆောင်နိုင်ပါသလား။

A: ဟုတ်ကဲ့၊ ဒုတိယမိတ္တူများသည် full၊ differential နှင့် transaction log backup များကို ပံ့ပိုးပေးပါသည်။ primary replica မှ backup များကို offload လုပ်ရန်နှင့် ၎င်း၏ resource utilization ကို လျှော့ချရန် backup preference များကို configure လုပ်ပါ။

မေး- ဘယ်လို patch လုပ်ရမလဲ SQL Server အနည်းဆုံး အနားယူချိန်နဲ့လား။

A: secondary replicas များကို ဦးစွာ patch လုပ်ပြီးနောက် patched secondary ကို manual failover လုပ်ခြင်းဖြင့် rolling upgrades များကို အသုံးပြုပါ၊ နောက်ဆုံးတွင် ယခင် primary ကို patch လုပ်ခြင်းဖြင့်ဖြစ်သည်။ ၎င်းသည် failover duration ၏ downtime ကို လျှော့ချပေးသည်။

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

A: ဟုတ်ကဲ့၊ database များကို running availability group များထဲသို့ ထည့်သွင်းနိုင်ပါသည်။ database သည် full backup ပါရှိသော full recovery model တွင်ရှိရမည်ဖြစ်ပြီး၊ secondary replicas များကို automatic seeding သို့မဟုတ် manual backup and restore ကို အသုံးပြု၍ seed လုပ်ရမည်။

မေး- အလိုအလျောက် မျိုးစေ့ကြဲခြင်းဆိုတာ ဘာလဲ။ သုံးသင့်လား။

A: အလိုအလျောက် seeding သည် manual backup များမပါဘဲ secondary replicas များကို initialize လုပ်ရန် network မှတစ်ဆင့် database data ကို လွှဲပြောင်းပေးသည်။ ၎င်းကို database ငယ်များအတွက် သို့မဟုတ် network bandwidth လုံလောက်သည့်အခါတွင် အသုံးပြုပါ။ အလွန်ကြီးမားသော database များအတွက် manual seeding သည် ပိုမိုမြန်ဆန်နိုင်သည်။

မေး- ရရှိနိုင်မှုအုပ်စုတွင် DBCC CHECKDB ကို မည်သည့်နေရာတွင် လုပ်ဆောင်သင့်သနည်း။

A: primary replica မှာ load ကို လျှော့ချဖို့အတွက် secondary replicas တွေမှာ DBCC CHECKDB ကို run သင့်ပါတယ်။ Database consistency check တွေကို primary replica performance ကို မထိခိုက်စေဘဲ secondary database တွေနဲ့ ယှဉ်ပြီး execute လုပ်နိုင်ပါတယ်။

DBCC CHECKDB အကြောင်း အသေးစိတ်သိရှိလိုပါက ကျွန်ုပ်တို့၏ ပြည့်စုံသောလမ်းညွှန်.

5.4 ပြဿနာဖြေရှင်းခြင်းမေးခွန်းများ

မေး- ကျွန်တော့်ရဲ့ database က ဘာလို့ NOT SYNCHRONIZING state မှာ ရှိနေတာလဲ။

A: အဖြစ်များသော အကြောင်းရင်းများတွင် ကွန်ရက်ချိတ်ဆက်မှုပြဿနာများ၊ ဒေတာရွှေ့ပြောင်းမှု ရပ်ဆိုင်းထားခြင်း၊ ဒုတိယမိတ္တူများတွင် disk space မလုံလောက်ခြင်း သို့မဟုတ် endpoint ပြဿနာများ ပါဝင်သည်။ synchronization health description ကို စစ်ဆေးပြီး SQL Server အသေးစိတ်အချက်အလက်များအတွက် အမှားမှတ်တမ်းများ။ ဒုတိယဒေတာဘေ့စ်တွင် တစ်ခုခုထည့်သွင်းထားပါက ပြန်လည်ကောင်းမွန်လာမှု အခြေအနေ သို့မဟုတ် ပြသမှုများ ပြန်လည်ရယူရန် ဆိုင်းငံ့ထားသည်ပစ်မှတ်ထားပြင်ဆင်မှုများအတွက် ချိတ်ဆက်ထားသောလမ်းညွှန်ချက်များကို ကြည့်ပါ။

မေး- primary မရနိုင်တဲ့အခါ failover ကို ဘယ်လို force လုပ်ရမလဲ။

A: ဒုတိယမိတ္တူတစ်ခုနှင့် ချိတ်ဆက်ပြီး ALTER AVAILABILITY GROUP AG_Name FORCE_FAILOVER_ALLOW_DATA_LOSS ကို လုပ်ဆောင်ပါ။ ၎င်းသည် ဒေတာဆုံးရှုံးမှုဖြစ်နိုင်ခြေကို သိရှိပြီး ဒုတိယမိတ္တူကို မူလမိတ္တူအဖြစ် ချက်ချင်းမြှင့်တင်ပေးသည်။

မေး- ဘာကြောင့် client တွေက ကျွန်တော့်ရဲ့ listener နဲ့ ချိတ်ဆက်လို့မရတာလဲ။

A: Failover Cluster Manager မှာ listener ဟာ online ဖြစ်နေကြောင်း၊ DNS registration အောင်မြင်ကြောင်း၊ listener IP အားလုံးကို client တွေဆီကနေ ဆက်သွယ်နိုင်ကြောင်းနဲ့ firewall rules တွေက listener port ကို traffic ခွင့်ပြုကြောင်း အတည်ပြုပါ။

မေး- ပြန်လည်ပြုပြင်ရန် တန်းစီစောင့်ဆိုင်းမှု များပြားခြင်းဆိုတာ ဘာကိုဆိုလိုတာလဲ။

A: redo queue ကြီးကြီးမားမားရှိနေခြင်းက ဒုတိယမိတ္တူသည် log မှတ်တမ်းများရောက်ရှိလာသည့်အတိုင်း မြန်မြန်မလုပ်ဆောင်နိုင်ကြောင်း ဖော်ပြသည်။ ၎င်းသည် disk I/O ပိတ်ဆို့မှုများ၊ CPU ကန့်သတ်ချက်များ သို့မဟုတ် ဒုတိယတွင် read-only query များမှ ပိတ်ဆို့ခြင်းကို ညွှန်ပြနိုင်သည်။

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

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

၅.၅ လိုင်စင်နှင့် ကုန်ကျစရိတ်ဆိုင်ရာ မေးခွန်းများ

မေး- Always On Availability Groups တွေကို ဘယ်လိုလိုင်စင်ချထားပေးလဲ။

A: SQL Server လိုင်စင်ရရှိမှုသည် edition နှင့် deployment model ပေါ်တွင် မူတည်ပါသည်။ Enterprise Edition ရရှိနိုင်မှုအုပ်စုများသည် replica အားလုံးတွင် Enterprise လိုင်စင်များ လိုအပ်သည်။ passive secondary replica များသည် အချို့သောအခြေအနေများအောက်တွင် အခမဲ့လိုင်စင်ရရှိရန် အရည်အချင်းပြည့်မီနိုင်သည်။

Q: သုံးလို့ရလား။ SQL Server ရရှိနိုင်မှုအဖွဲ့များအတွက် Developer Edition?

A: ဟုတ်ကဲ့၊ Developer Edition တွင် full availability groups support အပါအဝင် Enterprise Edition လုပ်ဆောင်ချက်အားလုံး ပါဝင်သည်။ သို့သော် ၎င်းကို ဖွံ့ဖြိုးတိုးတက်ရေးနှင့် စမ်းသပ်ခြင်းအတွက်သာ လိုင်စင်ချထားပေးပြီး ထုတ်လုပ်မှုအသုံးပြုမှုအတွက် မဟုတ်ပါ။

မေး- ဖတ်နိုင်သော ဒုတိယအဆင့်ဆော့ဖ်ဝဲများသည် အပိုလိုင်စင်များ လိုအပ်ပါသလား။

A: လိုင်စင်ချထားခြင်းသည် အခြေအနေပေါ် မူတည်ပါသည်။ ဘေးအန္တရာယ်ပြန်လည်ထူထောင်ရေးအတွက် passive secondary များသည် ယေဘုယျအားဖြင့် လိုင်စင်များ မလိုအပ်ပါ။ read-only workloads များကို ဝန်ဆောင်မှုပေးသော active secondary များသည် ယေဘုယျအားဖြင့် လိုင်စင်များ လိုအပ်သော်လည်း သတ်မှတ်ထားသော စည်းကမ်းချက်များ ကွဲပြားပါသည်။

မေး- အမြင့်ဆုံးရရှိနိုင်မှုရရှိရန် အခမဲ့နည်းလမ်းရှိပါသလား။ SQL Server?

A: SQL Server Express Edition သည် ရရှိနိုင်မှုအုပ်စုများကို မပံ့ပိုးပါ။ SQL Server Standard Edition သည် Basic Availability Groups များကို အောက်ပါမှစ၍ ပံ့ပိုးပေးပါသည်။ SQL Server ၂၀၁၆ ခုနှစ်တွင်၊ Standard Edition လိုင်စင်ကြေးများဖြင့် အခြေခံမြင့်မားသော ရရှိနိုင်မှုကို ပံ့ပိုးပေးပါသည်။

မေး- ဖြန့်ဝေထားသော ရရှိနိုင်မှုအုပ်စုများဆိုတာ ဘာတွေလဲ။

A: ဖြန့်ဝေထားသော ရရှိနိုင်မှုအုပ်စုများသည် သီးခြားရရှိနိုင်မှုအုပ်စုနှစ်ခုကို လွှမ်းခြုံထားသော ရရှိနိုင်မှုအုပ်စု၏ အထူးအမျိုးအစားတစ်ခုဖြစ်ပြီး ရိုးရာရရှိနိုင်မှုအုပ်စုများ၏ စွမ်းရည်များထက် ကျော်လွန်သော အခြေအနေများကို ဖြစ်စေသည်။ မိတ်ဆက်ခဲ့သည် SQL Server ၂၀၁၆ ခုနှစ်တွင် ဖြန့်ဝေထားသော ရရှိနိုင်မှုအဖွဲ့များသည် ချဲ့ထွင်မှုနှင့် ပထဝီဝင်ဆိုင်ရာ ဖြန့်ဖြူးမှုလိုအပ်ချက်များကို ကိုင်တွယ်ဖြေရှင်းကြသည်။

6 ။ ကောက်ချက်

6.1 အဓိကအချက်များ အကျဉ်းချုပ်

SQL Server Always On Availability Groups များသည် မစ်ရှင်-အရေးကြီးသော ဒေတာဘေ့စ်များအတွက် Microsoft ၏ ထိပ်တန်း မြင့်မားသော ရရှိနိုင်မှုနှင့် ဘေးအန္တရာယ် ပြန်လည်ထူထောင်ရေး ဖြေရှင်းချက်ကို ကိုယ်စားပြုသည်။ ၎င်းတို့သည် shared storage လိုအပ်ချက်များမပါဘဲ ဒေတာဘေ့စ်အဆင့် failover၊ workload များကို offload လုပ်ရန်အတွက် ဖတ်နိုင်သော ဒုတိယမိတ္တူများနှင့် ပြည့်စုံသော ဒေတာကာကွယ်မှုအတွက် ပြောင်းလွယ်ပြင်လွယ်ရှိသော ပထဝီဝင်ဖြန့်ဖြူးမှုကို ပေးဆောင်သည်။ ကဲ့သို့သော ဖြေရှင်းချက်များကို လုပ်ဆောင်နေဆဲ အဖွဲ့အစည်းများအတွက် သစ်တင်ပို့မှု or ပွား, ရရှိနိုင်မှုအဖွဲ့များသည် ပိုမိုခိုင်မာပြီး လုပ်ငန်းလည်ပတ်မှုအရ ရိုးရှင်းသော အဆင့်မြှင့်တင်မှုလမ်းကြောင်းကို ပေးဆောင်သည်။

၇.၂ Always On Availability Groups ကို ဘယ်အချိန်မှာ အသုံးပြုရမလဲ

အလိုအလျောက် failover စွမ်းရည်များဖြင့် database-level high availability လိုအပ်သည့်အခါ ရရှိနိုင်မှုအုပ်စုများကို ရွေးချယ်ပါ။ အရေးကြီးသောဒေတာဘေ့စ်များအတွက် သုညဒေတာဆုံးရှုံးမှုကာကွယ်မှု လိုအပ်သောအဖွဲ့အစည်းများသည် အလိုအလျောက် failover ပါရှိသော synchronous commit replicas များမှ အကျိုးကျေးဇူးရရှိကြသည်။ read-scale စွမ်းရည်များလိုအပ်သော application များသည် query workloads များကို ဖြန့်ဝေရန် ဖတ်ရှုနိုင်သော secondary replicas များကို အသုံးပြုကြသည်။

၆.၃ သင်၏ အကောင်အထည်ဖော်မှုကို စတင်ခြင်း

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

ကိုးကား

မိုက်ခရိုဆော့ဖ် တရားဝင်စာရွက်စာတမ်း- Always On availability group ဆိုတာ ဘာလဲ။
မိုက်ခရိုဆော့ဖ် တရားဝင်စာရွက်စာတမ်း- Always On Availability Groups များဖြင့် စတင်အသုံးပြုခြင်း
မိုက်ခရိုဆော့ဖ် တရားဝင်စာရွက်စာတမ်း- ဖြန့်ဝေထားသော ရရှိနိုင်မှုအုပ်စုများ

အာဘော်အကြောင်း

Yuan Sheng 10 နှစ်အထက်အတွေ့အကြုံရှိသောအကြီးတန်းဒေတာဘေ့စစီမံခန့်ခွဲသူ (DBA) SQL Server ပတ်ဝန်းကျင်နှင့် လုပ်ငန်းဒေတာဘေ့စ်စီမံခန့်ခွဲမှု။ သူသည် ဘဏ္ဍာရေးဝန်ဆောင်မှုများ၊ ကျန်းမာရေးစောင့်ရှောက်မှုနှင့် ကုန်ထုတ်လုပ်ငန်းအဖွဲ့အစည်းများရှိ ရာနှင့်ချီသော ဒေတာဘေ့စ်ပြန်လည်ရယူရေးအခြေအနေများကို အောင်မြင်စွာဖြေရှင်းနိုင်ခဲ့သည်။

Yuan သည် အထူးပြုသည်။ SQL Server ဒေတာဘေ့စ်ပြန်လည်ရယူခြင်း၊ မြင့်မားသောရရှိနိုင်မှုဖြေရှင်းချက်များနှင့် စွမ်းဆောင်ရည် ပိုမိုကောင်းမွန်အောင်ပြုလုပ်ခြင်း။ ၎င်း၏ကျယ်ပြန့်သောလက်တွေ့အတွေ့အကြုံတွင် multi-terabyte ဒေတာဘေ့စ်များကိုစီမံခန့်ခွဲခြင်း၊ Always On Availability Groups များကိုအကောင်အထည်ဖော်ခြင်းနှင့် မစ်ရှင်အရေးပါသောစီးပွားရေးစနစ်များအတွက် အလိုအလျောက်အရန်ကူးခြင်းနှင့် ပြန်လည်ရယူခြင်းမဟာဗျူဟာများ ဖော်ဆောင်ခြင်းတို့ပါဝင်သည်။

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

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

SQL Server အမြဲတမ်းဖွင့်ထားနိုင်သော ရရှိနိုင်မှုအဖွဲ့များ- အပြည့်အစုံလမ်းညွှန် [၂၀၂၆]

၁။ Always On Availability Groups များကို နားလည်ခြင်း

၁.၁ ၎င်းသည် အဘယ်အရာဖြစ်ပြီး မည်သို့အလုပ်လုပ်ပုံ