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

SQL Server Always On သည် Microsoft ၏ ပြည့်စုံသော မြင့်မားသော ရရှိနိုင်မှုနှင့် ဘေးအန္တရာယ် ပြန်လည်ထူထောင်ရေး ဖြေရှင်းချက်ဖြစ်ပြီး မိတ်ဆက်ခဲ့သည်။ SQL Server ၂၀၁၂။ ၎င်းသည် database mirroring နှင့် log shipping ကဲ့သို့သော ယခင်နည်းပညာများထက် သိသာထင်ရှားသော တိုးတက်မှုတစ်ခုကို ကိုယ်စားပြုပြီး downtime နှင့် data loss ကို အနည်းဆုံးဖြစ်အောင် လုပ်ဆောင်ပေးနေစဉ်တွင် data များကို စဉ်ဆက်မပြတ် ဝင်ရောက်ကြည့်ရှုနိုင်စေပါသည်။

၁.၂ စီးပွားရေးလုပ်ငန်းများသည် အဘယ်ကြောင့် အမြဲတမ်း လည်ပတ်နေသော ဖြေရှင်းချက်များ လိုအပ်သနည်း

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

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

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

၁.၃ အဓိက သဘောတရားများ- RTO၊ RPO၊ HA နှင့် DR

ပြန်လည်ရယူချိန် ရည်မှန်းချက် (RTO) ချို့ယွင်းမှုတစ်ခုပြီးနောက် လက်ခံနိုင်သော အများဆုံး downtime ကြာချိန်ကို သတ်မှတ်ပေးသည် - ဒေတာဘေ့စ် မည်မျှမြန်မြန် အွန်လိုင်းပြန်ဖြစ်ရမည်ကို သတ်မှတ်ပေးသည်။

Recovery Point Objective (RPO) အချိန်နှင့်အမျှ တိုင်းတာထားသော အများဆုံးလက်ခံနိုင်သော အချက်အလက်ဆုံးရှုံးမှုကို သတ်မှတ်ပေးသည် - မကြာသေးမီက လုပ်ငန်းမှ ကျူးလွန်ခဲ့သော အချက်အလက်မည်မျှ ဆုံးရှုံးနိုင်သည်ကို သတ်မှတ်ပေးသည်။

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

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

SQL Server Always On သည် HA နှင့် DR နှစ်မျိုးလုံးကို တစ်ခုတည်းသော ပေါင်းစည်းထားသော ဗိသုကာလက်ရာအတွင်း ပံ့ပိုးပေးပါသည်။ Synchronous-commit mode သည် RPO = 0 ကို သုညနီးပါး RTO အတွက် အလိုအလျောက် failover ဖြင့် ပေးပို့ပြီး ဝေးလံသောနေရာများတွင် latency သက်ရောက်မှု နည်းပါးစေရန်အတွက် လဲလှယ်ခြင်းဖြင့် ဖြစ်နိုင်ခြေရှိသော ဒေတာဆုံးရှုံးမှုကို လက်ခံပါသည်။

၁.၄ အမြဲတမ်းဖွင့်ထားသော ဖြေရှင်းချက်များ

SQL Server Always On မှာ ကွဲပြားတဲ့ ရရှိနိုင်မှုနဲ့ အခြေခံအဆောက်အအုံ လိုအပ်ချက်တွေနဲ့ ကိုက်ညီတဲ့ ဖြန့်ကျက်မှု ရွေးချယ်စရာ သုံးခု ပါရှိပါတယ်။ ဒီလမ်းညွှန်ချက်က သုံးခုစလုံးကို လွှမ်းခြုံထားပါတယ်-

အမြဲတမ်းဖွင့်ထားနိုင်သော ရရှိနိုင်မှုအဖွဲ့များ (AG): မျှဝေသိမ်းဆည်းခြင်းမရှိဘဲ ဒေတာဘေ့စ်အဆင့် မြင့်မားစွာရရှိနိုင်မှုနှင့် ဘေးအန္တရာယ်ပြန်လည်ထူထောင်ခြင်း။
Always On Failover Cluster Instances (FCI): မျှဝေသိုလှောင်မှုကို အသုံးပြု၍ Instance-level မြင့်မားစွာ ရရှိနိုင်မှု။
AG + FCI ပေါင်းစပ်ထားသည်- အမြင့်ဆုံးခံနိုင်ရည်ရှိစေရန်အတွက် instance-level နှင့် database-level failover တို့ကို ပေါင်းစပ်ထားသော အလွှာနှစ်ထပ်ကာကွယ်မှု။

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

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

၃.၂ အဓိကအင်္ဂါရပ်များ

ဒေတာဘေ့စ်အဆင့် ချို့ယွင်းမှု- တစ်ဦးချင်းဒေတာဘေ့စ်များ သို့မဟုတ် အုပ်စုများသည် သီးခြားစီ ချို့ယွင်းနိုင်သည် SQL Server ဥပမာ;
Enterprise Edition မှာ ပုံတူကိုးခုအထိ (အဓိကတစ်ခု၊ ဒုတိယရှစ်ခု)။
ဒေတာဆုံးရှုံးမှု သုညအတွက် synchronous-commit မုဒ်၊ ဝေးလံသော DR ပုံတူများအတွက် asynchronous-commit။
မူလမိတ္တူများ မရရှိနိုင်တော့သည့်အခါ synchronous replicas များအတွက် အလိုအလျောက် failover;
အစီရင်ခံစာများ လျှော့ချခြင်းနှင့် အရန်ကူးယူခြင်း လုပ်ငန်းပမာဏများအတွက် ဖတ်နိုင်သော ဒုတိယမိတ္တူများ။
availability group listener သည် လက်ရှိ primary သို့ အလိုအလျောက် လမ်းကြောင်းပြောင်းပေးသည့် single connection endpoint တစ်ခုကို ပေးသည်။

