Practical MySQL & MariaDB

อธิบายการทำสำเนา MySQL: การตั้งค่า, GTID, การตรวจสอบ, และคู่มือการแก้ไขปัญหา

ขั้นสูง / อื่น ๆ
目次

1. MySQL Replication คืออะไร? ภาพรวมและกรณีการใช้งาน

MySQL replication เป็นฟีเจอร์ที่ทำให้สำเนาของฐานข้อมูลซิงโครไนซ์กับเซิร์ฟเวอร์อื่น ๆ แบบเรียลไทม์ ซึ่งช่วยเพิ่มความทนทานและประสิทธิภาพของฐานข้อมูล ด้านล่างนี้เราจะอธิบายอย่างละเอียดว่า MySQL replication ถูกใช้เมื่อใดและทำงานอย่างไร

ภาพรวมของ MySQL Replication

MySQL replication แบ่งเนื้อหาฐานข้อมูลระหว่างหลายเซิร์ฟเวอร์โดยใช้ master server และหนึ่งหรือหลาย slave servers โดยเฉพาะ การอัปเดตข้อมูลที่บันทึกใน binary log ของ master server จะถูกอ่านและนำไปใช้โดย slave servers เพื่อให้ข้อมูลสอดคล้องกัน ซึ่งทำให้บริการต่อเนื่องได้โดยการสลับไปใช้ slave server หาก master server เกิดข้อผิดพลาด

กรณีการใช้งานของ MySQL Replication

MySQL replication ถูกนำไปใช้ในสถานการณ์ต่อไปนี้อย่างแพร่หลาย:

  • High Availability : ในกรณีที่เกิดความล้มเหลว การสลับไปใช้ slave server จะช่วยลดเวลาการหยุดทำงานลง
  • Load Balancing : คำสั่งอ่าน‑only สามารถกระจายไปยัง slave servers เพื่อลดภาระบน master server
  • Data Protection and Backup : เนื่องจาก replication ทำสำเนาข้อมูลแบบเรียลไทม์ จึงสามารถทำหน้าที่เป็นกลไกสำรองข้อมูลได้ด้วย

ประเภทของ Replication

MySQL replication มีประเภทต่อไปนี้ตามวิธีการซิงโครไนซ์:

  • Asynchronous Replication : master ดำเนินการต่อโดยไม่ต้องรอการยืนยันจาก slave ซึ่งทำให้ตอบสนองได้เร็วขึ้น แต่บางข้อมูลอาจไม่ถึง slave หากเกิดความล้มเหลว
  • Semi‑Synchronous Replication : master รอการยืนยันว่าข้อมูลได้รับจาก slave แล้วจึงดำเนินการต่อ ซึ่งให้ความน่าเชื่อถือสูงกว่า asynchronous replication แม้จะทำให้ตอบสนองช้าลงเล็กน้อย

ส่วนต่อไปนี้จะอธิบายแนวคิดพื้นฐานของ MySQL replication รวมถึง binary log และ GTID

2. แนวคิดพื้นฐานของ MySQL Replication

เพื่อทำความเข้าใจ MySQL replication จำเป็นต้องเข้าใจบทบาทของ binary log และ GTID (Global Transaction ID) ซึ่งเป็นส่วนสำคัญของกระบวนการ replication องค์ประกอบเหล่านี้เป็นพื้นฐานสำหรับการทำสำเนาข้อมูลที่แม่นยำ

บทบาทของ Master และ Slave

ใน MySQL replication, master server และ slave server มีบทบาทที่แตกต่างกัน master จะบันทึกการอัปเดตข้อมูลลงใน binary log และส่งต่อไปยัง slave ส่วน slave จะนำ log ที่ได้รับไปประมวลผลเพื่ออัปเดตข้อมูลของตนเอง ดังนั้น slave จะมีข้อมูลที่ตรงกับ master เสมอ

Binary Log และ Relay Log

MySQL replication พึ่งพา log สองประเภทต่อไปนี้:

  1. Binary Log
  • Binary log บันทึกการอัปเดตข้อมูล (เช่น INSERT, UPDATE, DELETE) บน master server ซึ่งทำให้ slave server สามารถรักษาสถานะข้อมูลให้ตรงกับ master ได้
  1. Relay Log
  • Relay log เก็บเหตุการณ์จาก binary log ที่รับมาจาก master บน slave server โดยเธรด SQL ของ slave จะทำงานตามลำดับของ relay log เพื่อประยุกต์การเปลี่ยนแปลงข้อมูล

