Citymobil дээр бид MySQL мэдээллийн баазыг үндсэн мэдээллийн сан болгон ашигладаг. Бидэнд янз бүрийн үйлчилгээ, зориулалт бүхий хэд хэдэн мэдээллийн сангийн кластер бий.

Мастерийн байнгын бэлэн байдал нь бүхэл бүтэн систем болон түүний бие даасан хэсгүүдийн гүйцэтгэлийн чухал үзүүлэлт юм. Мастер бүтэлгүйтсэн тохиолдолд кластерийг автоматаар сэргээх нь ослын хариу өгөх хугацаа болон системийн зогсолтыг ихээхэн бууруулдаг. Энэ нийтлэлд би MySQL кластерт зориулсан өндөр хүртээмжтэй (HA) дизайныг авч үзэх болно. MySQL Оркестратор болон виртуал 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.

Манай шидтэнтэй холбоотой гарч болзошгүй асуудлуудыг авч үзээд автомат сэргээх механизм хэрхэн ажиллах ёстойг төсөөлөөд үз дээ.

Мастертай холбогдох сүлжээний холболт алга болсон эсвэл техник хангамжийн түвшинд асуудал үүссэн, сервер ажиллах боломжгүй байна.

1. Оркестратор кластерын топологийг шинэчилдэг бөгөөд хуулбар бүр нь мастерыг ашиглах боломжгүй гэж мэдээлдэг. Оркестр нь шинэ мастерийн дүрд тохирох хуулбарыг сонгох үйл явцыг эхлүүлж, сэргээн засварлаж эхэлдэг.
2. Бид хуучин мастераас VIP-г арилгахыг оролдож байна - амжилтанд хүрсэнгүй.
3. Хуулбар нь мастерын дүрд шилждэг. Топологийг дахин бүтээж байна.
4. VIP-тэй шинэ сүлжээний интерфейс нэмж байна. VIP устгах боломжгүй байсан тул бид үе үе далд хүсэлт илгээж эхэлдэг үнэ төлбөргүй ARP. Энэ төрлийн хүсэлт/хариулт нь холбогдсон свич дээрх IP болон MAC хаягийн зураглалын хүснэгтийг шинэчлэх боломжийг олгодог бөгөөд ингэснээр манай VIP шилжсэнийг танд мэдэгдэнэ. Энэ нь магадлалыг бууруулдаг split brain хуучин мастерыг буцааж өгөх үед.
5. Бүх шинэ холболтууд нэн даруй шинэ мастер руу шилждэг. Хуучин холболтууд амжилтгүй болж, мэдээллийн сан руу дахин дахин залгах нь хэрэглээний түвшинд хийгддэг.

Сервер хэвийн горимд ажиллаж байгаа тул DBMS түвшинд алдаа гарлаа

Алгоритм нь өмнөх тохиолдолтой төстэй: топологийг шинэчлэх, сэргээх үйл явцыг эхлүүлэх. Сервер бэлэн байгаа тул бид хуучин мастер дээр VIP-г амжилттай гаргаж, шинэ рүү шилжүүлж, хэд хэдэн ARP хүсэлт илгээдэг. Хуучин мастерын боломжит буцаалт нь дахин баригдсан кластер болон програмын үйл ажиллагаанд нөлөөлөх ёсгүй.

Бусад асуудал

Хуулбарууд эсвэл завсрын мастеруудын бүтэлгүйтэл удирддаггүй автомат үйлдэл хийх ба гарын авлагын оролцоог шаарддаг.

Виртуал сүлжээний интерфэйс нь үргэлж түр зуур нэмэгддэг, өөрөөр хэлбэл серверийг дахин ачаалсны дараа VIP автоматаар оноогддоггүй. Өгөгдлийн сангийн жишээ бүр анхдагчаар зөвхөн унших горимд эхэлдэг бөгөөд найруулагч нь шинэ мастерийг автоматаар бичихээр сольж, суулгахыг оролддог. read only хуучин мастер дээр. Эдгээр арга хэмжээ нь магадлалыг бууруулахад чиглэгддэг split brain.

Сэргээх явцад асуудал үүсч болзошгүй бөгөөд үүнийг стандарт хяналтын хэрэгслээс гадна найруулагчийн UI-ээр дамжуулан мэдэгдэх ёстой. Бид энэ функцийг нэмснээр REST API-г өргөтгөсөн (PR Одоогоор хянаж байгаа).

HA уусмалын ерөнхий диаграммыг доор үзүүлэв.

Шинэ мастер сонгох

Оркестр нь хангалттай ухаалаг бөгөөд сонгохыг хичээдэг хамгийн тохиромжтой хуулбар дараах шалгуурын дагуу шинэ мастераар:

• хуулбар нь мастераас хоцордог;
• Мастер болон хуулбарын MySQL хувилбар;
• хуулбарлах төрөл (RBR, SBR эсвэл холимог);
• ижил эсвэл өөр мэдээллийн төвд байрлах;
• хүртээмжтэй байдал errant GTID - хуулбар дээр хийгдсэн бөгөөд мастер дээр байхгүй гүйлгээ;
• захиалгат сонголтын дүрмийг мөн харгалзан үздэг.

Бүх дохио нь мастерт тохирох хамгийн тохиромжтой нэр дэвшигч биш юм. Жишээлбэл, хуулбарыг өгөгдлийг нөөцлөхөд ашиглаж болно, эсвэл сервер нь илүү сул техник хангамжийн тохиргоотой байдаг. Оркестр дэмждэг Гарын авлагын дүрмүүдийн тусламжтайгаар та нэр дэвшигчийн сонголтоо хамгийн дуртайгаас үл хэрэгсэх хүртэл өөрчлөх боломжтой.

Хариулт, нөхөн сэргээх хугацаа

Осол гарсан тохиолдолд системийн сул зогсолтыг багасгах нь чухал тул зохион байгуулагчийн кластерын топологийг үүсгэх, шинэчлэхэд нөлөөлөх MySQL параметрүүдийг авч үзье.

• slave_net_timeout — холболт тасарч, дахин холбогдохоос өмнө хуулбар нь мастераас шинэ өгөгдөл эсвэл зүрхний цохилтын дохио ирэхийг хүлээх секундын тоо. Утга бага байх тусам хуулбар нь мастертай харилцах харилцаа тасарсан болохыг хурдан тодорхойлж чадна. Бид энэ утгыг 5 секунд болгон тохируулсан.
• MASTER_CONNECT_RETRY - дахин холбох оролдлогын хоорондох секундын тоо. Сүлжээний асуудал гарсан тохиолдолд энэ параметрийн бага утга нь хурдан дахин холбогдох боломжийг олгож, кластерийг сэргээх үйл явцыг эхлүүлэхээс сэргийлнэ. Санал болгож буй утга нь 1 секунд байна.
• MASTER_RETRY_COUNT - дахин холбох оролдлогын хамгийн их тоо.
• MASTER_HEARTBEAT_PERIOD - секундын интервал, дараа нь мастер зүрхний цохилтын дохиог илгээдэг. Өгөгдмөл утгын хагас хүртэл slave_net_timeout.

Оркестрийн сонголтууд:

• DelayMasterPromotionIfSQLThreadNotUpToDate - тэнцүү бол true, дараа нь хуулбарын SQL хэлхээг Relay Log-аас ашиглагдаагүй бүх гүйлгээг хийж дуустал нэр дэвшигчийн хуулбар дээр мастер үүрэг хэрэгжихгүй. Нэр дэвшигчдийн хуулбар бүгд хоцрох үед гүйлгээгээ алдахгүйн тулд бид энэ сонголтыг ашигладаг.
• InstancePollSeconds - топологийг барих, шинэчлэх давтамж.
• RecoveryPollSeconds — топологийн шинжилгээний давтамж. Хэрэв асуудал илэрсэн бол топологийг сэргээх ажиллагааг эхлүүлнэ. Энэ тогтмол, 1 секундтэй тэнцүү.

Кластерийн зангилаа бүрийг найруулагч нэг удаа санал болгодог InstancePollSeconds секунд Асуудал илэрсэн үед кластерийн төлөвийг албаддаг шинэчлэгдсэн, дараа нь нөхөн сэргээх эцсийн шийдвэр гарна. Өөр өөр мэдээллийн сан болон найруулагчийн параметрүүдийг туршиж үзсэнээр бид хариу үйлдэл болон сэргээх хугацааг 30 секунд хүртэл бууруулж чадсан.

Туршилтын тавиур

Бид орон нутгийн хөгжүүлэлтээр HA схемийг туршиж эхэлсэн туршилтын вандан сандал туршилт, үйлдвэрлэлийн орчинд цаашид хэрэгжүүлэх. Орон нутгийн стенд нь Docker-д суурилсан бүрэн автоматжуулсан бөгөөд найруулагч болон сүлжээний тохиргоог туршиж үзэх, кластерийг 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 failover кластер үүсгэх бидний арга барилын талаар ярьсан. Үүнийг хэрэгжүүлэхэд хялбар бөгөөд одоогийн нөхцөлд найдвартай байдлын хүлээн зөвшөөрөгдөх түвшинг хангадаг. Бүхэл бүтэн систем, тэр дундаа дэд бүтэц хөгжихийн хэрээр энэ арга зам нь хувьсан өөрчлөгдөх нь дамжиггүй.

Эх сурвалж: www.habr.com