สถาปัตยกรรรม Galera mariadb

สถาปัตยกรรมของ MariaDB Galera Cluster เป็นโซลูชันฐานข้อมูลที่โดดเด่นในเรื่อง ความพร้อมใช้งานสูง (High Availability) และ การจำลองข้อมูลแบบซิงโครนัส (Synchronous Replication) โดยมีคุณสมบัติหลักที่เรียกว่า “Multi-Master Active-Active”

นี่คือคำอธิบายสถาปัตยกรรมและส่วนประกอบหลัก:

---

1. คุณสมบัติหลัก

• Multi-Master (Active-Active):
  • คุณสามารถ อ่าน (Read) และ เขียน (Write) ข้อมูลไปยัง โหนดใดๆ ก็ได้ ในคลัสเตอร์
  • โหนดทุกตัวทำงานเป็น “Master” ได้พร้อมกัน ซึ่งแตกต่างจากการจำลองข้อมูลแบบดั้งเดิม (Master-Slave) ที่มี Master เพียงตัวเดียว
• Synchronous Replication (การจำลองข้อมูลแบบซิงโครนัส):
  • เมื่อมีการทำธุรกรรม (Transaction) และผู้ใช้สั่ง COMMIT การเปลี่ยนแปลงข้อมูลจะถูกจำลองและยืนยันในโหนดอื่นๆ ทั้งหมด ก่อนที่จะแจ้งกลับไปยังผู้ใช้ว่าการทำธุรกรรมสำเร็จ
  • ทำให้มั่นใจได้ว่า ข้อมูลจะสอดคล้องกัน ในทุกโหนดเสมอ (ไม่มี Slave Lag) และ ไม่มีการสูญเสียข้อมูล ในกรณีที่โหนดล้มเหลว
• Parallel Replication (การจำลองแบบขนาน):
  • Galera สามารถจำลองข้อมูลในระดับแถว (Row Level) และประยุกต์ใช้ (Apply) การเปลี่ยนแปลงแบบขนานกันได้ ซึ่งช่วยเพิ่มประสิทธิภาพการเขียนโดยรวมของคลัสเตอร์

2. ส่วนประกอบสำคัญ

MariaDB Galera Cluster ถูกสร้างขึ้นโดยการรวม MariaDB Server เข้ากับ Galera Replication Provider

ส่วนประกอบ	คำอธิบาย
MariaDB Server	เป็นเซิร์ฟเวอร์ฐานข้อมูลหลักที่รองรับการเชื่อมต่อของแอปพลิเคชัน โดยจำเป็นต้องกำหนดค่าให้ใช้ Storage Engine ที่รองรับ Transaction (เช่น InnoDB หรือ XtraDB) และตั้งค่า binlog_format=ROW
wsrep API	(Write Set REPlication API) เป็นอินเทอร์เฟซที่ MariaDB ใช้สื่อสารกับ Galera Replication Provider เพื่อส่งข้อมูลการทำธุรกรรม
Galera Replication Provider	เป็นไลบรารี (libgalera_smm.so) ที่ทำหน้าที่จัดการการจำลองข้อมูล การควบคุมสมาชิก และ Quorum เป็นหัวใจสำคัญของคลัสเตอร์
Write Set	คือกลุ่มของการเปลี่ยนแปลงข้อมูลที่เกิดขึ้นใน Transaction หนึ่งๆ ซึ่งจะถูกห่อหุ้มและส่งไปยังโหนดอื่นๆ เพื่อให้โหนดเหล่านั้นประยุกต์ใช้การเปลี่ยนแปลง (Apply)

3. กลไกการทำงานของ Galera

A. Certification-Based Replication (การจำลองข้อมูลตามการรับรอง)

นี่คือวิธีที่ Galera จัดการการเขียน:

1. การเขียนข้อมูล (Write): ไคลเอนต์เขียนข้อมูลไปยังโหนด A
2. การเตรียม Write Set: โหนด A รวบรวมการเปลี่ยนแปลงในรูปแบบของ Write Set และส่งไปยังโหนดอื่นๆ ทั้งหมด
3. การรับรอง (Certification): โหนดอื่นๆ แต่ละตัวจะตรวจสอบ Write Set ว่า ขัดแย้ง (Conflict) กับ Transaction อื่นๆ ที่กำลังดำเนินอยู่หรือไม่ (เช่น มีการพยายามแก้ไขแถวเดียวกันหรือไม่)
   • การตรวจสอบนี้ทำให้เกิด Deadlock ใน Galera ได้
4. การสั่งงาน (Ordering): โหนดที่รับ Write Set จะให้ Global Transaction ID (GTID) ที่เป็นลำดับเดียวกัน (Global Ordering) เพื่อให้มั่นใจว่าทุกโหนดประยุกต์ใช้การเปลี่ยนแปลงในลำดับเดียวกัน
5. การยืนยัน (Commit):
   • หาก ไม่มีความขัดแย้ง โหนดทั้งหมดจะยืนยัน (Commit) การเปลี่ยนแปลงนั้น
   • หาก มีความขัดแย้ง (Certification Failed) โหนด A จะต้องยกเลิก (Rollback) Transaction นั้น และแจ้งให้ไคลเอนต์ทราบ

B. State Snapshot Transfer (SST) และ Incremental State Transfer (IST)

กลไกนี้ใช้ในการนำโหนดที่เพิ่งเข้าร่วมคลัสเตอร์ หรือโหนดที่ล้มเหลวไปนาน ให้กลับมามีข้อมูลที่ทันสมัย:

• SST (State Snapshot Transfer):
  • เมื่อโหนดใหม่เข้าร่วมคลัสเตอร์ (หรือโหนดที่ตามหลังมากเกินไป) คลัสเตอร์จะเลือกโหนดหนึ่งเป็น Donor
  • Donor จะ ล็อก (Pause) การเขียน เพื่อสร้างสำเนาข้อมูลที่สมบูรณ์ (Snapshot) และส่งทั้งฐานข้อมูลไปยังโหนดใหม่
  • วิธีการ SST ที่นิยมใช้ เช่น rsync หรือ mariabackup
• IST (Incremental State Transfer):
  • หากโหนดใดโหนดหนึ่งหลุดออกจากคลัสเตอร์ไปเพียงชั่วครู่ และ Write Set ที่พลาดไปนั้นยังอยู่ในแคชของโหนดอื่น (gcache)
  • โหนดนั้นจะสามารถดึงเฉพาะ ส่วนที่ขาดหายไป กลับคืนมาได้ทันทีโดยไม่ต้องทำการถ่ายโอนข้อมูลทั้งหมด (SST) ซึ่งเร็วกว่ามาก

C. Quorum และ Membership Control

• Quorum: คือการกำหนดเสียงข้างมาก (Majority) เพื่อรักษาความเสถียรของคลัสเตอร์ (นี่คือเหตุผลที่แนะนำให้ใช้จำนวนโหนดเป็นเลขคี่)
• Membership Control: หากโหนดใดโหนดหนึ่งล้มเหลวหรือหยุดการตอบสนอง โหนดที่เหลือจะทำการลงคะแนนเพื่อ นำโหนดที่ล้มเหลวออกจากการเป็นสมาชิก โดยอัตโนมัติ เพื่อให้คลัสเตอร์ยังคงทำงานต่อได้โดยไม่หยุดชะงัก (Automatic Node Removal/Join)