GTID (Global Transaction ID) คืออะไร?

GTID เป็นกลไกที่กำหนด ID ที่ไม่ซ้ำกันให้กับแต่ละ transaction เพื่อช่วยให้คงความสอดคล้องกันระหว่างหลาย slave โดยใช้ GTID จะไม่ต้องระบุตำแหน่งของ binary log อีกต่อไป เพียงแต่ transaction ที่ยังไม่ได้รับจาก master จะถูกนำไปใช้กับ slave โดยอัตโนมัติ ซึ่งทำให้การจัดการง่ายขึ้นอย่างมาก

ข้อดีของ GTID

  • Unique Identification : แต่ละ transaction จะได้รับ GTID ที่เป็นเอกลักษณ์ ทำให้ระบุได้ชัดเจนว่า transaction ใดได้ถูกประมวลผลแล้ว
  • Easier Recovery : เมื่อใช้ GTID จะทำการประมวลผลเฉพาะ transaction ที่ยังไม่ได้ประมวลผลหลังจากการรีสตาร์ทของ master หรือ slave
  • Efficient Operational Management : แม้ในสภาพแวดล้อมขนาดใหญ่ที่มีหลาย slave ก็สามารถคงความสอดคล้องของ transaction ได้ด้วยการจัดการที่ง่ายขึ้น

เพื่อใช้ GTID จำเป็นต้องตั้งค่า gtid_mode=ON และ enforce_gtid_consistency=ON การกำหนดค่านี้บน master และ slave ทั้งสองจะทำให้ replication ใช้ GTID ได้

ส่วนต่อไปนี้จะอธิบายขั้นตอนเฉพาะสำหรับการตั้งค่า MySQL replication.

3. ขั้นตอนการตั้งค่า MySQL Replication

ส่วนนี้อธิบายขั้นตอนที่จำเป็นสำหรับการตั้งค่า MySQL replication โดยทำตามขั้นตอนเหล่านี้คุณจะสามารถกำหนดโครงสร้าง master‑slave เบื้องต้นและเปิดใช้งานการซิงโครไนซ์ข้อมูลแบบเรียลไทม์ได้

การกำหนดค่าเซิร์ฟเวอร์ Master

ก่อนอื่นให้แก้ไขไฟล์การกำหนดค่าของเซิร์ฟเวอร์ master (โดยทั่วไปคือ my.cnf หรือ my.ini) เพื่อเปิดใช้งาน binary log และตั้งค่า server ID

  1. แก้ไขไฟล์การกำหนดค่า
  • เพิ่มการตั้งค่าต่อไปนี้ภายใต้ส่วน [mysqld] และกำหนด server ID ที่ไม่ซ้ำกัน (เช่น 1)
    [mysqld]
server-id=1
log-bin=mysql-bin
  • server-id ต้องเป็นหมายเลขที่ไม่ซ้ำกันสำหรับแต่ละเซิร์ฟเวอร์ และ log-bin จะเปิดใช้งาน binary log
  1. สร้างผู้ใช้ Replication
  • สร้างผู้ใช้ replication เฉพาะสำหรับ master server และให้สิทธิ์ที่จำเป็น
    CREATE USER 'repl'@'%' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
FLUSH PRIVILEGES;
  • ผู้ใช้นี้จำเป็นสำหรับ slave server เพื่อเข้าถึงข้อมูลจาก master
  1. ตรวจสอบสถานะ Master
  • ตรวจสอบไฟล์ binary log ปัจจุบันและตำแหน่ง (log location) ข้อมูลนี้จำเป็นเมื่อกำหนดค่า slave server
    SHOW MASTER STATUS;
  • File (ชื่อไฟล์ log) และ Position ที่แสดงโดยคำสั่งนี้จะถูกใช้ในการกำหนดค่า slave

การกำหนดค่าเซิร์ฟเวอร์ Slave

ต่อไปให้แก้ไขไฟล์การกำหนดค่าของเซิร์ฟเวอร์ slave และกำหนดค่า server ID รวมถึงข้อมูลของ master

  1. แก้ไขไฟล์การกำหนดค่า
  • ตั้งค่า server-id ที่ไม่ซ้ำกันบน slave server ด้วย (เช่น 2) ค่านี้ต้องแตกต่างจาก server ID ของ master
    [mysqld]
