MySQL-д зориулсан найруулагч: яагаад та үүнгүйгээр алдааг тэсвэрлэх чадвартай төсөл барьж чадахгүй байна вэ?

Аливаа томоохон төсөл хэд хэдэн серверээс эхэлдэг. Эхлээд нэг DB сервер байсан бөгөөд дараа нь унших хэмжээг нэмэгдүүлэхийн тулд түүнд боолуудыг нэмсэн. Тэгээд - зогсоо! Нэг эзэн байдаг ч олон боолууд байдаг; хэрэв боолуудын аль нэг нь явбал бүх зүйл сайхан болно, гэхдээ эзэн нь явбал муу байх болно: сул зогсолт, админууд серверээ өсгөх гэж оролдож байна. Юу хийх вэ? Мастер нөөцөл. Энэ тухай миний хамтран зүтгэгч Павел аль хэдийн бичсэн нийтлэл, Би үүнийг давтахгүй. Үүний оронд би танд яагаад MySQL-д зориулсан Orchestrator хэрэгтэй байгааг хэлэх болно!

Гол асуултаас эхэлье: "Мастер явахад бид кодыг хэрхэн шинэ машин руу шилжүүлэх вэ?"

• Би VIP (Виртуал IP) схемд хамгийн их дуртай, бид энэ талаар доор ярих болно. Энэ нь хамгийн энгийн бөгөөд ойлгомжтой боловч тодорхой хязгаарлалттай байдаг: бидний нөөцлөх мастер нь шинэ машинтай L2 сегментэд байх ёстой, өөрөөр хэлбэл бид хоёр дахь DC-ийн талаар мартаж болно. Мөн найрсаг байдлаар, хэрэв та том L2 нь хор хөнөөлтэй гэсэн дүрмийг дагаж мөрдвөл L2 нь зөвхөн тавиур дээр, L3 нь тавиуруудын хооронд байдаг тул ийм схем нь бүр ч илүү хязгаарлалттай байдаг.
• Та кодонд DNS нэрийг бичиж /etc/hosts-аар дамжуулан шийдвэрлэх боломжтой. Үнэндээ ямар ч шийдвэр гарахгүй. Схемийн давуу тал: эхний аргын хязгаарлалт байхгүй, өөрөөр хэлбэл хөндлөн DC-ийг зохион байгуулах боломжтой. Гэхдээ дараа нь тодорхой асуулт гарч ирнэ: бид Puppet-Ansible-ээр дамжуулан /etc/hosts руу өөрчлөлтийг хэр хурдан хүргэх вэ?
• Та хоёр дахь аргыг бага зэрэг өөрчилж болно: кэш DNS-ийг бүх вэб сервер дээр суулгаж, код нь үндсэн мэдээллийн сан руу орох болно. Та DNS-д энэ оруулгад TTL 60 тохируулж болно. Зөв хэрэгжүүлбэл арга нь сайн юм шиг санагддаг.
• Консул гэх мэтийг ашиглахыг илэрхийлсэн үйлчилгээний нээлт бүхий схем.
• Сонирхолтой сонголт ProxySQL. Та ProxySQL-ээр дамжуулан MySQL руу бүх урсгалыг чиглүүлэх хэрэгтэй; ProxySQL өөрөө хэн мастер болохыг тодорхойлж чадна. Дашрамд хэлэхэд, та энэ бүтээгдэхүүнийг ашиглах сонголтуудын нэгийг миний нийтлэлээс уншиж болно нийтлэл.

Github-д ажиллаж байсан Orchestrator-ийн зохиогч эхлээд VIP-тэй анхны схемийг хэрэгжүүлж, дараа нь консултай схем болгон хувиргасан.

Дэд бүтцийн ердийн төлөвлөлт:

Би анхааралдаа авах шаардлагатай тодорхой нөхцөл байдлыг нэн даруй тайлбарлах болно.