2.2 အကောင်အထည်ဖော်ရေး အဆင့်များ

Active Directory ဝန်ဆောင်မှုအကောင့်များကို ပြင်ဆင်ပြီး node အားလုံးတွင် ခွင့်ပြုချက်များကို configure လုပ်ပါ။
ပါဝင်သောဆာဗာအားလုံးတွင် Windows Server Failover Clustering ကို ထည့်သွင်းပြီး အတည်ပြုပါ။
install SQL Server တသမတ်တည်းရှိသော လမ်းကြောင်းများနှင့် ဆက်တင်များကို အသုံးပြု၍ node တစ်ခုချင်းစီတွင် standalone instance အဖြစ်၊
Always On Availability Groups လုပ်ဆောင်ချက်ကို အောက်ပါမှတစ်ဆင့် ဖွင့်ပါ SQL Server ဖွဲ့စည်းပုံမန်နေဂျာ သို့မဟုတ် PowerShell;
ဒေတာဘေ့စ်များကို full recovery model သို့သတ်မှတ်ပြီး full backup များယူကာ မှတ်တမ်းတင်ပါ။
ရရှိနိုင်မှုအုပ်စုကို ဖန်တီးပါ၊ ပုံတူများကို ထည့်သွင်းပါ၊ နှင့် ရရှိနိုင်မှုနှင့် failover မုဒ်များကို ပြင်ဆင်သတ်မှတ်ပါ။
အလိုအလျောက် စိုက်ပျိုးခြင်း သို့မဟုတ် ကိုယ်တိုင် အရန်ကူးယူခြင်းနှင့် ပြန်လည်ရယူခြင်းကို အသုံးပြု၍ ဒုတိယမိတ္တူများကို မျိုးစေ့ချပါ။
ရရှိနိုင်မှုအုပ်စု နားထောင်သူကို ဖန်တီးပြီး client ချိတ်ဆက်မှုကို အတည်ပြုပါ။

အဆင့်ဆင့် လုပ်ဆောင်ပုံအပြည့်အစုံအတွက်၊ ကျွန်ုပ်တို့၏ Always On Availability Groups လမ်းညွှန်အပြည့်အစုံ.

2.3 အတွက် အကောင်းဆုံး

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

2.4 အားသာချက်များ

မျှဝေသိမ်းဆည်းရန် မလိုအပ်ပါ — ပုံတူတစ်ခုစီသည် သီးခြားဒေသခံသိမ်းဆည်းမှုကို အသုံးပြုသည်။
HA နှင့် DR နှစ်မျိုးလုံးကို တစ်ခုတည်းသော configuration တွင် ပံ့ပိုးပေးသည်။
ဖတ်နိုင်သော ဒုတိယအဆင့်များသည် အဓိက အလုပ်ဝန်ကို လျှော့ချပေးသည်။
ဒေတာဘေ့စ်အဆင့် အသေးစိတ်အချက်အလက်များသည် ဒေတာဘေ့စ်အုပ်စုတစ်ခုစီအတွက် မတူညီသော failover မူဝါဒများကို ခွင့်ပြုသည်။

2.5 Cons

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

၁၀ ကိုးကား

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

၃။ အမြဲတမ်း Failover Cluster Instances များဖွင့်ထားခြင်း

အမြဲတမ်းဖွင့်ထားသော Failover Cluster Instances (FCI) single တစ်ခုကို လုပ်ဆောင်ခြင်းဖြင့် instance-level high availability ကို ပေးစွမ်းသည် SQL Server တူညီသော storage ကို မျှဝေသည့် physical node များစွာတွင် instance ကို လုပ်ဆောင်သည်။ active node ပျက်ကွက်သွားသောအခါ၊ SQL Server standby node ပေါ်ရှိ instance ကို အလိုအလျောက် ပြန်လည်စတင်ပြီး client application များအတွက် transition ကို transparent ဖြစ်စေသည်။

၃.၂ အဓိကအင်္ဂါရပ်များ

Instance-level failover: instance ရှိ database အားလုံးသည် တစ်ခုတည်းသော unit အနေဖြင့် အတူတကွ fail over ဖြစ်သွားသည်။
node အားလုံးမှ ဝင်ရောက်အသုံးပြုနိုင်သော shared storage (Storage Area Network (SAN), iSCSI, Storage Spaces Direct, သို့မဟုတ် SMB);
virtual network name နှင့် virtual IP address သည် မည်သည့် node သည် active ဖြစ်နေပါစေ တည်ငြိမ်သော connection endpoint ကို ပေးစွမ်းသည်။
Windows Server Failover Clustering သည် node ကျန်းမာရေးစောင့်ကြည့်ခြင်း၊ quorum နှင့် failover orchestration တို့ကို စီမံခန့်ခွဲသည်။
Active/Standby၊ Active/Active၊ N+1 နှင့် N+M node configuration အမျိုးအစားများကို ပံ့ပိုးပေးသည်။

3.2 အကောင်အထည်ဖော်ရေး အဆင့်များ

cluster node အားလုံးသို့ shared storage ကို ပံ့ပိုးပေးပြီး ချိတ်ဆက်ပါ။
Failover Clustering လုပ်ဆောင်ချက်ကို ထည့်သွင်းပြီး cluster configuration ကို အတည်ပြုပါ။
Windows Server Failover Cluster ကို ဖန်တီးပြီး quorum ကို configure လုပ်ပါ။
ပြေးပါ SQL Server failover cluster option ကိုရွေးချယ်ခြင်းနှင့် virtual network name နှင့် shared storage paths များကိုသတ်မှတ်ခြင်း installation;
node အပိုတွေထည့်ပါ SQL Server failover cluster ဖြစ်ရပ်;
node များအကြား ကိုယ်တိုင် failover တစ်ခုကို စမ်းသပ်ခြင်းဖြင့် failover အပြုအမူကို အတည်ပြုပါ။