server-id=2
  • มักจะตั้งค่า read_only=ON เพื่อป้องกันการเขียนข้อมูลบน slave server ด้วย
  1. กำหนดข้อมูล Master บน Slave
  • รันคำสั่งต่อไปนี้บน slave server โดยระบุ hostname ของ master, ผู้ใช้, ชื่อไฟล์ binary log และตำแหน่ง
    CHANGE MASTER TO
    MASTER_HOST='master_host',
    MASTER_USER='repl',
    MASTER_PASSWORD='password',
    MASTER_LOG_FILE='mysql-bin.000001',
    MASTER_LOG_POS=123;
  • ใส่ค่าที่ได้ยืนยันจาก master ก่อนหน้านี้สำหรับ MASTER_LOG_FILE และ MASTER_LOG_POS
  1. เริ่มต้น Replication
  • รันคำสั่งต่อไปนี้บน slave server เพื่อเริ่ม replication
    START SLAVE;

การตรวจสอบสถานะ Replication

ตรวจสอบว่า replication ระหว่าง master และ slave ถูกกำหนดค่าอย่างถูกต้อง

  • Check Master Status
    SHOW MASTER STATUS;
  • Check Slave Status
    SHOW SLAVE STATUS\G;
  • หาก Slave_IO_Running และ Slave_SQL_Running ทั้งสองแสดงค่า Yes replication จะทำงานอย่างปกติ

ส่วนต่อไปจะอธิบายการกำหนดค่า replication ขั้นสูง รวมถึงความแตกต่างระหว่าง asynchronous และ semi‑synchronous replication และการตั้งค่าโดยใช้ GTID

4. ประเภทของ Replication และการใช้งานขั้นสูง

MySQL replication มีสองประเภทหลักตามวิธีการซิงโครไนซ์ข้อมูล: asynchronous replication และ semi‑synchronous replication การเข้าใจลักษณะของแต่ละประเภทและเลือกใช้ตามกรณีการใช้งานของคุณจะช่วยปรับปรุงประสิทธิภาพระบบและความน่าเชื่อถือ ส่วนนี้ยังอธิบายประโยชน์ของการใช้ GTID (Global Transaction Identifier) สำหรับการกำหนดค่า replication

ความแตกต่างระหว่าง Asynchronous และ Semi‑Synchronous Replication

1. Asynchronous Replication

ใน asynchronous replication เซิร์ฟเวอร์ master จะส่งการตอบกลับให้กับไคลเอนต์ทันทีหลังจากทำธุรกรรมเสร็จสิ้น กล่าวคือ master สามารถดำเนินการคำขอใหม่ต่อไปได้แม้การซิงโครไนซ์กับ slave จะล่าช้า วิธีนี้ให้ประสิทธิภาพการตอบสนองที่ดีเยี่ยมและเหมาะกับระบบที่เน้นการกระจายโหลด อย่างไรก็ตาม หากเกิดความล้มเหลว มีความเสี่ยงว่าข้อมูลที่ยังไม่ได้ถูกนำไปใช้บน slave จะสูญหาย

2. Semi‑Synchronous Replication

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

การทำซ้ำโดยใช้ GTID

GTID (Global Transaction Identifier) มอบหมาย ID ที่ไม่ซ้ำกันให้กับธุรกรรมแต่ละรายการและรักษาความสอดคล้องของธุรกรรมระหว่างเซิร์ฟเวอร์หลักและทาส การเปิดใช้งาน GTID ทำให้การจัดการการทำซ้ำง่ายขึ้นเมื่อเทียบกับการทำซ้ำแบบดั้งเดิมที่ใช้ตำแหน่ง binary log。

ข้อดีของ GTID

  • ความสอดคล้องของข้อมูลที่ปรับปรุงแล้ว : ด้วย GTID เซิร์ฟเวอร์ทาสสามารถระบุธุรกรรมที่ยังไม่ได้นำไปใช้โดยอัตโนมัติ ทำให้ง่ายต่อการรักษาความสอดคล้อง
  • การจัดการการทำซ้ำที่ง่ายขึ้น : GTID ช่วยปรับปรุงประสิทธิภาพสำหรับ failover การสลับเซิร์ฟเวอร์หลัก/ทาส และงานกู้คืน เนื่องจากไม่จำเป็นต้องระบุตำแหน่ง binary log อีกต่อไป การดำเนินการจึงง่ายขึ้น