• VIP хаягийг аль ч серверийн тохиргоонд бүртгүүлж болохгүй. Нөхцөл байдлыг төсөөлөөд үз дээ: мастер дахин ачаалагдсан бөгөөд үүнийг ачаалж байх үед Orchestrator ажиллагаагүй горимд орж, боолуудын нэгийг мастер болгосон; Дараа нь хуучин мастер босч, одоо VIP хоёр машин дээр байна. Энэ муу байна.
• Оркестрийн хувьд та хуучин мастер болон шинэ мастерийг дуудах скрипт бичих хэрэгтэй болно. Хуучин мастер дээр та ifdown, шинэ мастер дээр ifup vip ажиллуулах хэрэгтэй. Энэ скриптэд бүтэлгүйтсэн тохиолдолд тархи хуваагдахаас зайлсхийхийн тулд хуучин мастерын шилжүүлэгч дээрх портыг зүгээр л унтраадаг гэдгийг тусгах нь сайхан байх болно.
• Оркестр таны скриптийг дуудаж эхлээд VIP-г устгаад/эсвэл шилжүүлэгч дээрх портыг унтрааж, дараа нь шинэ мастер дээр VIP өргөх скриптийг дуудсаны дараа arping командыг ашиглан хүн бүрт шинэ VIP одоо байгаа гэдгийг хэлэхээ бүү мартаарай. энд.
• Бүх боолууд зөвхөн_уншсан=1 байх ёстой бөгөөд та боолыг эзэнд сурталчлангуут ​​энэ нь зөвхөн_унших=0 байх ёстой.
• Үүний тулд бидний сонгосон ямар ч боол эзэн болж чадна гэдгийг битгий мартаарай (Оркестр нь аль боолыг шинэ эзэнд нэр дэвшигч гэж үзэх, хоёрдугаарт аль нь, аль боолыг сонгохыг илүүд үзэх бүхэл бүтэн механизмтай байдаг. ямар ч тохиолдолд сонгох боломжгүй мастер). Хэрэв боол эзэн болбол боолын ачаалал үүн дээр үлдэж, эзний ачаалал нэмэгдэх тул үүнийг анхаарч үзэх хэрэгтэй.

Хэрэв танд оркестр байхгүй бол яагаад танд хэрэгтэй байна вэ?

• Orchestrator нь топологийг бүхэлд нь харуулдаг хэрэглэгчдэд ээлтэй график интерфэйстэй (доорх дэлгэцийн зургийг үзнэ үү).
• Оркестратор нь аль боолууд хоцорч байгаа, хаана хуулбарлах нь ерөнхийдөө эвдэрч байгааг хянах боломжтой (бидэнд SMS илгээх Оркестраторт хавсаргасан скриптүүд байдаг).
• Оркестр нь ямар боолуудад GTID алдаатай байгааг хэлж өгнө.

Оркестрийн интерфейс:

GTID алдаа гэж юу вэ?

Оркестрийн ажилд орох хоёр үндсэн шаардлага байдаг.

• MySQL кластерийн бүх машин дээр псевдо GTID-г идэвхжүүлсэн байх шаардлагатай; бид GTID-г идэвхжүүлсэн.
• Хаа сайгүй нэг төрлийн бинлог байх шаардлагатай, та мэдэгдлийг ашиглаж болно. Бид мастер болон ихэнх боолууд Row-тэй, хоёр нь Холимог горимд түүхэндээ үлдсэн тохиргоотой байсан. Үүний үр дүнд Оркестратор эдгээр боолуудыг шинэ эзэнтэй холбохыг хүсээгүй.

Үйлдвэрлэлийн боолын хамгийн чухал зүйл бол эзэнтэйгээ тууштай байх явдал гэдгийг санаарай! Хэрэв та Глобал Гүйлгээний ID (GTID)-г мастер болон боол дээрээ идэвхжүүлсэн бол gtid_subset функцийг ашиглан эдгээр машинууд дээр өгөгдөл өөрчлөх ижил хүсэлтүүд бодитоор хийгдсэн эсэхийг мэдэх боломжтой. Та энэ талаар илүү ихийг уншиж болно энд.

Тиймээс Orchestrator танд GTID алдаагаар дамжуулан эзэн дээр байхгүй гүйлгээнүүд байгааг харуулж байна. Яагаад ийм зүйл болж байна вэ?