အဆင့်ဆင့် လုပ်ဆောင်ပုံအပြည့်အစုံအတွက်၊ ကျွန်ုပ်တို့၏ SQL Server Failover Cluster လမ်းညွှန်အပြည့်အစုံ.

3.3 အတွက် အကောင်းဆုံး

ရှိပြီးသား မျှဝေသိုလှောင်မှု အခြေခံအဆောက်အအုံ (SAN သို့မဟုတ် iSCSI) ရှိသော ပတ်ဝန်းကျင်များ။
ဒေတာဘေ့စ်အားလုံး အတူတကွ ပျက်ကွက်ရမည့် instance-level failover လိုအပ်သည့် application များ။
client transparency အရေးကြီးပြီး application-side ပြောင်းလဲမှုများကို လက်ခံနိုင်ခြင်းမရှိသည့် အခြေအနေများ။
single-instance failover model ၏ ရိုးရှင်းမှုကို ဦးစားပေးသော အဖွဲ့အစည်းများ။

3.4 အားသာချက်များ

client ပြန်လည်ပြင်ဆင်သတ်မှတ်ရန် မလိုအပ်ဘဲ instance level တွင် အလိုအလျောက် failover လုပ်ဆောင်နိုင်ခြင်း။
data replication overhead မရှိပါ — node အားလုံးသည် တူညီသော storage ကို ဝင်ရောက်အသုံးပြုကြသည်။
ဒေတာဘေ့စ်အားလုံးတစ်ပြိုင်နက်တည်းအတွက် ခန့်မှန်းနိုင်သော failover အပြုအမူ။
ဟာ့ဒ်ဝဲအသုံးပြုမှုကို အကောင်းဆုံးဖြစ်စေရန် ပြောင်းလွယ်ပြင်လွယ်ရှိသော node configuration များ (Active/Active၊ N+1၊ N+M) ကို ပံ့ပိုးပေးသည်။

3.5 Cons

သိုလှောင်မှုကိုယ်တိုင်က မလိုအပ်ဘူးဆိုရင် မျှဝေသိုလှောင်မှုဟာ ပျက်ကွက်နိုင်ခြေရှိတဲ့ တစ်ခုတည်းသောအချက်ပါ။
node တစ်ခုတည်းသာ လည်ပတ်သည် SQL Server တစ်ချိန်တည်းတွင် — ဒုတိယ node များတွင် read load balancing မရှိပါ။
Availability group နှင့် တွဲဖက်မပါဝင်ဘဲ built-in disaster recovery မရှိပါ။
မျှဝေသိုလှောင်မှု အခြေခံအဆောက်အအုံသည် AG နှင့် နှိုင်းယှဉ်ပါက ကုန်ကျစရိတ်နှင့် ရှုပ်ထွေးမှုကို တိုးစေသည်။

၁၀ ကိုးကား

မိုက်ခရိုဆော့ဖ် တရားဝင်စာရွက်စာတမ်း- အမြဲတမ်းဖွင့်ထားသော Failover Cluster Instances များ (SQL Server)

၄။ Availability Group များကို Failover Cluster Instances များနှင့် ပေါင်းစပ်ပါ။

instance-level နှင့် database-level protection နှစ်မျိုးလုံး လိုအပ်သော အဖွဲ့အစည်းများအတွက်၊ SQL Server Failover Cluster Instances (FCI) တွင် availability group replicas များကို hosting လုပ်ခြင်းကို ပံ့ပိုးပေးသည်။ ဤ configuration တွင် FCI node တစ်ခုစီသည် availability replica တစ်ခုတည်းအဖြစ် လုပ်ဆောင်သောကြောင့် FCI failover သည် availability group အတွက် ပွင့်လင်းမြင်သာပြီး AG failover သည် site များတစ်လျှောက် database-level protection ကို ပေးစွမ်းသည်။ ဤပေါင်းစပ်မှုသည် ရရှိနိုင်သော အပြည့်စုံဆုံး high availability နှင့် disaster recovery coverage ကို ပေးစွမ်းသည်။ SQL Server.

၃.၂ အဓိကအင်္ဂါရပ်များ

အလွှာနှစ်ထပ် failover: FCI သည် instance-level node ပျက်ကွက်မှုများကို ကိုင်တွယ်သည်။ AG သည် site-level သို့မဟုတ် replica-level ပျက်ကွက်မှုများကို ကိုင်တွယ်သည်။
FCI တွင် node မည်မျှပါဝင်သည်ဖြစ်စေ FCI တစ်ခုစီသည် availability group အတွင်း တစ်ခုတည်းသော replica အဖြစ် ရေတွက်သည်။
FCI-hosted မိတ္တူများသည် FCI စံလိုအပ်ချက်များအတိုင်း shared storage လိုအပ်နေဆဲဖြစ်သည်။
FCI များတွင် host လုပ်ထားသော AG မိတ္တူများသည် manual failover ကိုသာ ပံ့ပိုးပေးသည် — FCI-host လုပ်ထားသော မိတ္တူများအတွက် အလိုအလျောက် failover မရရှိနိုင်ပါ။
သီးခြား instance များသည် FCI-hosted replicas များနှင့်အတူ တူညီသော availability group တွင် ပါဝင်နိုင်သည်။

