Master-Slave Replication

---

⚙️ I. MÔ HÌNH MASTER-SLAVE CHUẨN DOANH NGHIỆP

⚒️ Kiến trúc tổng quan:

                ┌────────────┐
                │  Client    │
                └────┬───────┘
                     │
             ┌───────▼────────┐
             │ Load Balancer  │
             └───────┬────────┘
             ┌───────▼──────┬───────────────────┐
             │   Master DB  │                   │
             └───────┬──────┘                   │
                     │                          │
      ┌──────────────▼──────────────┐           │
      │         Slave DB 1          │           │
      └─────────────────────────────┘           │
      │         Slave DB 2          │           │
      └─────────────────────────────┘           │
      │        Read-only replicas   │           │
      └─────────────────────────────┘           │
                                               ...

---

✅ II. LỢI ÍCH

Khía cạnh	Lợi ích
Scalability	Offload đọc về các slave → scale theo chiều ngang.
Fault Tolerance	Master down → có thể failover sang slave.
Backup	Backup trên slave để tránh ảnh hưởng master.
Geo-distribution	Đặt các slave ở nhiều region để giảm latency.

---

⚠️ III. VẤN ĐỀ THƯỜNG GẶP & GIẢI PHÁP

---

1. 🔄 Replication Lag (Độ trễ đồng bộ)

❌ Vấn đề:

• Slave nhận dữ liệu chậm hơn master → dẫn đến truy vấn thấy dữ liệu cũ (eventual consistency).

• Gây lỗi khi hệ thống yêu cầu dữ liệu mới inserted nhưng chưa tới slave.

✅ Giải pháp:

• Monitor replication lag thường xuyên (Prometheus + Grafana).

• Use semi-sync replication (MySQL, PostgreSQL): bắt buộc 1 slave xác nhận trước khi commit.

• Phân luồng đọc hợp lý: các truy vấn quan trọng → master, không quan trọng → slave.

---

2. 🧨 Single Point of Failure (SPOF) - Master Down

❌ Vấn đề:

• Nếu master chết → toàn bộ ghi dừng → downtime!

✅ Giải pháp:

• Automatic Failover:

  • Dùng hệ thống như: MHA (MySQL High Availability), Orchestrator, Patroni (PostgreSQL).

• Leader Election:

  • Thường tích hợp Zookeeper / etcd / Consul để chọn master mới.

---

3. 🔁 Split Brain

❌ Vấn đề:

• Có 2 nodes đều nghĩ mình là master → ghi dữ liệu khác nhau → mất đồng nhất → cực kỳ nguy hiểm!

✅ Giải pháp:

• Luôn dùng cơ chế quorum trong leader election.

• Heartbeat detection + fencing để đảm bảo chỉ 1 node có quyền ghi.

---

4. 💥 Write Scalability Limit

❌ Vấn đề:

• Master là bottleneck ghi → không scale được ghi theo chiều ngang.

✅ Giải pháp:

• Sharding kết hợp replication: Mỗi shard có 1 master + nhiều slave.

• Command Queue: tách ghi ra khỏi luồng chính (event sourcing, CQRS).

---

5. 🔍 Inconsistency sau failover

❌ Vấn đề:

• Nếu failover chưa kịp, slave chưa sync đầy đủ, client ghi trùng hoặc sai.

✅ Giải pháp:

• GTID (Global Transaction ID) trong MySQL / binlog position tracking để đảm bảo dữ liệu không mất.

• Sau failover, repoint lại các slave về master mới và đồng bộ lại dữ liệu thiếu.

---

🧠 IV. KINH NGHIỆM TRIỂN KHAI DOANH NGHIỆP

• Infrastructure-as-code: triển khai DB cluster bằng Terraform, Ansible.

• Monitoring chặt chẽ: không chỉ DB, mà cả network và replication.

• Read/Write Splitting Middleware: ProxySQL, Pgpool-II để tự động route truy vấn đúng nơi.

• Load Testing + Chaos Testing: dùng tools như ChaosMonkey để test HA.

---

📌 Tổng Kết

Yếu tố	Master-Slave Replication (Enterprise)
Ghi	Chỉ tại 1 master
Đọc	Phân tải qua các slave
Tính nhất quán	Eventual (tùy config)
HA (High Availability)	Có nếu cấu hình failover tốt
Dễ mở rộng	Đọc dễ, ghi cần thêm sharding

---