การกำหนดค่าการทำซ้ำ GTID

เพื่อใช้ GTID คุณต้องเพิ่มและเปิดใช้งานตัวเลือกต่อไปนี้ในไฟล์กำหนดค่าของทั้งเซิร์ฟเวอร์หลักและทาส。

การกำหนดค่าเซิร์ฟเวอร์หลัก

[mysqld]
server-id=1
log-bin=mysql-bin
gtid_mode=ON
enforce_gtid_consistency=ON

การกำหนดค่าเซิร์ฟเวอร์ทาส

[mysqld]
server-id=2
gtid_mode=ON
enforce_gtid_consistency=ON
read_only=ON

ในสภาพแวดล้อมที่เปิดใช้งาน GTID การทำซ้ำจะดำเนินการโดยอัตโนมัติผ่าน GTID โดยเพียงแค่ตั้งค่าข้อมูลเซิร์ฟเวอร์หลักบนเซิร์ฟเวอร์ทาสโดยใช้คำสั่ง CHANGE MASTER TO。

ส่วนถัดไปอธิบายวิธีการบำรุงรักษาสำหรับการทำซ้ำ MySQL และจุดตรวจสอบที่สำคัญสำหรับการจัดการการดำเนินงาน。

5. การบำรุงรักษาและการตรวจสอบการทำซ้ำ

เพื่อดำเนินการทำซ้ำ MySQL อย่างถูกต้อง การบำรุงรักษาและการตรวจสอบเป็นประจำจึงจำเป็น ส่วนนี้จะอธิบายคำสั่งสำหรับตรวจสอบว่าระบบการทำซ้ำทำงานปกติหรือไม่ และวิธีจัดการกับข้อผิดพลาดทั่วไป。

วิธีตรวจสอบสถานะการทำซ้ำ

ใช้คำสั่งต่อไปนี้เพื่อตรวจสอบสถานะการซิงโครไนซ์ระหว่างเซิร์ฟเวอร์หลักและทาส。

การตรวจสอบสถานะเซิร์ฟเวอร์หลัก

คุณสามารถตรวจสอบสถานะการทำซ้ำของเซิร์ฟเวอร์หลักโดยใช้คำสั่ง SHOW MASTER STATUS คำสั่งนี้จะแสดงชื่อไฟล์ binary log ปัจจุบันและตำแหน่ง ทำให้คุณสามารถยืนยันการอัปเดตล่าสุดที่ควรส่งไปยังเซิร์ฟเวอร์ทาส。

SHOW MASTER STATUS;

ผลลัพธ์โดยทั่วไปจะรวมฟิลด์ต่อไปนี้:

  • File : ชื่อไฟล์ binary log ปัจจุบันที่สร้างโดยเซิร์ฟเวอร์หลัก
  • Position : ตำแหน่งปัจจุบันภายใน binary log
  • Binlog_Do_DB และ Binlog_Ignore_DB : ฐานข้อมูลที่รวม/ยกเว้นจากการทำซ้ำ

การตรวจสอบสถานะเซิร์ฟเวอร์ทาส

คุณสามารถตรวจสอบสถานะการทำซ้ำของเซิร์ฟเวอร์ทาสโดยใช้คำสั่ง SHOW SLAVE STATUS ผลลัพธ์จะรวมข้อมูลที่จำเป็นสำหรับการพิจารณาว่าเซิร์ฟเวอร์ทาสทำงานถูกต้องหรือไม่。

SHOW SLAVE STATUS\G;

ฟิลด์สำคัญรวมถึง:

  • Slave_IO_Running และ Slave_SQL_Running : หากทั้งคู่เป็น Yes เซิร์ฟเวอร์ทาสกำลังทำงานปกติ
  • Seconds_Behind_Master : บ่งชี้ว่าเซิร์ฟเวอร์ทาสตามหลังเซิร์ฟเวอร์หลักกี่วินาที โดย理想ควรเป็น 0

การแก้ไขปัญหาการทำซ้ำ