4.2 အကောင်အထည်ဖော်ရေး အဆင့်များ

စံ FCI စနစ်ထည့်သွင်းမှုလုပ်ထုံးလုပ်နည်းများကို လိုက်နာ၍ FCI တစ်ခုချင်းစီကို သီးခြားစီ ဖြန့်ကျက်ပြီး အတည်ပြုပါ။
FCI node အားလုံးနှင့် standalone replica node အားလုံးသည် Windows Server Failover Cluster တစ်ခုတည်းနှင့် သက်ဆိုင်ကြောင်း သေချာပါစေ။
FCI instance တစ်ခုချင်းစီတွင် Always On Availability Groups လုပ်ဆောင်ချက်ကို ဖွင့်ပါ။
ဖြစ်နိုင်ချေရှိသော FCI failover ပြီးနောက်တွင် WSFC node တစ်ခုတည်းမှ တူညီသော availability group ၏ မိတ္တူနှစ်ခုကို host မလုပ်ကြောင်း အတည်ပြုပါ။
FCI instance များကို replica များအဖြစ် သတ်မှတ်ပြီး FCI-hosted replica အားလုံးအတွက် manual failover mode ကို configure လုပ်ခြင်း၊ availability group ကို ဖန်တီးပါ။
ဒုတိယမိတ္တူများကို seed လုပ်ပြီး availability group listener ကို configure လုပ်ပါ။

FCI စနစ်ထည့်သွင်းမှုအသေးစိတ်အတွက်၊ ကျွန်ုပ်တို့၏ SQL Server Failover Cluster အပြည့်အစုံလမ်းညွှန်။ AG စနစ်ထည့်သွင်းမှုအသေးစိတ်အတွက် ကျွန်ုပ်တို့၏ Always On Availability Groups အပြည့်အစုံလမ်းညွှန်ကို ကြည့်ပါ။

4.3 အတွက် အကောင်းဆုံး

တစ်ဦးချင်း node ပျက်ကွက်မှုများနှင့် site-level ဘေးအန္တရာယ်နှစ်မျိုးလုံးမှ ကာကွယ်ရန် လိုအပ်သော မစ်ရှင်-အရေးပါသောပတ်ဝန်းကျင်များ၊
cross-site disaster recovery ကို ထည့်သွင်းရန် လိုအပ်သော FCI ကို လည်ပတ်နေသော အဖွဲ့အစည်းများ။
အမြင့်ဆုံးဒေတာကာကွယ်မှုနှင့် ရရှိနိုင်မှုဆိုင်ရာ SLA များကို မဖြစ်မနေလိုက်နာရမည့် စည်းမျဉ်းသတ်မှတ်ထားသော စက်မှုလုပ်ငန်းများ။
instance-level နှင့် database-level failover မူဝါဒများ တစ်ပြိုင်တည်းတည်ရှိရမည့် ကြီးမားသော ဖြန့်ကျက်မှုများ။

4.4 အားသာချက်များ

အမြင့်ဆုံးကာကွယ်မှု- FCI မှ node ချို့ယွင်းချက်များကို ကိုင်တွယ်ဖြေရှင်းပြီး၊ site ချို့ယွင်းချက်များကို AG မှ ကိုင်တွယ်ဖြေရှင်းသည်။
FCI failover သည် availability group အတွက် ပွင့်လင်းမြင်သာမှုရှိသည် — AG သည် FCI failover အတွင်း ပုံတူပြောင်းလဲမှုကို မတွေ့ရပါ။
ပြောင်းလွယ်ပြင်လွယ်ရှိသော topology: FCI-hosted နှင့် standalone replicas များကို တူညီသော availability group တွင် ရောနှောထားသည်။

4.5 Cons

FCI-hosted replicas များသည် manual AG failover ကိုသာ ပံ့ပိုးပေးသည် — ဤ replicas များအတွက် အလိုအလျောက် AG failover ကို မရရှိနိုင်ပါ။
FCI failover တစ်ခုပြီးနောက် node တစ်ခုသည် AG ၏ replicas နှစ်ခုကို hosting မလုပ်စေရန် WSFC node စီစဉ်ခြင်းကို ဂရုတစိုက်ပြုလုပ်ရန် လိုအပ်ပါသည်။
AG သို့မဟုတ် FCI တစ်ခုတည်းထက် အခြေခံအဆောက်အအုံကုန်ကျစရိတ်နှင့် လုပ်ငန်းလည်ပတ်မှုရှုပ်ထွေးမှု ပိုမိုမြင့်မားခြင်း။
FCI အစိတ်အပိုင်းတစ်ခုစီအတွက် shared storage လိုအပ်နေဆဲဖြစ်သည်။

၁၀ ကိုးကား

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

၅။ အမြဲတမ်းဖွင့်ထားသော ဖြေရှင်းချက်များ နှိုင်းယှဉ်ခြင်း

၁၁.၁ အင်္ဂါရပ်နှိုင်းယှဉ်ဇယား

