Replication ส่งกระแสการเปลี่ยนแปลงจาก source (master) ไปยัง replica หนึ่งตัวหรือมากกว่า source จะบันทึกทุกการเปลี่ยนแปลงที่ commit แล้วลงใน binary log (binlog); I/O thread ของแต่ละ replica จะคัดลอก log นั้นและ thread ที่เป็น SQL/applier จะเล่นซ้ำ ทำให้ replica ปรับให้มีข้อมูลตรงกัน
writes
app ---------> --- binlog ---> <-- reads
| <-- reads
+---------- binlog ---> <-- reads
ROW (บันทึกภาพของแถวจริง เป็นค่าเริ่มต้นที่ปลอดภัย), STATEMENT หรือ MIXEDชี้การเขียนไปที่ source และกระจาย SELECT ไปยัง replica ต่าง ๆ แอปที่อ่านหนัก (เว็บแอปส่วนใหญ่) ขยาย read ได้เกือบเป็นเชิงเส้นด้วยการเพิ่ม replica ขณะที่ source ตัวเดียวยังคงจัดการการเขียนทั้งหมด
-- On a replica, watch how far behind it is:
SHOW REPLICA STATUS\G
-- Seconds_Behind_Source: 2 <- replication lag
-- Replica_IO_Running: Yes
-- Replica_SQL_Running: Yes
เพราะ async replica ตามหลัง source ผู้ใช้ที่เขียนแล้วอ่านจาก replica ทันทีอาจไม่เห็นการเปลี่ยนแปลงของตัวเอง (ละเมิด "read-your-writes") ให้ route การอ่านที่ไวต่อ latency หรือที่เพิ่งเขียนไปที่ source หรือใช้ semi-sync
Replication เป็นขั้นตอนแรกมาตรฐานในการขยาย read และเพื่อให้ได้ warm standby สำหรับ failover/backup ข้อจำกัดที่เป็นเอกลักษณ์ของมัน — lag และคอขวดการเขียนตัวเดียว — เป็นตัวกำหนดการออกแบบจริง: มันอธิบายว่าทำไมบางครั้งคุณจึงอ่านข้อมูลเก่า และทำไมการขยายการเขียนในที่สุดจึงต้องใช้ sharding ไม่ใช่แค่เพิ่ม replica
คลังคำถามสัมภาษณ์งาน IT พร้อมคำตอบโดยละเอียด — ตั้งแต่ระดับ Junior ถึง Senior
บริจาค