ปัญหาทั่วไประหว่างการดำเนินการทำซ้ำรวมถึงข้อผิดพลาดการเชื่อมต่อและความไม่สอดคล้องของข้อมูล ด้านล่างคือกรณีข้อผิดพลาดทั่วไปและวิธีแก้ไข。

1. ข้อผิดพลาดการเชื่อมต่อ

หาก Slave_IO_Running เป็น No หมายความว่าเซิร์ฟเวอร์ทาสไม่สามารถเชื่อมต่อกับเซิร์ฟเวอร์หลัก ลองทำตามนี้:

  • ตรวจสอบชื่อโฮสต์หรือที่อยู่ IP ของเซิร์ฟเวอร์หลัก : ตรวจสอบให้แน่ใจว่าที่อยู่เซิร์ฟเวอร์หลักถูกต้อง
  • ตรวจสอบการตั้งค่าไฟร์วอลล์ : ยืนยันว่าพอร์ตที่จำเป็น (โดยปกติคือ 3306) เปิดอยู่

2. ความไม่สอดคล้องของข้อมูล

If Last_Error contains an error message, a data inconsistency may have occurred between the master and slave. In such cases, stop the slave and apply corrections before restarting replication.

STOP SLAVE;
# Restart after applying fixes
START SLAVE;

3. ลดการหน่วงของ Replication

การหน่วงของ replication อาจเกิดจากข้อจำกัดของฮาร์ดแวร์ slave หรือปัญหาเครือข่าย หากจำเป็น การอัปเกรดการกำหนดค่าเซิร์ฟเวอร์ slave สามารถปรับปรุงประสิทธิภาพได้

ส่วนต่อไปนี้จะสำรวจปัญหา replication อย่างละเอียดและให้วิธีแก้เพิ่มเติม

6. ปัญหาทั่วไปและวิธีแก้ของมัน

ระหว่างการทำงานของ MySQL replication ปัญหาต่าง ๆ อาจเกิดขึ้น ส่วนนี้อธิบายปัญหาที่พบบ่อยและวิธีแก้ การตรวจจับปัญหาแต่เนิ่น ๆ และใช้การแก้ไขที่ถูกต้องช่วยรักษาการทำงานของระบบให้เสถียร

1. เมื่อ Slave_IO_Running ถูกหยุด

Symptom: หาก Slave_IO_Running แสดง No ในผลลัพธ์ของ SHOW SLAVE STATUS slave จะไม่สามารถเชื่อมต่อกับ master ได้

Causes and Solutions:

  • Network Issues : หากมีปัญหาการเชื่อมต่อเครือข่าย slave จะไม่สามารถเข้าถึง master ได้ ตรวจสอบการตั้งค่าไฟร์วอลและยืนยันว่า master สามารถเข้าถึงได้
  • Incorrect Master Hostname or IP Address : ตรวจสอบให้แน่ใจว่า hostname หรือ IP address ที่ระบุใน CHANGE MASTER TO ถูกต้อง
  • User Privilege Issues : หากผู้ใช้ replication บน master ไม่มีสิทธิ์เพียงพอ การเชื่อมต่อจะล้มเหลว ยืนยันว่ามีการมอบสิทธิ์ที่ถูกต้องโดยใช้ GRANT REPLICATION SLAVE

2. ความไม่สอดคล้องของข้อมูลบน Slave

Symptom: หากข้อมูลระหว่าง master และ slave ไม่ตรงกัน slave อาจเข้าสู่สถานะที่ไม่สอดคล้อง

Causes and Solutions:

  • Manual Data Correction : หยุด slave, แก้ไขธุรกรรมที่มีปัญหาโดยมือ, แล้วเริ่ม replication ใหม่ STOP SLAVE; # Fix data if necessary START SLAVE;
  • Resynchronization : หากความไม่สอดคล้องมีขนาดใหญ่ ให้ทำการสำรองข้อมูลเต็มจาก master แล้วซิงโครไนซ์ slave ใหม่

3. การหน่วงของ Replication

Symptom: หาก Seconds_Behind_Master ไม่เป็น 0 ในผลลัพธ์ของ SHOW SLAVE STATUS slave จะล่าช้ากว่า master ค่าที่ต้องการคือให้ใกล้ 0 มากที่สุด