လက္ခဏာ	ရရှိနိုင်မှုအုပ်စုများ	Failover Cluster Instances များ	AG + FCI ပေါင်းစပ်
ပျက်ကွက်မှုအတိုင်းအတာ	ဒေတာဘေ့စ်အဆင့်	ဖြစ်ရပ်အဆင့်	နှစ်ခုလုံး
မျှဝေသိုလှောင်မှု လိုအပ်သည်	အဘယ်သူမျှမ	Yes	ဟုတ်ကဲ့ (FCI အစိတ်အပိုင်းအတွက်)
ဒေတာ ကူးယူခြင်း	ပုံတူတစ်ခုစီအတွက် မှတ်တမ်းအခြေပြု	မရှိပါ (မျှဝေသိုလှောင်မှု)	FCI များအကြား Log-based
အလိုအလျောက် ပျက်ကွက်ခြင်း။	ဟုတ်ကဲ့ (တစ်ပြိုင်တည်းမိတ္တူများ)	Yes	FCI: ဟုတ်ကဲ့၊ AG: မဟုတ်ပါ
ဖတ်နိုင်သော ဒုတိယစာများ	Yes	အဘယ်သူမျှမ	ဟုတ်ကဲ့ (AG အစိတ်အပိုင်း)
သဘာဝဘေးပြန်လည်နာလန်ထူ	built-in	built-in မဟုတ်ပါ။	built-in
အများဆုံးမိတ္တူများ	၉ (လုပ်ငန်း)	N / A	၉ (လုပ်ငန်း)
အခြေခံအဆောက်အအုံ ရှုပ်ထွေးမှု	အလယ်အလတ်	အလယ်အလတ်	မြင့်သော
ပေးရ	ပိုနိမ့်သော (SAN မလိုအပ်ပါ)	ပိုမိုမြင့်မားသော (SAN လိုအပ်သည်)	အမြင့်ဆုံး

၅.၂ သင့်ရဲ့ အမြဲတမ်းဖွင့်ထားတဲ့ ဖြေရှင်းချက်ကို ရွေးချယ်ပါ

သင့်ရဲ့ storage infrastructure ကနေစပါ- shared storage မရှိသေးဘူးဆိုရင် Availability Groups က သဘာဝရွေးချယ်မှုဖြစ်ပြီး HA နဲ့ DR နှစ်ခုလုံးအတွက် ကုန်ကျစရိတ်အသက်သာဆုံးလမ်းကြောင်းပါ။ SAN environment ကို လည်ပတ်နေပြီး instance-level failover လိုအပ်ရင် FCI က ပိုရိုးရှင်းတဲ့ရွေးချယ်မှုပါ — ဒါပေမယ့် cross-site DR က အနာဂတ်မှာ လိုအပ်ချက်တစ်ခုဖြစ်ရင် AG ကို နောက်မှထပ်ထည့်ဖို့ စီစဉ်ပါ။

တိုးလာသောရှုပ်ထွေးမှုကို စီမံခန့်ခွဲရန်အတွက် ကာကွယ်မှုအလွှာနှစ်ခုလုံးနှင့် လုပ်ငန်းလည်ပတ်မှုရင့်ကျက်မှုနှစ်ခုလုံးကို အမှန်တကယ်လိုအပ်သည့်အခါတွင်သာ AG + FCI ပေါင်းစပ်မှုကို ရွေးချယ်ပါ။ မှတ်သားထားရမည့် အဓိကကန့်သတ်ချက်မှာ FCI-hosted AG replicas များသည် အလိုအလျောက် AG failover ကို မပံ့ပိုးသောကြောင့် ဤ topology သည် availability group-level failovers များအတွက် manual intervention လိုအပ်ပါသည်။

ယနေ့ခေတ် greenfield အများစုတွင် ဖြန့်ကျက်မှုများအတွက် Always On Availability Groups သည် အကြံပြုထားသော စတင်သည့်နေရာဖြစ်သည်- ၎င်းသည် HA နှင့် DR နှစ်မျိုးလုံးကို လွှမ်းခြုံထားပြီး shared storage မလိုအပ်ဘဲ readable secondary များကို ပံ့ပိုးပေးသည် — FCI တစ်ခုတည်းဖြင့် မယှဉ်နိုင်သော စွမ်းရည်များဖြစ်သည်။

6. အကောင်းဆုံးအလေ့အကျင့်များ SQL Server အမြဲတမ်းဖွင့်ထားသော ဖြေရှင်းချက်များ

6.1 စီမံကိန်းနှင့် ဒီဇိုင်း

Always On solution ကို မရွေးချယ်မီ RTO နှင့် RPO လိုအပ်ချက်များကို သတ်မှတ်ပါ — ဤပစ်မှတ်များသည် synchronous သို့မဟုတ် asynchronous commit mode သင့်လျော်မှုရှိမရှိနှင့် automatic failover လုပ်ဆောင်နိုင်ခြင်းရှိမရှိကို တိုက်ရိုက်ဆုံးဖြတ်ပေးသည်။
အမြင့်ဆုံးဝန်အား အခြေအနေများ အပါအဝင် failover event အတွင်း primary workload အပြည့်အစုံကို ကိုင်တွယ်ရန် secondary replicas များကို အရွယ်အစားသတ်မှတ်ပါ။
AG ဖြန့်ကျက်မှုများအတွက်၊ ရေးသားမှု နှောင့်နှေးမှုသက်ရောက်မှုကို လျှော့ချရန်အတွက် synchronous replicas များကို တူညီသော data center သို့မဟုတ် low-latency network တွင်ထားပါ။ ပထဝီဝင်အနေအထားအရ ဝေးကွာသော DR replicas များအတွက် asynchronous mode ကို သီးသန့်ထားပါ။
မဲအရေအတွက် စုံကိန်းဖြင့် ဒီဇိုင်း quorum။ two-node cluster များအတွက် split-brain scenarios များကို ကာကွယ်ရန် file share သို့မဟုတ် cloud witness ကို တတိယမဲအဖြစ် ထည့်ပါ။
multi-subnet ဖြန့်ကျက်မှုများအတွက် သင့်ကွန်ရက် topology ကို ဂရုတစိုက်စီစဉ်ပါ။ subnet တစ်ခုစီတွင် ၎င်း၏ကိုယ်ပိုင် listener IP address လိုအပ်ပြီး client များသည် ၎င်းတို့၏ connection strings များတွင် MultiSubnetFailover=True လိုအပ်သည်။

