โปรเจ็กต์ขนาดใหญ่ใดๆ ก็ตามเริ่มต้นด้วยเซิร์ฟเวอร์สองสามตัว ในตอนแรกมีเซิร์ฟเวอร์ DB หนึ่งตัว จากนั้นทาสก็ถูกเพิ่มเข้าไปเพื่อปรับขนาดการอ่าน แล้ว-หยุด! มีนายคนเดียวแต่มีทาสมากมาย หากทาสคนใดคนหนึ่งออกไปทุกอย่างจะดี แต่ถ้าเจ้านายออกไปก็จะแย่: การหยุดทำงานผู้ดูแลระบบกำลังพยายามยกเซิร์ฟเวอร์ จะทำอย่างไร? จองนายครับ. พาเวลเพื่อนร่วมงานของฉันเขียนเกี่ยวกับเรื่องนี้แล้ว ฉันจะไม่พูดซ้ำ ฉันจะบอกคุณว่าทำไมคุณถึงต้องการ Orchestrator สำหรับ MySQL แทน!
เริ่มจากคำถามหลัก: “เราจะเปลี่ยนรหัสเป็นเครื่องใหม่ได้อย่างไรเมื่อต้นแบบออกไป”
- ฉันชอบรูปแบบ VIP (Virtual IP) มากที่สุด เราจะพูดถึงมันด้านล่าง เป็นวิธีที่ง่ายที่สุดและชัดเจนที่สุดถึงแม้ว่าจะมีข้อจำกัดที่ชัดเจน: ต้นแบบที่เราจะจองจะต้องอยู่ในเซ็กเมนต์ L2 ด้วยเครื่องใหม่นั่นคือเราสามารถลืม DC ตัวที่สองได้ และในทางที่เป็นมิตร หากคุณปฏิบัติตามกฎที่ว่า L2 ขนาดใหญ่นั้นชั่วร้าย เนื่องจาก L2 เป็นเพียงต่อแร็คเท่านั้น และ L3 อยู่ระหว่างแร็ค และรูปแบบดังกล่าวยังมีข้อจำกัดที่มากกว่านั้นอีก
- คุณสามารถเขียนชื่อ DNS ลงในโค้ดและแก้ไขผ่าน /etc/hosts ในความเป็นจริงจะไม่มีการลงมติ ข้อดีของโครงการ: ไม่มีข้อจำกัดลักษณะเฉพาะของวิธีแรก นั่นคือ สามารถจัดระเบียบ cross-DC ได้ แต่แล้วคำถามที่ชัดเจนก็เกิดขึ้น: เราจะส่งมอบการเปลี่ยนแปลงไปยัง /etc/hosts ผ่าน Puppet-Ansible ได้เร็วแค่ไหน?
- คุณสามารถเปลี่ยนวิธีที่สองได้เล็กน้อย: ติดตั้งแคช DNS บนเว็บเซิร์ฟเวอร์ทั้งหมดซึ่งโค้ดจะถูกส่งไปยังฐานข้อมูลหลัก คุณสามารถตั้งค่า TTL 60 สำหรับรายการนี้ใน DNS ดูเหมือนว่าถ้าปฏิบัติอย่างถูกต้องวิธีการก็ดี
- โครงการที่มีการค้นพบบริการโดยนัยถึงการใช้กงสุลและอื่น ๆ
- ตัวเลือกที่น่าสนใจด้วย . คุณต้องกำหนดเส้นทางการรับส่งข้อมูลทั้งหมดไปยัง MySQL ผ่าน ProxySQL โดยตัว ProxySQL เองสามารถระบุได้ว่าใครคือมาสเตอร์ โดยวิธีการที่คุณสามารถอ่านเกี่ยวกับหนึ่งในตัวเลือกสำหรับการใช้ผลิตภัณฑ์นี้ในของฉัน .
ผู้เขียน Orchestrator ซึ่งทำงานใน Github ได้นำโครงการแรกไปใช้กับ VIP ก่อน จากนั้นจึงแปลงเป็นโครงการกับกงสุล
เค้าโครงโครงสร้างพื้นฐานทั่วไป:
ฉันจะอธิบายสถานการณ์ที่ชัดเจนที่ต้องคำนึงถึงทันที:
- ไม่ควรลงทะเบียนที่อยู่ VIP ในการกำหนดค่าบนเซิร์ฟเวอร์ใดๆ ลองจินตนาการถึงสถานการณ์: ต้นแบบรีบูตเครื่อง และในขณะที่กำลังโหลด Orchestrator ก็เข้าสู่โหมดเฟลโอเวอร์และทำให้ทาสตัวหนึ่งเป็นมาสเตอร์ จากนั้นนายเฒ่าก็ลุกขึ้น และตอนนี้ VIP อยู่บนรถสองคัน นี้ไม่ดี.
- สำหรับผู้เรียบเรียงคุณจะต้องเขียนสคริปต์สำหรับการเรียกอาจารย์เก่าและอาจารย์คนใหม่ บนมาสเตอร์ตัวเก่า คุณจะต้องรัน ifdown และบนมาสเตอร์ตัวใหม่ – ifup vip คงจะดีไม่น้อยหากรวมไว้ในสคริปต์นี้ว่าในกรณีที่เกิดข้อผิดพลาด พอร์ตบนสวิตช์ของต้นแบบตัวเก่าจะถูกปิดเพื่อหลีกเลี่ยงการแยกสมอง
- หลังจากที่ Orchestrator เรียกสคริปต์ของคุณเพื่อลบ VIP และ/หรือดับพอร์ตบนสวิตช์ก่อน จากนั้นจึงเรียกสคริปต์การเพิ่ม VIP บนต้นแบบใหม่ อย่าลืมใช้คำสั่ง arping เพื่อบอกทุกคนว่า VIP ใหม่อยู่ในขณะนี้ ที่นี่.
- สเลฟทั้งหมดควรมี read_only=1 และทันทีที่คุณเลื่อนสเลฟเป็นมาสเตอร์ก็ควรมี read_only=0
- อย่าลืมว่าทาสใด ๆ ที่เราเลือกไว้สำหรับสิ่งนี้สามารถเป็นเจ้านายได้ (Orchestrator มีกลไกการตั้งค่าทั้งหมดซึ่งทาสจะต้องพิจารณาเป็นผู้สมัครสำหรับเจ้านายคนใหม่ในอันดับแรกซึ่งในอันดับที่สองและทาสคนใดควร จะไม่ถูกเลือกเลยไม่ว่าในกรณีใด ๆ ก็ตาม) หากทาสกลายเป็นนาย ภาระของทาสจะยังคงอยู่และภาระของนายจะถูกเพิ่มเข้าไป ซึ่งจะต้องนำมาพิจารณาด้วย
ทำไมคุณถึงต้องการ Orchestrator หากคุณไม่มี?
- Orchestrator มีส่วนต่อประสานกราฟิกที่ใช้งานง่ายซึ่งแสดงโทโพโลยีทั้งหมด (ดูภาพหน้าจอด้านล่าง)
- Orchestrator สามารถติดตามได้ว่าทาสคนไหนล้าหลัง และโดยทั่วไปการจำลองแบบใช้งานไม่ได้ (เรามีสคริปต์แนบอยู่กับ Orchestrator เพื่อส่ง SMS)
- Orchestrator จะบอกคุณว่าทาสคนไหนมีข้อผิดพลาด GTID
อินเตอร์เฟซออร์เคสตรา:
GTID ผิดพลาดคืออะไร
มีข้อกำหนดหลักสองประการสำหรับ Orchestrator ในการทำงาน:
- จำเป็นต้องเปิดใช้งาน Pseudo GTID บนเครื่องทั้งหมดในคลัสเตอร์ MySQL โดยเราได้เปิดใช้งาน GTID แล้ว
- จำเป็นต้องมี binlogs ประเภทเดียวทุกที่ คุณสามารถใช้คำสั่งได้ เรามีการกำหนดค่าที่เจ้านายและทาสส่วนใหญ่มีแถว และสองแห่งในอดีตยังคงอยู่ในโหมดผสม เป็นผลให้ Orchestrator ไม่ต้องการเชื่อมต่อทาสเหล่านี้กับมาสเตอร์คนใหม่
โปรดจำไว้ว่าสิ่งที่สำคัญที่สุดในทาสการผลิตคือความสม่ำเสมอกับเจ้านาย! หากคุณเปิดใช้งาน Global Transaction ID (GTID) ไว้ทั้งบนหลักและรอง คุณสามารถใช้ฟังก์ชัน gtid_subset เพื่อดูว่ามีการดำเนินการคำขอเดียวกันสำหรับการเปลี่ยนแปลงข้อมูลบนเครื่องเหล่านี้จริงหรือไม่ คุณสามารถอ่านเพิ่มเติมเกี่ยวกับเรื่องนี้ได้ .
ดังนั้น Orchestrator จะแสดงให้คุณเห็นผ่าน GTID ที่ผิดพลาดว่ามีธุรกรรมบนทาสที่ไม่ได้อยู่ในต้นแบบ ทำไมสิ่งนี้ถึงเกิดขึ้น?
- Read_only=1 ไม่ได้เปิดใช้งานบนทาส มีคนเชื่อมต่อและดำเนินการตามคำขอเปลี่ยนแปลงข้อมูลแล้ว
- Super_read_only=1 ไม่ได้เปิดใช้งานบนทาส จากนั้นผู้ดูแลระบบเมื่อสับสนเซิร์ฟเวอร์ จึงเข้าไปและดำเนินการตามคำขอที่นั่น
- หากคุณคำนึงถึงทั้งสองประเด็นก่อนหน้านี้ มีเคล็ดลับอีกอย่างหนึ่ง: ใน MySQL คำขอล้าง binlog จะไปที่ binlog ด้วย ดังนั้นในการล้างครั้งแรก GTID ผิดพลาดจะปรากฏบนต้นแบบและทาสทั้งหมด จะหลีกเลี่ยงสิ่งนี้ได้อย่างไร? Perona-5.7.25-28 แนะนำการตั้งค่า binlog_skip_flush_commands=1 ซึ่งห้ามไม่ให้เขียนฟลัชลงใน binlogs มีอันที่จัดตั้งขึ้นบนเว็บไซต์ mysql.com .
ผมขอสรุปทั้งหมดข้างต้น หากคุณไม่ต้องการใช้ Orchestrator ในโหมดเฟลโอเวอร์ ให้ตั้งค่าไว้ในโหมดการสังเกต จากนั้น คุณจะมองเห็นแผนที่ของการโต้ตอบของเครื่อง MySQL และข้อมูลภาพเกี่ยวกับประเภทของการจำลองแบบในแต่ละเครื่องต่อหน้าต่อตา ไม่ว่าทาสจะล้าหลังหรือไม่ และที่สำคัญที่สุดคือพวกเขามีความสอดคล้องกับต้นแบบเพียงใด!
คำถามที่ชัดเจนคือ “Orchestrator ควรทำงานอย่างไร” เขาต้องเลือกต้นแบบใหม่จากทาสปัจจุบัน จากนั้นเชื่อมต่อทาสทั้งหมดเข้ากับมันใหม่ (นี่คือสิ่งที่ GTID จำเป็น หากคุณใช้กลไกเก่ากับ binlog_name และ binlog_pos ให้เปลี่ยนทาสจากต้นแบบปัจจุบันเป็นอันใหม่ เป็นไปไม่ได้เลย!) ก่อนที่เราจะมี Orchestrator ฉันเคยต้องทำทั้งหมดนี้ด้วยตนเอง นายคนเก่าถูกแขวนคอเนื่องจากตัวควบคุม Adaptec แบบบั๊กกี้ ซึ่งมีทาสอยู่ประมาณ 10 คน ฉันจำเป็นต้องโอน VIP จากมาสเตอร์ไปยังทาสคนหนึ่งและเชื่อมต่อทาสอื่น ๆ ทั้งหมดเข้ากับมันอีกครั้ง ฉันต้องเปิดคอนโซลกี่เครื่อง ฉันป้อนคำสั่งพร้อมกันกี่คำสั่ง... ฉันต้องรอจนถึงตี 3 ลบโหลดออกจากทาสทั้งหมดยกเว้นสองเครื่อง สร้างเครื่องแรกจากสองเครื่องหลัก ติดเครื่องที่สองทันที ดังนั้นให้แนบทาสอื่น ๆ ทั้งหมดเข้ากับต้นแบบใหม่และส่งคืนโหลด โดยรวมแล้วแย่มาก...
Orchestrator ทำงานอย่างไรเมื่อเข้าสู่โหมดเฟลโอเวอร์ สิ่งนี้แสดงให้เห็นได้ง่ายที่สุดด้วยตัวอย่างของสถานการณ์ที่เราต้องการทำให้ผู้เชี่ยวชาญมีเครื่องจักรที่ทรงพลังและทันสมัยมากกว่าที่เราเป็นอยู่ตอนนี้
รูปแสดงช่วงกลางของกระบวนการ จนถึงตอนนี้ได้ทำอะไรไปแล้วบ้าง? เราบอกว่าเราต้องการสร้างทาสให้เป็นมาสเตอร์คนใหม่ Orchestrator เริ่มที่จะเชื่อมต่อทาสอื่นๆ ทั้งหมดเข้ากับมันอีกครั้ง โดยที่มาสเตอร์คนใหม่จะทำหน้าที่เป็นเครื่องขนส่ง ด้วยรูปแบบนี้ ไม่มีข้อผิดพลาดเกิดขึ้น สเลฟทั้งหมดทำงานได้ Orchestrator จะลบ VIP ออกจากต้นแบบเก่า โอนไปยังต้นแบบใหม่ ทำให้ read_only=0 และลืมเกี่ยวกับต้นแบบเก่า ทั้งหมด! เวลาหยุดให้บริการของเราคือเวลาโอน VIP ซึ่งก็คือ 2-3 วินาที
นั่นคือทั้งหมดสำหรับวันนี้ ขอบคุณทุกคน จะมีบทความที่สองเกี่ยวกับ Orchestrator เร็วๆ นี้ ในภาพยนตร์โซเวียตชื่อดังเรื่อง "Garage" ตัวละครตัวหนึ่งกล่าวว่า "ฉันจะไม่ไปลาดตระเวนกับเขา!" เอาล่ะ ออร์เคสตราเรเตอร์ ฉันจะไปลาดตระเวนกับคุณ!
ที่มา: will.com