Causes and Solutions:

  • Slave Hardware Limitations : หากเซิร์ฟเวอร์ slave มีทรัพยากรไม่เพียงพอ อาจไม่ทันตาม การอัปเกรดฮาร์ดแวร์จะช่วยได้
  • Query Optimization : หากคิวรีที่รับจาก master ใช้เวลานานในการดำเนินการบน slave การหน่วงของ replication จะเกิดขึ้น การเพิ่มดัชนีและปรับแต่งคิวรีจะลดเวลาการประมวลผล

4. ข้อผิดพลาดสิทธิ์ของผู้ใช้ Replication

Symptom: หาก Last_Error แสดงข้อความที่เกี่ยวกับสิทธิ์ slave อาจไม่มีสิทธิ์เพียงพอในการเชื่อมต่อกับ master

Causes and Solutions:

  • Reconfigure User Privileges : ตรวจสอบให้แน่ใจว่ามีผู้ใช้ที่มีสิทธิ์เหมาะสมบน master หากจำเป็นให้กำหนดใหม่ GRANT REPLICATION SLAVE ON *.* TO 'repl'@'slave_ip_address'; FLUSH PRIVILEGES;

5. การเติบโตของ Binary Log

Symptom: Binary log ของ master อาจเติบโตเกินไป ทำให้ใช้พื้นที่ดิสก์มาก

Causes and Solutions:

  • Binary Log Rotation : ลบหรือเก็บถาวร binary log อย่างสม่ำเสมอเพื่อป้องกันการเติบโตเกินไป โดยกำหนดค่า expire_logs_days สามารถลบ log ที่เก่ากว่าช่วงเวลาที่กำหนดโดยอัตโนมัติ SET GLOBAL expire_logs_days = 7; # Delete logs older than 7 days

โดยการทำความเข้าใจปัญหา MySQL replication ที่พบบ่อยและวิธีแก้เหล่านี้ คุณจะสามารถจัดการการดำเนินงานได้ราบรื่นยิ่งขึ้น ส่วนต่อไปนี้สรุปประเด็นสำคัญสำหรับการจัดการ replication

7. สรุป

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

Key Takeaways

  1. Choosing the Right Replication Type
  • การทำซ้ำแบบอะซิงโครนัสให้เวลาตอบสนองที่เร็วขึ้นและเหมาะสำหรับการกระจายโหลด อย่างไรก็ตาม หากความน่าเชื่อถือเป็นสิ่งสำคัญ การทำซ้ำแบบกึ่งซิงโครนัสจะเหมาะสมกว่า เลือกตามความต้องการของระบบของคุณ
  1. Effective Use of GTID
  • GTID ช่วยขจัดความจำเป็นในการระบุตำแหน่งของบันทึกไบนารีและทำให้การจัดการธุรกรรมเป็นไปอย่างราบรื่น มันมีประโยชน์อย่างยิ่งในสภาพแวดล้อมที่มีสลาฟหลายตัวหรือที่การฟอล์โอเวอร์เป็นสิ่งสำคัญ
  1. Regular Status Monitoring
  • ใช้ SHOW MASTER STATUS และ SHOW SLAVE STATUS เพื่อตรวจสอบสถานะการทำงานของเซิร์ฟเวอร์มาสเตอร์และสลาฟอย่างสม่ำเสมอ การดำเนินการอย่างรวดเร็วเมื่อพบความผิดปกติจะช่วยลดความเสี่ยงเช่น ความไม่สอดคล้องของข้อมูลหรือความล่าช้า
  1. Mastering Basic Troubleshooting
  • ปัญหาการทำซ้ำที่พบบ่อยรวมถึงข้อผิดพลาดการเชื่อมต่อสลาฟ ความไม่สอดคล้องของข้อมูล และความล่าช้า การเข้าใจวิธีแก้ปัญหาเบื้องต้นสำหรับแต่ละปัญหาจะทำให้การดำเนินงานราบรื่นยิ่งขึ้น
  1. Binary Log Management
  • เนื่องจากบันทึกไบนารีอาจใช้พื้นที่ดิสก์อย่างมาก จึงแนะนำให้กำหนดค่า expire_logs_days เพื่อทำความสะอาดอัตโนมัติและดำเนินการบำรุงรักษาอย่างสม่ำเสมอ

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

เราหวังว่าคู่มือนี้จะช่วยให้คุณเข้าใจและนำ MySQL replication ไปใช้ได้ดีขึ้น ขอให้การทำซ้ำของคุณราบรื่นและเสถียรภาพ.