၁၂.၂ အကောင်အထည်ဖော်မှုလမ်းညွှန်ချက်များ

တသမတ်တည်းအသုံးပြုပါ SQL Server မိတ္တူအားလုံးတွင် ဗားရှင်း၊ ထုတ်ဝေမှုနှင့် စုစုပေါင်း အပ်ဒိတ်အဆင့်များ။ ရောနှောထားသော patch အဆင့်များသည် failover အတွင်း မမျှော်လင့်ထားသော အပြုအမူကို ဖြစ်ပေါ်စေနိုင်သည်။
အပလီကေးရှင်းအသွားအလာနှင့် သီးခြားစီ cluster heartbeat traffic အတွက် သီးသန့်ကွန်ရက် interface များကို ပြင်ဆင်သတ်မှတ်ပါ။
ကနဦးဒေတာဘေ့စ်ထပ်တူပြုခြင်းအတွက် အလိုအလျောက် seeding ကိုဖွင့်ပါ SQL Server ၂၀၁၆ နှင့် နောက်ပိုင်း — အခြေအနေအများစုအတွက် အရန်ကူးယူမှုများကို ဒုတိယမိတ္တူများသို့ ကိုယ်တိုင်ကူးယူရန် မလိုအပ်တော့ပါ။
AG + FCI topologies အတွက်၊ FCI node configuration ပြောင်းလဲမှုတိုင်းပြီးတိုင်း WSFC node တစ်ခုတည်းမှ တူညီသော availability group ၏ replicas နှစ်ခုကို hosting မလုပ်နိုင်ကြောင်း အတည်ပြုပါ။
အမြဲတမ်းအသုံးပြုပါ SQL Server ရရှိနိုင်မှုအုပ်စု ပျက်ကွက်မှုများကို စီမံခန့်ခွဲရန် Management Studio သို့မဟုတ် Transact-SQL — Failover Cluster Manager သည် AG ထပ်တူပြုခြင်းအခြေအနေကို မသိရှိဘဲ ကြာရှည်စွာ ရပ်တန့်ခြင်း သို့မဟုတ် အချက်အလက်ဆုံးရှုံးမှုကို ဖြစ်စေနိုင်သောကြောင့် တိုက်ရိုက်မသုံးပါနှင့်။

6.3 စောင့်ကြည့်ထိန်းသိမ်းခြင်း။

availability group dashboard ကို အသုံးပြု၍ synchronization အခြေအနေကို စောင့်ကြည့်ခြင်း၊ queue ပေးပို့ခြင်းနှင့် queue ကို ပုံမှန်ပြန်လည်လုပ်ဆောင်ခြင်း SQL Server Management Studio သို့မဟုတ် Dynamic Management Views (DMVs)။ ဒုတိယအဆင့်တွင် redo queue များ တိုးပွားလာခြင်းသည် failover recovery ကို နှောင့်နှေးစေမည့် I/O bottleneck ကို ညွှန်ပြသည်။
primary မှ integrity check များကို offload လုပ်ရန် secondary replicas များတွင် DBCC CHECKDB ကို run ပါ။ ကျွန်ုပ်တို့၏ အချက်အလက်များကို ကြည့်ပါ။ DBCC CHECKDB လမ်းညွှန် အသေးစိတျအဘို့။
Apply SQL Server rolling upgrades များကို အသုံးပြု၍ patches များ- secondary replicas များကို ဦးစွာ patch လုပ်ပါ၊ patched secondary သို့ စီစဉ်ထားသော manual failover တစ်ခုကို လုပ်ဆောင်ပါ၊ ထို့နောက် ယခင် primary ကို patch လုပ်ပါ။ ၎င်းသည် downtime ကို တစ်ကြိမ်တည်းသော failover ကြာချိန်အထိ ကန့်သတ်ထားသည်။
ထုတ်လုပ်မှုမဟုတ်သောပတ်ဝန်းကျင်များတွင် failover ကို မှန်မှန်စမ်းသပ်ပါ။ တစ်ခါမှ မစမ်းသပ်ဖူးသော အလိုအလျောက် failover သည် ယုံကြည်စိတ်ချရသော ပြန်လည်ရယူခြင်းဗျူဟာမဟုတ်ပါ။
ရရှိနိုင်မှုအုပ်စု ကျန်းမာရေးအခြေအနေပြောင်းလဲမှုများ၊ ပုံတူအခန်းကဏ္ဍအကူးအပြောင်းများနှင့် ထပ်တူပြုခြင်းပျက်ကွက်မှုများအတွက် သတိပေးချက်များကို ပြင်ဆင်သတ်မှတ်ပါ- SQL Server အေးဂျင့် သို့မဟုတ် သီးသန့်စောင့်ကြည့်ရေးကိရိယာတစ်ခု ကဲ့သို့သော SQL Server performance ု့ကပ်ရေး.

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

မေး: ဘာလဲ SQL Server အမြဲတမ်းဖွင့်ထားလား။

A: SQL Server Always On သည် Microsoft ၏ မြင့်မားသော ရရှိနိုင်မှုနှင့် ဘေးအန္တရာယ် ပြန်လည်ထူထောင်ရေး ပလက်ဖောင်းဖြစ်ပြီး မိတ်ဆက်ခဲ့သည် SQL Server ၂၀၁၂။ ၎င်းတွင် ဟာ့ဒ်ဝဲ၊ ဆော့ဖ်ဝဲ သို့မဟုတ် ဆိုက်ချို့ယွင်းမှုများဖြစ်ပွားပါက အလိုအလျောက် failover၊ data redundancy နှင့် ဒေတာဘေ့စ်များသို့ စဉ်ဆက်မပြတ်ဝင်ရောက်ခွင့်ပေးသည့် နည်းပညာနှစ်ခု — Always On Availability Groups နှင့် Always On Failover Cluster Instances — တို့ပါဝင်သည်။