• Зөвхөн_унших=1 нь зарц дээр идэвхжээгүй, хэн нэгэн холбогдож, өгөгдлийг өөрчлөх хүсэлтийг гүйцэтгэсэн.
• Зөвхөн Super_read_on=1 нь боол дээр идэвхжээгүй байгаа тул админ серверийг төөрөлдүүлж, тэнд орж хүсэлтийг гүйцэтгэсэн.
• Хэрэв та өмнөх хоёр зүйлийг анхаарч үзсэн бол өөр нэг заль мэх бий: MySQL-д бинлогуудыг цэвэрлэх хүсэлт нь мөн бинлог руу очдог тул эхний угаах үед мастер болон бүх боолууд дээр GTID алдаа гарч ирнэ. Үүнээс хэрхэн зайлсхийх вэ? Perona-5.7.25-28 нь binlog_skip_flush_commands=1 тохиргоог нэвтрүүлсэн бөгөөд энэ нь binlogs руу flush бичихийг хориглодог. mysql.com вэб сайт дээр тогтсон нэг нь бий алдаа.

Дээр дурдсан бүх зүйлийг тоймлон хэлье. Хэрэв та Orchestrator-г ачаалах горимд ашиглахыг хүсэхгүй байгаа бол ажиглалтын горимд оруулна уу. Дараа нь таны нүдний өмнө үргэлж MySQL машинуудын харилцан үйлчлэлийн газрын зураг, машин тус бүр дээр ямар төрлийн хуулбар байгаа, боолууд хоцрогдсон эсэх, хамгийн чухал нь тэд мастертай хэр зэрэг нийцэж байгаа тухай визуал мэдээлэл байх болно!

"Оркестр яаж ажиллах ёстой вэ?" гэсэн тодорхой асуулт гарч ирнэ. Тэр одоогийн боолуудаас шинэ мастер сонгож, дараа нь түүнд бүх боолуудыг дахин холбох ёстой (үүнд GTID хэрэгтэй; хэрэв та binlog_name болон binlog_pos-той хуучин механизмыг ашигладаг бол одоо байгаа мастераас боолыг шинэ болгон сольж болно. зүгээр л боломжгүй юм!). Оркестратортой болохоос өмнө би энэ бүгдийг гараар хийх ёстой байсан. Хуучин эзэн нь адаптекийн хянагчаас болж дүүжлэгдэж байсан бөгөөд 10 орчим боолтой байв. Би VIP-г мастераас боолуудын аль нэгэнд шилжүүлж, бусад бүх боолуудыг дахин холбох шаардлагатай болсон. Хэдэн консол онгойлгож, хэдэн команд зэрэг оруулав... Шөнийн 3 цаг хүртэл хүлээгээд, хоёроос бусад боолуудын ачааллыг авч, хоёр мастерын эхний машиныг хийж, хоёр дахь машиныг шууд залгах хэрэгтэй болсон. үүн дээр, тиймээс бусад бүх боолуудыг шинэ эзэнд холбож, ачаагаа буцааж өг. Ерөнхийдөө аймшигтай ...

Orchestrator нь бүтэлгүйтлийн горимд шилжих үед хэрхэн ажилладаг вэ? Үүнийг бид мастерыг одоогийнхоос илүү хүчирхэг, илүү орчин үеийн машин болгохыг хүсч буй нөхцөл байдлын жишээгээр хамгийн хялбараар дүрсэлсэн болно.

Зураг нь үйл явцын дунд хэсгийг харуулж байна. Өнөөдрийг хүртэл юу хийсэн бэ? Бид зарим боолыг шинэ эзэн болгохыг хүсч байна гэж хэлээд Оркестратор бусад бүх боолуудыг зүгээр л холбож эхэлсэн бөгөөд шинэ мастер нь дамжин өнгөрөх машины үүрэг гүйцэтгэсэн. Энэ схемээр ямар ч алдаа гарахгүй, бүх боолууд ажилладаг, Оркестратор хуучин мастераас VIP-г устгаж, шинэ рүү шилжүүлж, зөвхөн уншигдах__=0 болгож, хуучин мастерыг мартдаг. Бүгд! Манай үйлчилгээний зогсолт нь VIP дамжуулах хугацаа буюу 2-3 секунд юм.

Өнөөдрийн хувьд энэ л байна, бүгдэд нь баярлалаа. Удахгүй Оркестраторын тухай хоёр дахь нийтлэл гарах болно. Зөвлөлтийн алдарт "Гараж" киноны нэг дүр "Би түүнтэй хамт хайгуул хийхгүй!" Оркестр, би тантай хамт тагнуулын ажилд явах болно!

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