ที่ Citymobil เราใช้ฐานข้อมูล MySQL เป็นที่จัดเก็บข้อมูลหลักถาวรของเรา เรามีคลัสเตอร์ฐานข้อมูลหลายกลุ่มสำหรับบริการและวัตถุประสงค์ที่หลากหลาย

ความพร้อมใช้งานคงที่ของต้นแบบเป็นตัวบ่งชี้ที่สำคัญของประสิทธิภาพของระบบทั้งหมดและแต่ละส่วนของระบบ การกู้คืนคลัสเตอร์อัตโนมัติในกรณีที่เกิดความล้มเหลวหลักจะช่วยลดเวลาตอบสนองเหตุการณ์และการหยุดทำงานของระบบได้อย่างมาก ในบทความนี้ ฉันจะดูการออกแบบความพร้อมใช้งานสูง (HA) สำหรับคลัสเตอร์ MySQL โดยอิงตาม MySQL ออร์เคสตราเตอร์ และที่อยู่ IP เสมือน (VIP)

โซลูชัน HA ที่ใช้ VIP

ก่อนอื่น ฉันจะบอกคุณสั้นๆ ว่าระบบจัดเก็บข้อมูลของเราคืออะไร

เราใช้โครงร่างการจำลองแบบคลาสสิกกับต้นแบบที่เข้าถึงได้แบบเขียนได้หนึ่งตัวและแบบจำลองแบบอ่านอย่างเดียวหลายตัว คลัสเตอร์สามารถมีต้นแบบระดับกลาง - โหนดที่เป็นทั้งแบบจำลองและต้นแบบสำหรับโหนดอื่น ไคลเอนต์เข้าถึงแบบจำลองผ่าน 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.

ปัญหาอาจเกิดขึ้นในระหว่างกระบวนการกู้คืน ซึ่งควรได้รับแจ้งผ่าน Orchestrator 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 ของเรพลิกาจะทำธุรกรรมที่ยังไม่ได้ใช้ทั้งหมดจากบันทึกการถ่ายทอด เราใช้ตัวเลือกนี้เพื่อหลีกเลี่ยงการสูญเสียธุรกรรมเมื่อแบบจำลองผู้สมัครทั้งหมดล้มเหลว
• InstancePollSeconds — ความถี่ในการสร้างและอัพเดตโทโพโลยี
• RecoveryPollSeconds — ความถี่ของการวิเคราะห์โทโพโลยี หากตรวจพบปัญหา การกู้คืนโทโพโลยีจะเริ่มต้นขึ้น นี้ คงที่เท่ากับ 1 วินาที

แต่ละโหนดคลัสเตอร์จะถูกสำรวจโดยผู้ดำเนินการทุกครั้ง InstancePollSeconds วินาที เมื่อตรวจพบปัญหา สถานะของคลัสเตอร์จะถูกบังคับ อัพเดทจากนั้นจะมีการตัดสินใจขั้นสุดท้ายในการดำเนินการฟื้นฟู ด้วยการทดลองกับฐานข้อมูลและพารามิเตอร์ออร์เคสตราที่แตกต่างกัน เราสามารถลดเวลาตอบสนองและการกู้คืนลงเหลือ 30 วินาที

แท่นทดสอบ

เราเริ่มทดสอบโครงการ HA ด้วยการพัฒนาท้องถิ่น ม้านั่งทดสอบ และการใช้งานเพิ่มเติมในสภาพแวดล้อมการทดสอบและการใช้งานจริง แท่นวางในพื้นที่เป็นแบบอัตโนมัติโดยสมบูรณ์โดยใช้ Docker และช่วยให้คุณสามารถทดลองกับการกำหนดค่าของออเคสตราและเครือข่าย ปรับขนาดคลัสเตอร์จากเซิร์ฟเวอร์ 2-3 เครื่องเป็นหลายสิบเครื่อง และดำเนินการฝึกหัดในสภาพแวดล้อมที่ปลอดภัย

ในระหว่างแบบฝึกหัด เราเลือกวิธีจำลองปัญหาวิธีใดวิธีหนึ่ง: ยิงอาจารย์ทันทีโดยใช้ kill -9ยุติกระบวนการอย่างนุ่มนวลและหยุดเซิร์ฟเวอร์ (docker-compose stop) จำลองปัญหาเครือข่ายโดยใช้ iptables -j REJECT หรือ iptables -j DROP. เราคาดหวังผลลัพธ์ดังต่อไปนี้:

• ผู้จัดทำจะตรวจพบปัญหากับต้นแบบและอัปเดตโทโพโลยีภายในไม่เกิน 10 วินาที
• ขั้นตอนการกู้คืนจะเริ่มขึ้นโดยอัตโนมัติ: การกำหนดค่าเครือข่ายจะเปลี่ยนไป บทบาทของต้นแบบจะถูกส่งต่อไปยังแบบจำลอง โทโพโลยีจะถูกสร้างขึ้นใหม่
• ต้นแบบใหม่จะสามารถเขียนได้ แบบจำลองสดจะไม่สูญหายระหว่างกระบวนการสร้างใหม่
• ข้อมูลจะเริ่มเขียนไปยังต้นแบบใหม่และจำลองแบบ
• เวลาพักฟื้นทั้งหมดจะไม่เกิน 30 วินาที

ดังที่คุณทราบ ระบบอาจทำงานแตกต่างกันในสภาพแวดล้อมการทดสอบและการใช้งานจริงเนื่องจากการกำหนดค่าฮาร์ดแวร์และเครือข่ายที่แตกต่างกัน ความแตกต่างในโหลดสังเคราะห์และโหลดจริง เป็นต้น ดังนั้นเราจึงดำเนินการฝึกซ้อมในสภาวะจริงเป็นระยะๆ โดยตรวจสอบว่าระบบทำงานอย่างไรเมื่อการเชื่อมต่อเครือข่ายขาดหายหรือแต่ละส่วนของระบบลดระดับลง ในอนาคต เราต้องการสร้างโครงสร้างพื้นฐานที่เหมือนกันโดยสิ้นเชิงสำหรับทั้งสองสภาพแวดล้อมและทำให้การทดสอบเป็นแบบอัตโนมัติ

ผลการวิจัย

ความสมบูรณ์ของโหนดระบบจัดเก็บข้อมูลหลักเป็นหนึ่งในงานหลักของ SRE และทีมปฏิบัติการ การนำ orchestrator และโซลูชัน HA ไปใช้ VIP ช่วยให้เราบรรลุผลลัพธ์ดังต่อไปนี้:

• การตรวจจับปัญหาที่เชื่อถือได้กับโทโพโลยีของคลัสเตอร์ฐานข้อมูล
• การตอบสนองอัตโนมัติและรวดเร็วต่อเหตุการณ์ที่เกี่ยวข้องกับหลัก ช่วยลดเวลาหยุดทำงานของระบบ

อย่างไรก็ตาม โซลูชันนี้มีข้อจำกัดและข้อเสีย:

• การขยายโครงร่าง HA ไปยังศูนย์ข้อมูลหลายแห่งจะต้องใช้เครือข่าย L2 เดียวระหว่างศูนย์เหล่านั้น
• ก่อนที่จะมอบหมาย VIP ให้กับมาสเตอร์คนใหม่ เราต้องปล่อยมันบนมาสเตอร์เก่าเสียก่อน กระบวนการนี้เป็นไปตามลำดับซึ่งจะเพิ่มเวลาในการฟื้นตัว
• การปล่อย VIP จำเป็นต้องมีการเข้าถึง SSH ไปยังเซิร์ฟเวอร์ หรือวิธีการอื่นใดในการเรียกขั้นตอนระยะไกล เนื่องจากเซิร์ฟเวอร์หรือฐานข้อมูลกำลังประสบปัญหาที่ทำให้เกิดกระบวนการกู้คืน เราจึงไม่สามารถแน่ใจได้ว่าการลบ VIP จะเสร็จสมบูรณ์ได้สำเร็จ และอาจนำไปสู่การปรากฏตัวของเซิร์ฟเวอร์สองเครื่องที่มีที่อยู่ IP เสมือนเดียวกันและเกิดปัญหาได้ split brain.

หลีกเลี่ยง split brainคุณสามารถใช้วิธีนี้ได้ สโตนิธ (“Shoot The Other Node In The Head”) ซึ่งจะแยกหรือปิดใช้งานโหนดปัญหาโดยสมบูรณ์ มีวิธีอื่นๆ ในการใช้ความพร้อมใช้งานสูงของคลัสเตอร์: การผสมผสานระหว่าง VIP และ DNS การค้นหาบริการและบริการพร็อกซี การจำลองแบบซิงโครนัส และวิธีการอื่นๆ ที่มีข้อเสียและข้อดีในตัวเอง

ฉันพูดคุยเกี่ยวกับแนวทางของเราในการสร้างคลัสเตอร์เฟลโอเวอร์ MySQL ใช้งานง่ายและให้ความน่าเชื่อถือในระดับที่ยอมรับได้ภายใต้สภาวะปัจจุบัน เมื่อระบบทั้งหมดโดยทั่วไปและโครงสร้างพื้นฐานได้รับการพัฒนาโดยเฉพาะ แนวทางนี้ก็จะพัฒนาไปอย่างไม่ต้องสงสัย

ที่มา: will.com