မေး- Always On Availability Groups နှင့် Failover Cluster Instances တို့၏ ကွာခြားချက်ကား အဘယ်နည်း။

A: Availability Groups များသည် database level တွင် လုပ်ဆောင်ပြီး log shipping မှတစ်ဆင့် independent secondary replicas များသို့ data များကို ပုံတူကူးယူကာ shared storage မလိုအပ်ပါ။ Failover Cluster Instances များသည် instance level တွင် လုပ်ဆောင်ပြီး node အားလုံးမှ ဝင်ရောက်အသုံးပြုနိုင်သော shared storage လိုအပ်သည်။ ထို့အပြင် database အားလုံးကို unit တစ်ခုအဖြစ် fail over လုပ်ရန် လိုအပ်ပါသည်။ AG သည် readable secondary များနှင့် built-in DR ကို ပံ့ပိုးပေးသော်လည်း FCI တွင် ပံ့ပိုးပေးခြင်း မရှိပါ။

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

A: မဟုတ်ပါ။ AG ပုံတူတစ်ခုစီသည် ဒေသတွင်းသိုလှောင်မှုပေါ်ရှိ ဒေတာဘေ့စ်များ၏ ၎င်း၏ကိုယ်ပိုင်လွတ်လပ်သောမိတ္တူကို ထိန်းသိမ်းထားသည်။ AG ပုံတူများကို လက်ခံသိမ်းဆည်းရန် Failover Cluster Instances များကို အသုံးပြုမှသာ shared storage လိုအပ်ပါသည်။

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

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

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

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

မေး- FCI-hosted replicas များသည် automatic AG failover ကို အသုံးပြုနိုင်ပါသလား။

A: မဟုတ်ပါ။ ရရှိနိုင်မှုမိတ္တူတစ်ခုကို Failover Cluster Instance တွင် ထားရှိသည့်အခါ၊ ထိုမိတ္တူအတွက် အလိုအလျောက်ရရှိနိုင်မှုအုပ်စု ပျက်ကွက်မှုကို ပံ့ပိုးမပေးပါ။ FCI-ထားရှိထားသော မိတ္တူများပါဝင်သည့် AG ပျက်ကွက်မှုအားလုံးသည် ကိုယ်တိုင်ဝင်ရောက်စွက်ဖက်မှု လိုအပ်ပါသည်။

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

A: Synchronous-commit mode မှာ primary က secondary log record တွေကို commit မလုပ်ခင် harden လုပ်ဖို့ စောင့်ရပါမယ်။ write latency ထပ်ပေါင်းထည့်ရင် data loss (RPO = 0) လုံးဝမရှိပါဘူး။ Asynchronous-commit mode မှာ primary က စောင့်စရာမလိုဘဲ commit လုပ်နိုင်ပါတယ်။ latency ကို လျှော့ချပေးပေမယ့် primary က log record အားလုံးကို မရခင် error တက်ရင် data loss ဖြစ်နိုင်ခြေများပါတယ်။ local HA replicas တွေအတွက် synchronous ကိုသုံးပါ။ distance DR replicas တွေအတွက် asynchronous ကိုသုံးပါ။

မေး။ ဘယ်လောက်ကြာမလဲ SQL Server အမြဲတမ်း failover လုပ်လို့ရလား။

A: synchronous AG replica အတွက် အလိုအလျောက် failover သည် ပုံမှန်အခြေအနေများတွင် စက္ကန့် ၃၀ အောက်အတွင်း ပြီးမြောက်လေ့ရှိသည်။ FCI failover သည် database recovery အချိန်ပေါ် မူတည်၍ စက္ကန့် ၂၀ မှ ၆၀ အထိ ကြာတတ်သည်။ အမှန်တကယ်ကြာချိန်သည် workload၊ database အရွယ်အစားနှင့် WSFC တွင် configure လုပ်ထားသော health check timeout setting များပေါ်တွင် မူတည်သည်။

မေး- failover လုပ်နေစဉ်အတွင်း client connection တွေ ဘာဖြစ်သွားလဲ။

A: failover ဖြစ်ပေါ်သောအခါ ရှိပြီးသား ချိတ်ဆက်မှုများ ပြတ်တောက်သွားပါသည်။ availability group listener ကိုအသုံးပြုပြီး connection retry logic ပါဝင်သော application များသည် failover ပြီးဆုံးပြီးနောက် primary အသစ်သို့ အလိုအလျောက် ပြန်လည်ချိတ်ဆက်ပါသည်။ MultiSubnetFailover=True to connection strings ကို ထည့်သွင်းခြင်းသည် multi-subnet ဖြန့်ကျက်မှုများတွင် ပြန်လည်ချိတ်ဆက်မှုအမြန်နှုန်းကို မြှင့်တင်ပေးသည်။

မေး- ဘယ်လိုလျှောက်ထားရမလဲ SQL Server Always On ပတ်ဝန်းကျင်မှာ downtime အနည်းဆုံးနဲ့ patch တွေလား။

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

မေး- Always On Availability Groups တွေကို Failover Cluster Instances တွေနဲ့ ပေါင်းစပ်လို့ရပါသလား။

