MySQL เป็นระบบจัดการฐานข้อมูลเชิงสัมพันธ์แบบโอเพ่นซอร์สที่ใช้กันอย่างแพร่หลายในการจัดการและจัดเก็บข้อมูลที่มีโครงสร้าง มีชื่อเสียงในด้านความเรียบง่าย การใช้งานที่ง่าย และความสามารถในการขยายตัว ทำให้เป็นตัวเลือกยอดนิยมสำหรับแอปพลิเคชันต่างๆ ตั้งแต่เว็บไซต์ขนาดเล็กไปจนถึงองค์กรขนาดใหญ่
สำหรับการซิงโครไนซ์ข้อมูลแบบเรียลไทม์ ความต้องการหลักคือการดำเนินการบนพื้นฐานของบันทึก (logs) ซึ่งทำให้สามารถซิงโครไนซ์ข้อมูลได้แบบเกือบเรียลไทม์ โดยไม่ก่อให้เกิดข้อจำกัดเพิ่มเติมต่อการออกแบบและนำไปใช้งานฐานข้อมูลเอง จุดประสงค์ของการทำ การจำลองข้อมูลแบบซิงโครนัส MySQL แบบแอคทีฟ-แอคทีฟ คือเพื่อให้มั่นใจในความพร้อมใช้งานอย่างต่อเนื่องและการทนต่อข้อผิดพลาด ต่อไปนี้คือ 4 วิธีในการทำ MySQL active-active การจำลองข้อมูลแบบซิงโครนัส
การจำลองข้อมูลแบบมาสเตอร์-มาสเตอร์ โดยใช้ฟังก์ชันการจำลองข้อมูลพื้นฐานของฐานข้อมูล MySQL
มักเหมาะสำหรับการใช้งานในระดับเล็กถึงปานกลาง
ในสถาปัตยกรรมนี้ สองโหนดสามารถใช้โหมดมาสเตอร์คู่อย่างง่ายและใช้การเชื่อมต่อเฉพาะได้ หากเกิดข้อผิดพลาดในโหนดมาสเตอร์_เอ การเชื่อมต่อแอปพลิเคชันสามารถสลับไปยังโหนดมาสเตอร์_บีได้อย่างรวดเร็ว และในทางกลับกันก็เป็นเช่นเดียวกัน
เพื่อป้องกันสถานการณ์แยกสมอง (split-brain) ซึ่งทั้งสองโหนดเขียนข้อมูลที่ขัดแย้งกัน มีความสำคัญที่จะต้องกำหนดค่าที่แตกต่างกันสำหรับ auto-increment-increment และ auto-increment-offset บนโหนดทั้งสอง เนื่องจากหากโหนดหลักขัดข้องหรือไม่สามารถใช้งานได้โดยไม่คาดคิด ก็มีความเป็นไปได้ว่าเหตุการณ์บางอย่างในบันทึกไบนารี (binlog events) อาจไม่ถูกทำซ้ำไปยังโหนดสำรอง ในกรณีเช่นนี้ อาจเกิดความขัดแย้งระหว่างค่า auto-increment ที่สร้างขึ้นบนโหนดสำรองกับค่าเดิมบนโหนดหลัก
อย่างไรก็ตาม หากมีกลไกทนต่อข้อผิดพลาดที่เหมาะสมในการแก้ไขปัญหาการชนกันของ ID ที่เพิ่มอัตโนมัติระหว่างมาสเตอร์และสลาก็อาจเป็นไปได้ที่จะหลีกเลี่ยงการใช้วิธีดังกล่าว ในเวอร์ชัน MySQL ที่อัปเดตแล้วตั้งแต่ 5.7 เป็นต้นไป การใช้การจำลองข้อมูลแบบหลายเธรด (multi-threaded replication) สามารถช่วยลดความหน่วงของการจำลองข้อมูลได้อย่างมีประสิทธิภาพ นอกจากนี้ อีกทางเลือกหนึ่งที่ไวต่อความล่าช้าของการจำลองแบบเป็นพิเศษคือการจำลองแบบแบบกึ่งซิงค์ (semi-sync replication) ซึ่งแทบไม่มีความล่าช้าเลย อย่างไรก็ตาม วิธีนี้อาจทำให้ประสิทธิภาพการประมวลผลธุรกรรมพร้อมกันลดลง โดยเฉพาะในกรณีที่เขียนสองทิศทาง การตัดสินใจควรพิจารณาอย่างรอบด้าน
โซลูชันที่อิงตามการจำลองข้อมูลของ Galera
Galera เป็นกลไกการจำลองแบบการซิงค์ข้อมูลแบบมัลติมาสเตอร์ที่พัฒนาโดย Codership ซึ่งช่วยให้สามารถทำรายการจำลองแบบข้อมูลแบบซิงโครนัส รวมถึงการอ่านและการเขียนบนโหนดหลายตัวได้ ทำให้มั่นใจได้ถึงความพร้อมใช้งานสูงและความสอดคล้องของข้อมูลในฐานข้อมูล โซลูชันหลักที่รองรับความพร้อมใช้งานสูงโดยอิงจาก Galera ได้แก่ MariaDB Galera Cluster และ Percona XtraDB Cluster (PXC)
ในปัจจุบัน PXC ถูกใช้งานอย่างแพร่หลายมากกว่าและให้ความสอดคล้องของข้อมูลอย่างเข้มงวด ทำให้เหมาะอย่างยิ่งสำหรับอีคอมเมิร์ซ อย่างไรก็ตาม PXC ก็มีข้อจำกัดเช่นกัน ในสถานการณ์ที่มีปริมาณธุรกรรมพร้อมกันสูง แนะนำให้ใช้เครือข่าย InfiniBand เพื่อลดความล่าช้าของเครือข่าย เนื่องจาก PXC อาจประสบปัญหาการขยายการเขียน (write amplification) และผลกระทบจากคอขวด ซึ่งทำให้ประสิทธิภาพในการทำงานพร้อมกันลดลงอย่างมาก เช่นเดียวกับการจำลองแบบแบบกึ่งซิงค์ (semi-sync replication) การจำลองแบบ Galera มักจำกัดไว้ที่สามโหนด นอกจากนี้ ความผันผวนของเครือข่ายสามารถก่อให้เกิดปัญหาด้านประสิทธิภาพและความเสถียร
โซลูชันที่อิงตาม Group Replication
MGR (MySQL Group Replication) เป็นโซลูชันสำหรับความพร้อมใช้งานสูงที่ MySQL แนะนำอย่างเป็นทางการ ซึ่งให้การรับประกันความสอดคล้องของข้อมูลที่เข้มงวดระหว่างโหนดต่างๆ ในกลุ่มฐานข้อมูลผ่านโปรโตคอล Paxos MGR สร้างขึ้นบนเทคโนโลยีการทำซ้ำแบบเนทีฟและจัดจำหน่ายในรูปแบบปลั๊กอิน ช่วยให้โหนดทั้งหมดในกลุ่มสามารถเขียนข้อมูลได้ แก้ปัญหาข้อจำกัดด้านประสิทธิภาพของกลุ่มเดี่ยว แก้ไขปัญหา split-brain ที่เกิดจากเครือข่ายแบ่งส่วน และยกระดับความน่าเชื่อถือของข้อมูลที่ทำซ้ำ
อย่างไรก็ตาม ความเป็นจริงค่อนข้างโหดร้าย ในขณะนี้ยังมีผู้ใช้งานระยะแรกของ MGR ไม่มากนัก นอกจากนี้ยังรองรับเฉพาะตาราง InnoDB เท่านั้น และต้องการให้แต่ละตารางมี primary key เพื่อการตรวจสอบความขัดแย้งของชุดคำสั่งเขียน (write set) จะต้องเปิดใช้งานคุณลักษณะ GTID และตั้งค่ารูปแบบ binary log เป็น ROW เพื่อการเลือกผู้นำและการจัดการชุดคำสั่งเขียน
COMMIT อาจล้มเหลวได้ โดยมีสถานการณ์ล้มเหลวคล้ายกับระดับการแยกข้อมูลแบบ snapshot ในปัจจุบัน กลุ่ม MGR (MySQL Group Replication) รองรับโหนดสูงสุด 9 โหนดเท่านั้น และไม่รองรับคุณสมบัติ foreign keys และ save point ซึ่งทำให้ไม่สามารถตรวจสอบข้อจำกัดทั่วโลกหรือยกเลิกการทำงานบางส่วนได้ บันทึกไบนารีไม่รองรับการตรวจสอบผลรวมของเหตุการณ์ binlog
โซลูชันที่อิงตามCanal
สำหรับการซิงค์ข้อมูลในฐานข้อมูลแบบเรียลไทม์ อาลีบาบามีโปรเจกต์โอเพนซอร์สที่ใช้เฉพาะทางชื่อ Otter ซึ่งทำให้สามารถทำสำเนาฐานข้อมูลแบบกระจายได้อย่างต่อเนื่อง แนวคิดหลักของ Otter ยังคงอยู่บนพื้นฐานของการจับข้อมูลลอจ์ที่เพิ่มขึ้นจากฐานข้อมูล เพื่อให้เกิดการทำสำเนาแบบซิงค์ใกล้เคียงเรียลไทม์ Otter เองอาศัยโปรเจกต์โอเพนซอร์สอีกตัวหนึ่งที่เรียกว่า Canal ซึ่งมุ่งเน้นไปที่การจับข้อมูลลอจ์การซิงค์ฐานข้อมูลที่เพิ่มขึ้น
ปัจจุบัน Otter มุ่งเน้นไปที่การบรรลุการจำลองข้อมูลแบบซิงโครนัสระหว่างฐานข้อมูล MySQL โดยใช้เทคโนโลยีที่คล้ายกันเพื่อให้เกิดการจำลองข้อมูลแบบสองทางระหว่างฐานข้อมูล MySQL สองตัว ควรสังเกตว่า การจำลองแบบสองทางที่กล่าวถึงนี้หมายถึง ข้อมูลสามารถซิงค์ได้ทั้งจาก A ไป B หรือจาก B ไป A แต่ในช่วงเวลาใดเวลาหนึ่งอาจเป็นการซิงค์แบบทางเดียว
ขั้นตอนการจำลองแบบมาสเตอร์-สเลฟสามารถแบ่งออกเป็นสามขั้นตอนได้ดังนี้:
1. มาสเตอร์บันทึกการเปลี่ยนแปลงลงในบันทึกไบนารี ซึ่งเป็นที่รู้จักกันในชื่อเหตุการณ์บันทึกไบนารี เหตุการณ์เหล่านี้สามารถดูได้โดยใช้คำสั่ง "show binlog events"
2. สเลฟจะคัดลอกเหตุการณ์บันทึกไบนารีจากมาสเตอร์ไปยังรีเลย์ลอจของตัวเอง
3. สเลฟจะทำตามเหตุการณ์ที่บันทึกไว้ในรีเลย์ลอคแบบตามลำดับ เพื่อนำการเปลี่ยนแปลงจากมาสเตอร์ไปใช้กับข้อมูลของตนเอง
สำหรับหลักการของ Canal นั้นค่อนข้างตรงไปตรงมา:
1. Canal จำลองโปรโตคอลการโต้ตอบของ MySQL slave โดยปลอมตัวเป็น MySQL slave และส่งคำขอ dump ไปยัง MySQL master
2. เมื่อได้รับคำขอ dump MySQL มาสเตอร์จะเริ่มส่งบันทึกไบนารีไปยังสเลฟ (ซึ่งก็คือ Canal)
3. Canal จากนั้นจะแยกวิเคราะห์อ็อบเจกต์บันทึกไบนารี (เดิมอยู่ในรูปแบบสตรีมไบต์) เพื่อดึงข้อมูลที่เกี่ยวข้องออกมา
สำรองข้อมูลฐานข้อมูล MySQL ด้วย Vinchin Backup & Recovery
เพื่อปกป้องข้อมูลให้ดียิ่งขึ้น ขอแนะนำให้คุณสำรองข้อมูลฐานข้อมูลของคุณ Vinchin Backup & Recovery มีฟังก์ชันการทำงานที่ทรงพลังเพื่อปกป้องฐานข้อมูลของคุณทั้งในเครื่องเสมือนและเซิร์ฟเวอร์จริง โดยการประสานงานอย่างราบรื่นกับการสำรองข้อมูลระดับเครื่องเสมือน ทำให้ผู้ใช้งานสภาพแวดล้อมเสมือนได้รับการประกันความปลอดภัยข้อมูลทางธุรกิจสำคัญและระบบสารสนเทศเป็นสองเท่า
Vinchin Backup & Recovery รองรับการป้องกัน Oracle DB, MySQL, SQL Server, PostgreSQL, Postgres Pro และ MariaDB ที่ติดตั้งบนเครื่องจริงและเครื่องเสมือนด้วยคุณสมบัติการสำรองข้อมูลและการกู้คืนฐานข้อมูลที่ทรงพลัง นอกจากนี้ยังมีกลยุทธ์การสำรองข้อมูลแบบเต็มรูปแบบ การสำรองข้อมูลแบบต่างระดับ การสำรองข้อมูลแบบเพิ่มเติม และการสำรองข้อมูลล็อกการทำธุรกรรม เพื่อให้คุณสามารถตั้งแผนการสำรองข้อมูลของคุณได้ตามต้องการ
Vinchin Backup & Recovery รองรับการสำรองข้อมูลแบบฮ็อตอย่างมีประสิทธิภาพ โดยไม่กระทบต่อการทำงานปกติของฐานข้อมูล และสามารถสร้างงานสำรองข้อมูลฐานข้อมูลที่กำหนดเองได้อย่างง่ายดาย
1. เลือกฐานข้อมูลเป้าหมาย
2. เลือกที่จัดเก็บข้อมูลสำรอง
3. เลือกกลยุทธ์การสำรองข้อมูล
4. ส่งงาน
คุณสามารถเริ่มใช้งานระบบที่มีประสิทธิภาพนี้ได้ด้วยการทดลองใช้งานฟรีแบบครบฟีเจอร์ 60 วัน เพียงคลิกที่ปุ่มเพื่อรับแพ็คเกจติดตั้ง คุณสามารถคลิกที่นี่เพื่อเรียนรู้เพิ่มเติมเกี่ยวกับ วิธีสำรองข้อมูล MySQL ด้วย Vinchin Backup & Recovery
สรุป
การจำลองข้อมูลแบบ active-active ของ MySQL ถูกออกแบบมาเพื่อให้มีความพร้อมใช้งานสูงและความยืดหยุ่น โดยอนุญาตให้สามารถใช้งานอินสแตนซ์ MySQL หลายตัวพร้อมกัน และทำให้ข้อมูลซิงค์กันระหว่างกันได้ ซึ่งช่วยให้สามารถอ่านและเขียนข้อมูลสองทิศทางได้อย่างต่อเนื่อง นอกจากนี้ยังช่วยให้มีความพร้อมในการใช้งานอยู่เสมอ การกระจายภาระงาน ความสม่ำเสมอของข้อมูล และความยืดหยุ่น อย่างไรก็ตาม การตั้งค่าและการจัดการที่เหมาะสมมีความสำคัญอย่างมาก และการเลือกวิธีการดำเนินการหรือเครื่องมือต่าง ๆ ขึ้นอยู่กับความต้องการเฉพาะเจาะจง
เพื่อปกป้องข้อมูลในฐานข้อมูลอย่างมีประสิทธิภาพ คุณสามารถเลือกใช้ Vinchin Backup & Recovery เพื่อสำรองข้อมูลและกู้คืนฐานข้อมูลได้อย่างง่ายดาย อย่าพลาดการทดลองใช้งานฟรี
