replica set ทำงานอย่างไรใน MongoDB?

Question

Accepted Answer

**replica set** คือกลุ่มของเซิร์ฟเวอร์ MongoDB ที่เก็บข้อมูลชุดเดียวกัน — ให้ **high availability** (failover อัตโนมัติ) และ **ความซ้ำซ้อน (redundancy)** โหนดหนึ่งเป็น **primary** (จัดการการ write) ที่เหลือเป็น **secondary** (replicate ข้อมูลของ primary และสามารถให้บริการ read ได้) เป็นกลไกมาตรฐานของ MongoDB สำหรับความน่าเชื่อถือ

## โครงสร้างของ replica set

```text
PRIMARY (1)   → receives all WRITES; replicates changes to secondaries
SECONDARIES (2+) → copy the primary's data (via the oplog); can serve READS
ARBITER (optional) → votes in elections but holds no data (for odd vote counts)

Write → Primary → replicated to Secondaries (via the operations log "oplog")
```

primary จัดการการ write และ replicate มัน (ผ่าน **oplog** ซึ่งเป็น log ของ operation) ไปยัง secondary ที่ซิงค์ข้อมูลให้ตรงกัน replica set ทั่วไปมีสมาชิก 3 ตัวเพื่อความทนทาน

## failover อัตโนมัติ (high availability)

```text
If the PRIMARY fails:
  → the secondaries detect it and hold an ELECTION
  → a secondary is automatically elected as the NEW PRIMARY
  → the application (via the driver) reconnects to the new primary
  → minimal downtime, no manual intervention
→ This automatic failover is the key high-availability benefit.
```

**failover อัตโนมัติ** เป็นคุณค่าหลัก: หาก primary ล้มเหลว replica set จะเลือก primary ใหม่โดยอัตโนมัติ — เปลี่ยนความล้มเหลวของเซิร์ฟเวอร์ให้เป็นการหยุดชะงักเพียงชั่วครู่แทนที่จะเป็นการล่ม (จำนวนสมาชิกที่ออกเสียงเป็นเลขคี่ช่วยหลีกเลี่ยงการเลือกตั้งที่เสมอกัน)

## การ scale การอ่านและ read preference

```js
// reads can be directed to secondaries to offload the primary
db.collection.find().readPref("secondaryPreferred");
// read preferences: primary (default), secondary, nearest, etc.
```

secondary สามารถให้บริการ read ได้ (scale ความสามารถในการอ่าน) ควบคุมด้วย **read preference** — แม้ว่าการอ่านจาก secondary อาจล้าหลังเล็กน้อย (replication แบบ asynchronous)

## write concern (ความทนทาน)

```js
// write concern: how many nodes must acknowledge a write before it's confirmed
db.collection.insertOne(doc, { writeConcern: { w: "majority" } });
// w: 1 (primary only — fast, less safe) vs w: "majority" (safer — survives failover)
```

**write concern** ควบคุมความทนทาน: `w: "majority"` รอให้โหนดส่วนใหญ่ตอบรับ (ปลอดภัยกว่า — รอดจากความล้มเหลวของ primary โดยไม่สูญเสียข้อมูล) เทียบกับ `w: 1` (เร็วกว่าแต่การ write อาจสูญหายตอน failover)

## ทำไมจึงสำคัญ

replica set เป็นพื้นฐานในการรัน MongoDB อย่างน่าเชื่อถือในระบบ production ดังนั้นการเข้าใจมันจึงเป็นความรู้ระดับ senior ที่สำคัญสำหรับการ deploy MongoDB ใน production

คุณค่าหลักคือ **high availability ผ่าน failover อัตโนมัติ**: replica set (กลุ่มเซิร์ฟเวอร์ที่เก็บข้อมูลชุดเดียวกัน โดย primary จัดการการ write และ secondary replicate) จะเลือก primary ใหม่โดยอัตโนมัติหาก primary ปัจจุบันล้มเหลว — เปลี่ยนความล้มเหลวของเซิร์ฟเวอร์ให้เป็นการหยุดชะงักชั่วครู่แทนที่จะล่มทั้งหมด ซึ่งจำเป็นต่อระบบที่ต้องพร้อมใช้งานอยู่เสมอ (และจำเป็นต่อ transaction และฟีเจอร์ production อีกหลายอย่าง)

การเข้าใจโครงสร้าง (primary, secondary, arbiter เสริม, oplog สำหรับ replication) และกลไก **การเลือกตั้ง/failover** เป็นพื้นฐาน

การรู้ว่า secondary สามารถให้บริการ **การอ่าน** ได้ (scale ความสามารถในการอ่านผ่าน **read preference** โดยมีข้อควรระวังว่าอาจล้าหลังเล็กน้อยจาก replication แบบ asynchronous) มีคุณค่าต่อประสิทธิภาพ

ที่สำคัญเป็นพิเศษคือการเข้าใจ **write concern** — การควบคุมความทนทานที่ `w: "majority"` รับประกันว่าการ write ถูกตอบรับโดยโหนดส่วนใหญ่ (จึงรอดจาก failover ของ primary โดยไม่สูญเสียข้อมูล — สำคัญสำหรับข้อมูลที่สำคัญยิ่ง) เทียบกับ `w: 1` (เร็วกว่าแต่เสี่ยงกว่าตอน failover) — เป็นข้อแลกเปลี่ยนระหว่างความน่าเชื่อถือกับประสิทธิภาพที่สำคัญ

เนื่องจาก high availability และความทนทานจำเป็นต่อฐานข้อมูล production และเนื่องจาก replica set (พร้อม failover อัตโนมัติ, การ scale การอ่านผ่าน secondary และ write concern สำหรับความทนทาน) เป็นกลไกพื้นฐานของ MongoDB สำหรับสิ่งเหล่านี้ การเข้าใจ replica set — โครงสร้าง, failover อัตโนมัติ, read preference และโดยเฉพาะ write concern — จึงเป็นความรู้ระดับ senior ที่สำคัญสำหรับการ deploy MongoDB อย่างน่าเชื่อถือใน production เป็นความกังวลที่มักวิกฤตและเป็นหัวข้อที่แสดงถึงความเข้าใจในโมเดล high-availability และความทนทานของ MongoDB ที่คาดหวังสำหรับตำแหน่ง senior ที่ทำงานกับฐานข้อมูลนี้