မည်သည့် ကြီးမားသော ပရောဂျက်မဆို ဆာဗာနှစ်ခုဖြင့် စတင်ခဲ့သည်။ အစပိုင်းတွင် DB ဆာဗာတစ်ခုရှိခဲ့သော်လည်း စာဖတ်ခြင်းကို အတိုင်းအတာတစ်ခုအထိ ချဲ့ထွင်ရန် ၎င်းတွင် ကျေးကျွန်များကို ပေါင်းထည့်ခဲ့သည်။ ပြီးတော့ ရပ်လိုက်! သခင်တပါးရှိသော်လည်း၊ ကျွန်များထဲမှ ထွက်သွားပါက အရာအားလုံး အဆင်ပြေမည်ဖြစ်သော်လည်း သခင်ထွက်သွားပါက ဆိုးရွားလိမ့်မည်- စက်ရပ်ချိန်၊ စီမံခန့်ခွဲသူများသည် ဆာဗာကို မြှင့်တင်ရန် ကြိုးစားနေပါသည်။ ဘာလုပ်မလဲ? အရံသခင်။ ကျွန်ုပ်၏လုပ်ဖော်ကိုင်ဖက် Pavel သည်ဤအကြောင်းကိုရေးသားထားပြီးဖြစ်သည်။ ငါအဲဒါကိုထပ်မလုပ်ဘူး။ အဲဒီအစား MySQL အတွက် Orchestrator ကို ဘာကြောင့် သေချာပေါက် လိုအပ်တယ်ဆိုတာ ပြောပြမယ်။
အဓိကမေးခွန်းနဲ့စကြရအောင်- "မာစတာထွက်သွားတဲ့အခါ ကုဒ်ကို စက်အသစ်ဆီ ဘယ်လိုပြောင်းမလဲ"
- VIP (Virtual IP) နဲ့ အစီအစဥ်ကို ကျွန်တော် အနှစ်သက်ဆုံးပါ၊ အောက်မှာ ပြောပြပါမယ်။ ၎င်းသည် အရိုးရှင်းဆုံးနှင့် အထင်ရှားဆုံးဖြစ်သည်၊ သိသာထင်ရှားသော ကန့်သတ်ချက်တစ်ခုပါရှိသည်၊ သို့သော် ကျွန်ုပ်တို့ သိမ်းဆည်းမည့် မာစတာသည် စက်အသစ်နှင့် L2 အပိုင်းတွင် ရှိရမည်၊ ဆိုလိုသည်မှာ ကျွန်ုပ်တို့သည် ဒုတိယ DC ကို မေ့ထားနိုင်သည်။ L2 ကြီးသည် မကောင်းသော စည်းမျဉ်းကို လိုက်နာပါက၊ L2 သည် တစ်ပွဲစီသာဖြစ်ပြီး L3 သည် ထိန်သိမ်းများကြားတွင် ရှိနေသောကြောင့်၊ ထိုကဲ့သို့သော အစီအစဉ်သည် ပို၍ပင် ကန့်သတ်ချက်များ ရှိနေပါသည်။
- ကုဒ်တွင် DNS အမည်တစ်ခုရေးပြီး /etc/hosts မှတဆင့် ဖြေရှင်းနိုင်သည်။ တကယ်တော့ ပြတ်သားမှု ရှိမှာ မဟုတ်ပါဘူး။ အစီအစဥ်၏ အားသာချက်- ပထမနည်းလမ်း၏ ကန့်သတ်ချက်လက္ခဏာများ မရှိကြောင်း ဆိုလိုသည်မှာ cross-DC ကို စုစည်းရန် ဖြစ်နိုင်သည်။ သို့သော်ထို့နောက် သိသာထင်ရှားသောမေးခွန်းပေါ်လာသည်- Puppet-Ansible မှတစ်ဆင့် အပြောင်းအလဲကို /etc/hosts သို့ မည်မျှမြန်မြန်ဆန်ဆန်ပေးပို့နိုင်မည်နည်း။
- ဒုတိယနည်းလမ်းကို သင်အနည်းငယ်ပြောင်းလဲနိုင်သည်- ကုဒ်သည် မာစတာဒေတာဘေ့စ်သို့သွားမည့် ဝဘ်ဆာဗာများအားလုံးတွင် caching DNS ကို ထည့်သွင်းပါ။ DNS တွင် ဤထည့်သွင်းမှုအတွက် TTL 60 ကို သင် သတ်မှတ်နိုင်သည်။ နည်းမှန်လမ်းမှန် အကောင်အထည်ဖော်ရင် ကောင်းမယ်ထင်တယ်။
- ကောင်စစ်ဝန်၏အသုံးပြုမှုနှင့် စသည်တို့ကို ရည်ညွှန်းသည့် ဝန်ဆောင်မှုရှာဖွေတွေ့ရှိမှုပါရှိသော အစီအစဉ်။
- စိတ်ဝင်စားစရာကောင်းသောရွေးချယ်မှုနှင့်အတူ . ProxySQL မှတဆင့် MySQL သို့ အသွားအလာအားလုံးကို လမ်းကြောင်းပြောင်းရန် လိုအပ်သည်၊ ProxySQL ကိုယ်တိုင်က မည်သူမည်ဝါဖြစ်သည်ကို ဆုံးဖြတ်နိုင်သည်။ စကားမစပ်၊ ကျွန်ုပ်တွင် ဤထုတ်ကုန်ကို အသုံးပြုရန်အတွက် ရွေးချယ်စရာများထဲမှ တစ်ခုကို သင်ဖတ်နိုင်သည်။ .
Github တွင်အလုပ်လုပ်သော Orchestrator ၏စာရေးသူသည် VIP ဖြင့်ပထမဆုံးအစီအစဥ်ကိုစတင်အကောင်အထည်ဖော်ခဲ့ပြီး၎င်းကိုကောင်စစ်ဝန်နှင့်အစီအစဉ်အဖြစ်ပြောင်းလဲခဲ့သည်။
ပုံမှန်အခြေခံအဆောက်အဦ အပြင်အဆင်-
ထည့်သွင်းစဉ်းစားရန် လိုအပ်သော သိသာထင်ရှားသော အခြေအနေများကို ကျွန်ုပ်ချက်ချင်းဖော်ပြပါမည်။
- VIP လိပ်စာကို မည်သည့်ဆာဗာများတွင်မဆို config တွင် စာရင်းသွင်းထားသင့်သည်။ အခြေအနေတစ်ခုကို စိတ်ကူးကြည့်ကြပါစို့။ မာစတာသည် ပြန်လည်စတင်ပြီး ၎င်းကိုဖွင့်နေချိန်တွင် Orchestrator သည် ပျက်ကွက်သည့်မုဒ်သို့ရောက်ရှိသွားပြီး ကျွန်များထဲမှတစ်ဦးကို သခင်ဖြစ်စေခဲ့သည်။ ထို့နောက် ဆရာကြီးသည် ထမြောက်ပြီး ယခု VIP သည် ကားနှစ်စီးပေါ်တွင် ရှိနေသည်။ ဒါက မကောင်းဘူး။
- သံစုံတီးဝိုင်းအတွက်၊ သခင်ဟောင်းနှင့် သခင်အသစ်ကို ခေါ်ရန်အတွက် ဇာတ်ညွှန်းရေးရန် လိုအပ်သည်။ မာစတာဟောင်းတွင် ifdown နှင့် master အသစ်တွင် ifup vip ကို run ရန်လိုအပ်သည်။ ရှုံးနိမ့်မှုတစ်ခုဖြစ်ပွားသောအခါ၊ ခွဲခြမ်းဦးနှောက်ကိုရှောင်ရှားရန် အဟောင်း၏မာစတာခလုတ်ရှိ ဆိပ်ကမ်းကို ရိုးရှင်းစွာပိတ်သွားစေရန် ဤ script တွင်ထည့်သွင်းခြင်းသည် ကောင်းပါတယ်။
- Orchestrator မှ VIP ကို ဦးစွာဖယ်ရှားရန်နှင့်/သို့မဟုတ် switch ပေါ်ရှိ port ကို ငြိမ်းသတ်ရန် သင်၏ script ကို ခေါ်ပြီးနောက်၊ မာစတာအသစ်တွင် VIP မြှင့်တင်ခြင်း script ကို ခေါ်ပြီးနောက်၊ VIP အသစ်ဖြစ်နေပြီဟု လူတိုင်းအား ပြောပြရန် arping command ကို အသုံးပြုရန် မမေ့ပါနှင့်။ ဒီမှာ။
- ကျွန်များအားလုံး read_only=1 ရှိသင့်ပြီး သင်ကျွန်အား သခင်ထံ မြှင့်တင်ပြီးသည်နှင့် ၎င်းတွင် read_only=0 ရှိသင့်သည်။
- ဤအတွက်ကျွန်ုပ်တို့ရွေးချယ်ထားသော မည်သည့်ကျွန်သည် သခင်ဖြစ်လာနိုင်သည်ကို မမေ့ပါနှင့် (Orchestrator တွင် သခင်အသစ်အတွက် ပထမနေရာ၌ ကိုယ်စားလှယ်လောင်းအဖြစ်ထည့်သွင်းစဉ်းစားရမည့် ကျွန်သည် ဦးစားပေးအစီအစဉ်တစ်ခု ရှိပြီး ဒုတိယနေရာတွင် မည်သည့်ကျွန်လုပ်သင့်သည် မည်သည့်အခြေအနေမျိုးတွင်မဆို သခင်ရွေးချယ်ခြင်းမပြုရပါ။) ကျွန်သည် သခင်ဖြစ်လာပါက၊ ကျွန်၏ဝန်သည် ၎င်းတွင်ရှိနေမည်ဖြစ်ပြီး၊ သခင်၏ဝန်ကို ထပ်လောင်းရမည်၊ ယင်းကို ထည့်သွင်းစဉ်းစားရမည်ဖြစ်သည်။
မင်းမှာ Orchestrator တစ်ယောက်မရှိရင် မင်းဘာလို့လိုအပ်တာလဲ။
- Orchestrator တွင် topology တစ်ခုလုံးကိုပြသသည့် အလွန်အသုံးပြုရလွယ်ကူသော ဂရပ်ဖစ် အင်တာဖေ့စ်တစ်ခု ပါရှိသည်။ (အောက်ပါ screenshot ကိုကြည့်ပါ)။
- Orchestrator သည် မည်သည့်ကျေးကျွန်များ နောက်ကျကျန်နေသေးသည်ကို ခြေရာခံနိုင်ပြီး ပုံတူပွားမှုမှာ ယေဘူယျအားဖြင့် ပျက်စီးသွားသည် (SMS ပေးပို့ရန်အတွက် Orchestrator နှင့် တွဲထားသော scripts များ ကျွန်ုပ်တို့တွင်ရှိသည်)။
- သံစုံတီးဝိုင်းဆရာသည် မည်သည့်ကျွန်များတွင် GTID မှားယွင်းမှုရှိသည်ကို ပြောပြသည်။
Orchestrator အင်တာဖေ့စ်-
GTID အမှားဆိုတာဘာလဲ။
Orchestrator အလုပ်လုပ်ရန် အဓိကလိုအပ်ချက် နှစ်ခုရှိသည်။
- MySQL အစုအဝေးရှိ စက်အားလုံးတွင် pseudo GTID ကို ဖွင့်ထားရန် လိုအပ်သည်၊ ကျွန်ုပ်တို့တွင် GTID ကို ဖွင့်ထားသည်။
- နေရာတိုင်းတွင် binlog အမျိုးအစားတစ်ခုရှိရန် လိုအပ်သည်၊ သင်သည် statement ကိုသုံးနိုင်သည်။ ကျွန်ုပ်တို့တွင် သခင်နှင့် ကျွန်အများစုတွင် Row ရှိကြပြီး သမိုင်းကြောင်းအရ နှစ်ခုသည် ရောနှောထားသည့်မုဒ်တွင် ကျန်ရှိနေခဲ့သည်။ ထို့ကြောင့် Orchestrator သည် ဤကျွန်များကို သခင်အသစ်နှင့် မချိတ်ဆက်လိုပါ။
ထုတ်လုပ်ရေးကျွန်တစ်ခုတွင် အရေးကြီးဆုံးအရာမှာ သခင်နှင့် လိုက်လျောညီထွေရှိကြောင်း သတိရပါ။ အကယ်၍ သင့်တွင် Global Transaction ID (GTID) ကို သင့်မာစတာနှင့် slave နှစ်ခုလုံးတွင် ဖွင့်ထားပါက၊ ထို့နောက် ဤစက်များတွင် ဒေတာပြောင်းလဲမှုများအတွက် တူညီသောတောင်းဆိုမှုများကို အမှန်တကယ်လုပ်ဆောင်ခြင်းရှိ၊ မရှိ သိရှိနိုင်ရန် gtid_subset လုပ်ဆောင်ချက်ကို သင်အသုံးပြုနိုင်ပါသည်။ ဤအကြောင်းပိုမိုဖတ်ရှုနိုင်ပါသည်။ .
ထို့ကြောင့်၊ Orchestrator သည် master တွင်မဟုတ်သောကျွန်တွင်အပေးအယူများရှိကြောင်း GTID အမှားမှတဆင့်သင့်အားပြသသည်။ ဘာကြောင့် ဒီလိုဖြစ်နေတာလဲ။
- Read_only=1 ကို ကျွန်တွင် ဖွင့်မထားပါ၊ တစ်စုံတစ်ယောက်သည် ချိတ်ဆက်ပြီး ဒေတာပြောင်းလဲရန် တောင်းဆိုချက်တစ်ခုကို အပြီးသတ်ခဲ့သည်။
- Super_read_only=1 ကို ကျွန်တွင် ဖွင့်မထားပါ၊ ထို့နောက် အက်ဒ်မင်သည် ဆာဗာကို ရှုပ်ယှက်ခတ်နေသဖြင့် ဝင်၍ တောင်းဆိုချက်ကို အကောင်အထည်ဖော်ခဲ့သည်။
- ယခင်အချက်နှစ်ခုလုံးကို ထည့်သွင်းစဉ်းစားပါက၊ MySQL တွင် နောက်ထပ်လှည့်ကွက်တစ်ခုရှိပါသည်- MySQL တွင် binlogs များကို flush လုပ်ရန် တောင်းဆိုချက်သည် binlog သို့သွားသည်၊ ထို့ကြောင့် ပထမ flush တွင်၊ master နှင့် slaves အားလုံးတွင် GTID အမှားတစ်ခုပေါ်လာလိမ့်မည်။ ဒါကို ဘယ်လိုရှောင်ရမလဲ။ Perona-5.7.25-28 သည် binlog_skip_flush_commands=1 ဆက်တင်ကို မိတ်ဆက်ခဲ့ပြီး၊ binlogs သို့ flush ရေးသားခြင်းကို တားမြစ်ထားသည်။ mysql.com ဝဘ်ဆိုဒ်တွင် တည်ထောင်ထားသော တစ်ခုရှိသည်။ .
အထက်ဖော်ပြပါ အားလုံးကို အကျဉ်းချုံးပါရစေ။ အကယ်၍ သင်သည် Orchestrator ကို failover mode တွင် အသုံးမပြုလိုပါက၊ ၎င်းကို observation mode တွင်ထည့်ပါ။ ထို့နောက် MySQL စက်များ၏အပြန်အလှန်ဆက်သွယ်မှုမြေပုံနှင့် ကျေးကျွန်များသည် နောက်ကျကျန်နေသေးသည်ဖြစ်စေ စက်တစ်ခုစီတွင် ပုံတူကူးချခြင်းအမျိုးအစားနှင့်ပတ်သက်သော အမြင်ဆိုင်ရာအချက်အလက်များကို သင့်မျက်စိရှေ့တွင် အမြဲရှိနေစေမည်ဖြစ်ပြီး အရေးကြီးဆုံးမှာ ၎င်းတို့သည် သခင်နှင့်မည်မျှကိုက်ညီမှုရှိသည်!
ထင်ရှားသောမေးခွန်းမှာ “သံစုံတီးဝိုင်းဆရာသည် မည်သို့လုပ်ဆောင်သင့်သနည်း။ သူသည် လက်ရှိကျွန်များထံမှ မာစတာအသစ်တစ်ခုကို ရွေးရမည်ဖြစ်ပြီး၊ ထို့နောက် ကျွန်အားလုံးကို ၎င်းနှင့် ပြန်လည်ချိတ်ဆက်ရမည် (၎င်းသည် GTID အတွက် လိုအပ်သည်၊ သင် binlog_name နှင့် binlog_pos ဖြင့် ယန္တရားဟောင်းကို အသုံးပြုပါက၊ ကျွန်တစ်ဦးကို လက်ရှိသခင်မှ အသစ်တစ်ခုသို့ ပြောင်းခြင်း မဖြစ်နိုင်ဘူး!) ငါတို့မှာ Orchestrator မရှိခင်မှာ ဒီအရာအားလုံးကို ကိုယ်တိုင်လုပ်ခဲ့ရတယ်။ သခင်ဟောင်းသည် buggy Adaptec ထိန်းချုပ်ကိရိယာကြောင့် ကြိုးဆွဲချခံနေရသည်၊ ၎င်းတွင် ကျွန် 10 ယောက်ခန့်ရှိသည်။ သခင်ထံမှ VIP ကို ကျွန်တစ်ဦးထံ လွှဲပြောင်းပြီး အခြားကျွန်အားလုံးကို ၎င်းနှင့် ပြန်လည်ချိတ်ဆက်ရန် လိုအပ်ပါသည်။ ကွန်ဆိုးလ်ဘယ်နှစ်လုံးဖွင့်ထားလဲ၊ တစ်ပြိုင်နက်တည်း command တွေဘယ်လောက်ဝင်ခဲ့လဲ... မနက် 3 နာရီအထိစောင့်ရတယ်၊ နှစ်ခုကလွဲလို့ ကျွန်တွေဆီက ဝန်ကိုဖယ်လိုက်၊ မာစတာနှစ်ခုရဲ့ ပထမစက်ကိုလုပ်ပါ၊ ဒုတိယစက်ကို ချက်ချင်းချိတ်လိုက်ပါ။ ထို့ကြောင့် အခြားကျွန်အားလုံးကို သခင်သစ်ထံ ချိတ်ပြီး ဝန်ကို ပြန်ပေးသည်။ ခြုံပြောရရင် ကြောက်စရာ...
Failover မုဒ်သို့ရောက်သွားသောအခါ Orchestrator မည်ကဲ့သို့အလုပ်လုပ်သနည်း။ ဤအရာအား ကျွန်ုပ်တို့သည် ယခုထက် ပိုမိုအားကောင်းပြီး ခေတ်မီသော စက်တစ်လုံးကို ကျွန်ုပ်တို့ပိုင်ဆိုင်လိုသော ကျွမ်းကျင်ပညာရှင်တစ်ဦးကို ကျွန်ုပ်တို့ယခုထက်ပိုမို၍ ခေတ်မီသော အခြေအနေတစ်ခုဖြင့် အလွယ်ဆုံးပုံဖော်ထားသည်။
ပုံသည် လုပ်ငန်းစဉ်၏ အလယ်ကို ပြသည်။ ဒီအထိ ဘာတွေလုပ်ပြီးသွားပြီလဲ။ ကျွန်ုပ်တို့သည် သခင်အသစ်၏ကျွန်အချို့ကို ခိုင်းစေလိုသည်ဟု ဆိုသည်၊ Orchestrator သည် အခြားကျွန်များအားလုံးကို ၎င်းနှင့် ရိုးရိုးရှင်းရှင်း ပြန်လည်ချိတ်ဆက်ရန် စတင်ခဲ့ပြီး သခင်အသစ်သည် အကူးအပြောင်းစက်တစ်ခုအဖြစ် လုပ်ဆောင်နေပါသည်။ ဤအစီအစဥ်ဖြင့်၊ အမှားအယွင်းမရှိ၊ ကျွန်အားလုံးအလုပ်လုပ်သည်၊ Orchestrator သည် VIP ကို သခင်ဟောင်းမှဖယ်ရှားကာ အသစ်သို့လွှဲပြောင်းပေးသည်၊ read_only=0 ပြုလုပ်ပြီး သခင်ဟောင်းအကြောင်းမေ့သွားပါသည်။ အားလုံး! ကျွန်ုပ်တို့၏ဝန်ဆောင်မှု၏ရပ်တန့်ချိန်သည် 2-3 စက္ကန့်ဖြစ်သည့် VIP လွှဲပြောင်းချိန်ဖြစ်သည်။
ဒီနေ့အတွက် ဒီလောက်ပါပဲ၊ အားလုံးကို ကျေးဇူးတင်ပါတယ်။ မကြာမီတွင် Orchestrator နှင့်ပတ်သက်သောဒုတိယဆောင်းပါးတစ်ပုဒ်ရှိလိမ့်မည်။ နာမည်ကျော် ဆိုဗီယက်ရုပ်ရှင် “Garage” တွင် ဇာတ်ကောင်တစ်ဦးက “ကျွန်တော် သူနဲ့ ကင်းထောက်မနေဘူး” လို့ပြောခဲ့ပါတယ်။ ဒါနဲ့ Orchestrator၊ မင်းနဲ့အတူ ကင်းထောက်သွားမယ်။
source: www.habr.com