A: ဟုတ်ကဲ့။ instance-level နှင့် database-level failover protection နှစ်မျိုးလုံးရရှိရန် FCI instance များတွင် AG replicas များကို host လုပ်နိုင်ပါသည်။ FCI တစ်ခုစီသည် AG replica တစ်ခုတည်းအဖြစ် ရေတွက်ပါသည်။ ဤ topology သည် ဖြစ်နိုင်ချေရှိသော FCI failover ပြီးနောက် node တစ်ခုမျှ AG ၏ replicas နှစ်ခုကို host မလုပ်ကြောင်းသေချာစေရန် WSFC node စီစဉ်ခြင်းကို ဂရုတစိုက်ပြုလုပ်ရန် လိုအပ်ပါသည်။

မေး- Always On ပတ်ဝန်းကျင်မှာ ကျွန်တော့်ရဲ့ database ပျက်စီးသွားရင် ဘာလုပ်သင့်လဲ။

A: ပထမဦးစွာ၊ corrupt သည် replicas အားလုံးတွင်ရှိမရှိ သို့မဟုတ် primary တွင်သာရှိမရှိ စစ်ဆေးပါ။ ကျန်းမာသော secondary တစ်ခုရှိပါက ချက်ချင်း fail over လုပ်ပါ။ replicas အားလုံးတွင် corrupt ဖြစ်ပါက clean backup မှ restore လုပ်ပါ။ corrupt ကို စောစီးစွာဖမ်းမိရန် secondary replicas များတွင် DBCC CHECKDB ကို မှန်မှန်လုပ်ဆောင်ပါ။ backup များလည်း ထိခိုက်ပါက၊ အထူးပြု SQL Server ဒေတာဆယ်တင်ရေးကိရိယာတခုဖြစ်တယ် ပျက်စီးနေသော MDF ဖိုင်များမှ ဒေတာများကို နောက်ဆုံးနည်းလမ်းအဖြစ် ထုတ်ယူရန် ကြိုးစားနိုင်သည်။

မေး- Always On Availability Groups တွေက အရင် Groups တွေနဲ့ ဘယ်လိုကွာခြားလဲ။ SQL Server HA ဖြေရှင်းနည်းတွေ?

A: AG သည် နည်းပညာဟောင်းများထက် အစားထိုးသည်။ သစ်တင်ပို့မှု နှင့် ပွား။ မှတ်တမ်းပို့ဆောင်ခြင်းသည် ကိုယ်တိုင် failover လိုအပ်ပြီး အလိုအလျောက် role transition မရှိပါ။ မိတ္တူကူးခြင်းကို HA အစား data distribution အတွက် ဒီဇိုင်းထုတ်ထားသည်။ AG သည် automated failover၊ synchronous commit ဖြင့် data loss သုညနှင့် readable secondary များ — ထိုနည်းပညာများ မယှဉ်နိုင်သော စွမ်းရည်များကို ပေးဆောင်သည်။

8 ။ ကောက်ချက်

SQL Server Always On သည် မြင့်မားသော ရရှိနိုင်မှုနှင့် ဘေးအန္တရာယ်ပြန်လည်ထူထောင်ရေးအတွက် ပြောင်းလွယ်ပြင်လွယ်ရှိသော၊ enterprise-grade platform တစ်ခုကို ပံ့ပိုးပေးပါသည်။ Always On Availability Groups သည် ခေတ်မီဖြန့်ကျက်မှုအများစုအတွက် မှန်ကန်သောရွေးချယ်မှုဖြစ်သည်- ၎င်းသည် shared storage လိုအပ်ချက်ကို ဖယ်ရှားပေးပြီး၊ ဖတ်ရှုနိုင်သော secondary များကို ပံ့ပိုးပေးပြီး local HA နှင့် cross-site DR နှစ်မျိုးလုံးကို တစ်ခုတည်းသော configuration တွင် ကိုင်တွယ်ပေးသည်။ Failover Cluster Instances သည် instance-level failover နှင့် ရှိပြီးသား shared storage infrastructure များသည် အဓိကလိုအပ်ချက်များဖြစ်သည့်အခါ ခိုင်မာသောရွေးချယ်မှုတစ်ခုအဖြစ် ဆက်လက်တည်ရှိနေပါသည်။ နည်းပညာနှစ်ခုလုံးကို ပေါင်းစပ်ခြင်းသည် ရရှိနိုင်သော အနက်ရှိုင်းဆုံးကာကွယ်မှုကို ပေးစွမ်းသည် - ပိုမိုကြီးမားသော infrastructure ရင်းနှီးမြှုပ်နှံမှုနှင့် လည်ပတ်မှုရှုပ်ထွေးမှု၏ ကုန်ကျစရိတ်ဖြင့်။

ဘယ်ဖြေရှင်းချက်ကိုပဲ ရွေးချယ်ပါစေ၊ အခြေခံတွေကတော့ အတူတူပါပဲ- သင့်ရဲ့ RTO နဲ့ RPO လိုအပ်ချက်တွေကို ဦးစွာ သတ်မှတ်ပါ၊ အဲဒီပစ်မှတ်တွေအပေါ် အခြေခံပြီး topology ကို ဒီဇိုင်းဆွဲပါ၊ ပြီးတော့ failover ကို ပုံမှန်စမ်းသပ်ပါ။ သေချာစွာစမ်းသပ်ထားတဲ့ ကောင်းမွန်စွာအကောင်အထည်ဖော်ထားတဲ့ Always On ဖြေရှင်းချက်တစ်ခုဟာ ထုတ်လုပ်မှုချို့ယွင်းမှုတွေဖြစ်လာတဲ့အခါ ကြိုတင်ခန့်မှန်းနိုင်လောက်အောင် ပြန်လည်ကောင်းမွန်လာပါလိမ့်မယ်။

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

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

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

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

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