په Citymobil کې موږ د MySQL ډیټابیس زموږ د اصلي دوامداره معلوماتو ذخیره کولو په توګه کاروو. موږ د مختلفو خدماتو او موخو لپاره ډیری ډیټابیس کلسترونه لرو.
د ماسټر دوامداره شتون د ټول سیسټم او د هغې د انفرادي برخو فعالیت یو مهم شاخص دی. د ماسټر ناکامۍ په صورت کې د کلستر اتوماتیک بیا رغونه د پیښې غبرګون وخت او سیسټم وخت کموي. په دې مقاله کې، زه به د MySQL کلستر لپاره د لوړ شتون (HA) ډیزاین وګورم او مجازی IP پتې (VIP).
د VIP پر بنسټ د HA حل
لومړی، زه به تاسو ته په لنډه توګه ووایم چې زموږ د معلوماتو ذخیره کولو سیسټم څه دی.
موږ د کلاسیک نقل کولو سکیم د یو لیکلو لاسرسي وړ ماسټر او ډیری لوستلو یوازې نقلونو سره کاروو. یو کلستر کولی شي یو منځنی ماسټر ولري - یو نوډ چې د نورو لپاره نقل او ماسټر دواړه وي. پیرودونکي د HAProxy له لارې نقلونو ته لاسرسی لري ، کوم چې حتی د بار توزیع او اسانه اندازه کولو ته اجازه ورکوي. د HAProxy کارول د تاریخي دلایلو له امله دي، او موږ اوس مهال ProxySQL ته د مهاجرت په بهیر کې یو.
تکثیر په نیمه همغږي حالت کې پر بنسټ ترسره کیږي GTID. دا پدې مانا ده چې لږ تر لږه یو نقل باید مخکې له دې چې بریالي وګڼل شي یو لیږد ثبت کړي. دا د نقل کولو حالت د ماسټر نوډ ناکامۍ په صورت کې د فعالیت او ډیټا خوندیتوب ترمینځ غوره توازن چمتو کوي. اساسا ټول بدلونونه د ماسټر څخه نقلونو ته لیږدول کیږي Row Based Replication (RBR)، مګر ځینې نوډونه ممکن ولري mixed binlog format.
آرکیسټریټر په دوره توګه د کلستر ټوپولوژي حالت تازه کوي، ترلاسه شوي معلومات تحلیلوي، او که ستونزې رامنځته شي، دا کولی شي د اتوماتیک بیا رغونې پروسه پیل کړي. پراختیا کونکی پخپله د پروسې لپاره مسؤل دی ، ځکه چې دا په بیلابیلو لارو پلي کیدی شي: د VIP ، DNS پراساس ، د خدماتو کشف خدماتو یا پخپله لیکل شوي میکانیزمونو کارول.
د ماسټر د بیرته راګرځولو یوه ساده لار که دا ناکامه شي د تیرولو VIP پتې کارول دي.
هغه څه چې تاسو اړتیا لرئ د دې حل په اړه پوه شئ مخکې له دې چې پرمخ لاړشئ:
- VIP یو IP پته ده چې د ځانګړي فزیکي شبکې انٹرفیس سره تړاو نلري. که چیرې نوډ ناکام شي یا د ټاکل شوي ساتنې په جریان کې ، موږ کولی شو VIP د لږترلږه وخت سره بلې سرچینې ته واړوو.
- د مجازی IP پتې وړیا کول او صادرول یو ارزانه او ګړندی عملیات دی.
- د VIP سره کار کولو لپاره، تاسو د SSH له لارې سرور ته لاسرسی ته اړتیا لرئ، یا د ځانګړو اسانتیاوو کارول، د بیلګې په توګه،
keepalived.
راځئ چې زموږ د وزرډ سره ممکنه ستونزې وګورو او تصور وکړو چې د اتوماتیک بیا رغونې میکانیزم باید څنګه کار وکړي.
د ماسټر سره د شبکې ارتباط ورک شوی، یا د هارډویر په کچه ستونزه رامنځته شوې، او سرور شتون نلري
- آرکیسټرټر د کلستر ټوپولوژي تازه کوي، هر نقل راپور ورکوي چې ماسټر شتون نلري. آرکیسټرټر د نوي ماسټر رول لپاره مناسب عکس غوره کولو پروسه پیل کوي او بیا رغونه پیل کوي.
- موږ هڅه کوو چې VIP د زاړه ماسټر څخه لیرې کړو - پرته له بریا څخه.
- نقل د ماسټر رول ته بدلیږي. ټوپولوژي بیا رغول کیږي.
- د VIP سره د نوي شبکې انٹرفیس اضافه کول. څرنګه چې د VIP لرې کول ممکن نه وو، موږ په منظمه توګه په پس منظر کې د غوښتنې لیږل پیل کوو وړیا ARP. دا ډول غوښتنه / ځواب تاسو ته اجازه درکوي چې په تړل شوي سویچونو کې د IP او MAC پتې نقشه کولو میز تازه کړئ ، پدې توګه تاسو ته خبر درکوي چې زموږ VIP حرکت کړی. دا احتمال کموي
split brainکله چې زاړه ماسټر بیرته راستانه شي. - ټولې نوې اړیکې سمدلاسه نوي ماسټر ته لیږل کیږي. زاړه اړیکې ناکامیږي او ډیټابیس ته تکراري زنګونه د غوښتنلیک په کچه رامینځته کیږي.
سرور په نورمال حالت کې کار کوي، د DBMS په کچه کې ناکامي رامنځته شوه
الګوریتم د تیرې قضیې سره ورته دی: د ټوپولوژي تازه کول او د بیا رغونې پروسې پیل کول. څرنګه چې سرور شتون لري، موږ په بریالیتوب سره VIP په زاړه ماسټر کې خوشې کوو، نوي ته یې لیږدوو، او د ARP ډیری غوښتنې لیږو. د زاړه ماسټر احتمالي راستنیدل باید د بیا جوړ شوي کلستر او د غوښتنلیک عملیات اغیزه ونکړي.
نورې ستونزې
د نقلونو یا منځنیو ماسټرانو ناکامي رهبري نه کوي د اتوماتیک کړنو لپاره او لاسي مداخلې ته اړتیا لري.
د مجازی شبکې انٹرفیس تل په لنډمهاله توګه اضافه کیږي ، دا د سرور ریبوټ وروسته ، VIP په اوتومات ډول نه ټاکل کیږي. د ډیټابیس هر مثال د ډیفالټ لخوا یوازې د لوستلو حالت کې پیل کیږي ، آرکیسټرټر په اوتومات ډول نوي ماسټر ته د لیکلو لپاره بدلوي او د نصبولو هڅه کوي read only په زاړه ماسټر باندې. دا کړنې د احتمال کمولو په هدف دي split brain.
د بیا رغونې پروسې په جریان کې ستونزې رامینځته کیدی شي، کوم چې باید د معیاري څارنې وسیلو سربیره د آرکیسټرټر UI له لارې هم خبر شي. موږ د دې خصوصیت په اضافه کولو سره REST API پراخ کړی دی ( اوس مهال تر ارزونې لاندې دي).
د HA حل عمومي ډیاګرام لاندې وړاندې شوی.
د نوي ماسټر غوره کول
آرکیسټرټر کافی هوښیار دی او هڅه کوي غوره کړي د لاندې معیارونو سره سم د نوي ماسټر په توګه:
- نقل د ماسټر شاته پاتې دی؛
- د ماسټر او نقل MySQL نسخه؛
- د نقل ډول (RBR، SBR یا مخلوط)؛
- په ورته یا مختلف ډیټا مرکزونو کې موقعیت؛
- شتون
errant GTID- هغه معاملې چې په نقل کې اجرا شوي او په ماسټر کې ندي؛ - د دودیز انتخاب قواعد هم په پام کې نیول شوي.
هر اشاره د ماسټر لپاره غوره نوماند نه ده. د مثال په توګه، یو نقل د ډیټا بیک اپ کولو لپاره کارول کیدی شي، یا سرور کمزوری هارډویر ترتیب لري. آرکیسټر لارښود قواعد چې تاسو یې کولی شئ د خپل نوماند انتخاب غوره توبونه له غوره غوره شوي څخه له پامه غورځول شوي تنظیم کړئ.
د غبرګون او بیا رغونې وخت
د یوې پیښې په صورت کې، دا مهمه ده چې د سیسټم ځنډول کم کړئ، نو راځئ چې د MySQL پیرامیټونه په پام کې ونیسو چې د آرکیسټرټر لخوا د کلستر ټوپولوژی په جوړولو او تازه کولو اغیزه کوي:
- - د ثانیو شمیر چې په جریان کې ریپلیکا د ماسټر څخه د نوي ډیټا یا د زړه ضربان سیګنال ته انتظار باسي مخکې لدې چې پیوستون له لاسه ورکړل شي او بیا وصل شي. څومره چې ارزښت ټیټ وي، په چټکۍ سره نقل کولی شي معلومه کړي چې د ماسټر سره اړیکه مات شوې. موږ دا ارزښت 5 ثانیو ته ټاکلی.
- - د بیا پیوستون هڅو تر مینځ د ثانیو شمیر. د شبکې د ستونزو په صورت کې، د دې پیرامیټر لپاره ټیټ ارزښت به د چټک بیا پیوستون اجازه ورکړي او د کلستر بیا رغونې پروسې پیل کولو مخه ونیسي. وړاندیز شوی ارزښت 1 ثانیه دی.
MASTER_RETRY_COUNT- د بیا پیوستون ډیری هڅې.MASTER_HEARTBEAT_PERIOD- په ثانیو کې وقفه چې وروسته ماسټر د زړه ضربان سیګنال لیږي. نیمایي ارزښت ته ډیفالټslave_net_timeout.
د آرکیسټریټ اختیارونه:
DelayMasterPromotionIfSQLThreadNotUpToDate- که مساوي ويtrue، بیا به ماسټر رول د کاندید په نقل کې پلي نشي تر هغه چې د ریپلیکا SQL تار د ریل لاګ څخه ټولې غیر پلي شوي لیږد بشپړ کړي. موږ دا اختیار کاروو ترڅو د معاملو له لاسه ورکولو څخه مخنیوی وشي کله چې د کاندید ټول نقلونه شاته شي.InstancePollSeconds- د ټوپولوژي جوړولو او تازه کولو فریکوینسي.RecoveryPollSeconds- د ټوپولوژي تحلیل فریکونسي. که کومه ستونزه وموندل شي، د ټوپولوژي بیا رغونه پیل کیږي. دا، د 1 ثانیې سره مساوي.
هر کلستر نوډ په هر یو کې یو ځل د آرکیسټرټر لخوا رایه ورکول کیږي InstancePollSeconds ثانیې کله چې ستونزه وموندل شي، د کلستر حالت مجبور دی، او بیا د بیا رغونې ترسره کولو لپاره وروستۍ پریکړه کیږي. د مختلف ډیټابیس او آرکیسټر پیرامیټرو سره تجربه کولو سره ، موږ وکولی شو د ځواب او بیا رغونې وخت 30 ثانیو ته راکم کړو.
د ازموینې موقف
موږ د سیمه ایز پرمختګ سره د HA سکیم ازموینه پیل کړه او د ازموینې او تولید چاپیریال کې نور پلي کول. ځایی سټینډ په بشپړ ډول د ډاکر پراساس اتومات شوی او تاسو ته اجازه درکوي د آرکیسټرټر او شبکې ترتیب کولو سره تجربه وکړئ ، کلستر له 2-3 سرورونو څخه څو درجن ته اندازه کړئ ، او په خوندي چاپیریال کې تمرینونه ترسره کړئ.
د تمرینونو په جریان کې، موږ د ستونزې د حل کولو میتودونو څخه یو غوره کوو: سمدلاسه د ماسټر په کارولو سره ډزې وکړئ kill -9په نرمۍ سره پروسه پای ته ورسوئ او سرور ودروئ (docker-compose stop)، په کارولو سره د شبکې ستونزې سمول iptables -j REJECT او یا iptables -j DROP. موږ د لاندې پایلو تمه کوو:
- آرکیسټرټر به د ماسټر سره ستونزې کشف کړي او له 10 ثانیو څخه په ډیر وخت کې به ټوپولوژي تازه کړي؛
- د بیا رغونې پروسه به په اوتومات ډول پیل شي: د شبکې ترتیب به بدل شي، د ماسټر رول به نقل ته تیریږي، ټوپولوژي به بیا جوړه شي؛
- نوی ماسټر به د لیکلو وړ شي، د بیا رغونې پروسې په جریان کې به ژوندی نقلونه له لاسه ورنکړي؛
- ډاټا به نوي ماسټر ته لیکل پیل شي او نقل شي؛
- د رغیدو ټول وخت به د 30 ثانیو څخه ډیر نه وي.
لکه څنګه چې تاسو پوهیږئ ، سیسټم ممکن د ازموینې او تولید چاپیریال کې د مختلف هارډویر او شبکې ترتیبونو ، مصنوعي او ریښتیني بار کې توپیرونو له امله مختلف چلند وکړي. له همدې امله، موږ په منظمه توګه په ریښتیني شرایطو کې تمرینونه ترسره کوو، وګورئ چې سیسټم څنګه چلند کوي کله چې د شبکې ارتباط له لاسه ورکړي یا د هغې انفرادي برخې خرابې شي. په راتلونکي کې، موږ غواړو د دواړو چاپیریالونو لپاره په بشپړه توګه ورته زیربنا جوړه کړو او د هغې ازموینې اتومات کړو.
موندنو
د اصلي ذخیره کولو سیسټم نوډ روغتیا د SRE او عملیاتي ټیم یو له اصلي دندو څخه دی. د VIP پر بنسټ د آرکسټرټر او HA حل پلي کولو موږ ته اجازه راکړه چې لاندې پایلې ترلاسه کړو:
- د ډیټابیس کلستر د ټوپولوژي سره د ستونزو معتبر کشف؛
- د ماسټر پورې اړوند پیښو ته اتوماتیک او ګړندی ځواب ، د سیسټم وخت کمول.
په هرصورت، حل خپل محدودیتونه او زیانونه لري:
- څو ډیټا مرکزونو ته د HA سکیم اندازه کول به د دوی ترمینځ یو واحد L2 شبکې ته اړتیا ولري.
- مخکې لدې چې نوي ماسټر ته VIP ګمارل شي ، موږ باید دا په زاړه کې خوشې کړو. پروسه په ترتیب سره ده، کوم چې د بیا رغونې وخت زیاتوي؛
- د VIP خوشې کول سرور ته د SSH لاسرسي ته اړتیا لري ، یا د ریموټ پروسیجرونو زنګ وهلو کوم بل میتود. څرنګه چې سرور یا ډیټابیس د ستونزو سره مخ دی چې د بیا رغونې پروسې لامل شوی، موږ ډاډه نشو چې د VIP لیرې کول به په بریالیتوب سره بشپړ شي. او دا کولی شي د ورته مجازی IP پتې او ستونزې سره د دوه سرورونو څرګندیدو لامل شي
split brain.
مخه نیول split brain، تاسو کولی شئ دا طریقه وکاروئ ("بل نوډ په سر کې ډزې وکړئ")، کوم چې د ستونزې نوډ په بشپړه توګه جلا یا غیر فعالوي. د کلستر لوړ شتون پلي کولو لپاره نورې لارې شتون لري: د VIP او DNS ترکیب، د خدماتو کشف او پراکسي خدمتونه، همغږي نقل او نور میتودونه چې خپل زیانونه او ګټې لري.
ما د MySQL ناکامیو کلستر جوړولو لپاره زموږ د تګلارې په اړه خبرې وکړې. دا پلي کول اسانه دي او په اوسني شرایطو کې د اعتبار وړ کچه چمتو کوي. لکه څنګه چې په عمومي توګه ټول سیسټم او په ځانګړې توګه زیربنا وده کوي، دا طریقه به بې له شکه وده وکړي.
سرچینه: www.habr.com