Net's Digital Garden 🌱

Database Replication

อ่านราว 3 นาที

Database Replication

การทำสำเนาข้อมูลไปยัง DB instances หลายตัวเพื่อ read scaling, high availability, และ disaster recovery

1. Master/Backup (Single Leader) Replication

  • 1 master รับ write (INSERT/UPDATE/DELETE) + DDL
  • 1+ standby/follower รับ stream changes จาก master — อ่านได้ เขียนไม่ได้
  • ง่าย เพราะไม่มี conflict (มีแค่คนเดียวเขียน)
  • Read scaling — กระจาย SELECT ไป replicas → master รับแต่ write

2. Multi-Master Replication

  • หลาย master ที่รับ write ได้
  • เพิ่ม write throughput + availability
  • แต่ต้อง resolve conflict เมื่อ 2 master เขียน row เดียวกัน:
    • Last-write-wins (LWW) — เก็บค่า timestamp ใหม่กว่า (เสี่ยง clock drift)
    • Application-level resolution — DB ส่ง conflict ให้ app ตัดสิน
    • CRDTs — data structure ที่ merge ได้เสมอ

3. Synchronous vs Asynchronous

Synchronous Replication

  • Master รอ จนกว่า replica ยืนยันว่าเขียนสำเร็จ → ค่อยตอบ client
  • ข้อดี: ข้อมูลจะไม่หายเลยถ้า master ตาย
  • ข้อเสีย: writes ช้าลง — ต้องรอ network round-trip

Asynchronous Replication

  • Master ตอบ client ทันที → push changes ไป replica แบบ async
  • ข้อดี: writes เร็ว
  • ข้อเสีย: master ตายก่อน replicate → ข้อมูลหาย + eventual consistency

Postgres synchronous_commit Levels

  • off — async, เร็วสุด, อาจหาย
  • local — commit ลง disk ของ master, ไม่รอ replica
  • remote_write — รอ replica เขียน WAL
  • on — รอ replica fsync (ปลอดภัยสุด, ช้าสุด)

4. Eventual Consistency

หลังเขียนที่ master → ใช้เวลา ms-วินาที propagate ไป replica → ระหว่างนั้นอ่านจาก replica อาจได้ค่าเก่า

กรณี Tolerable (รับได้): Twitter timeline — ทวีตใหม่ช้าไม่กี่วินาที ไม่ใช่ปัญหา

กรณี Intolerable (รับไม่ได้): การโอนเงิน — เงินเข้าแล้วต้องเห็นทันที

Read-Your-Own-Writes Pattern

เขียนเสร็จ → session นั้นอ่านจาก master จนกว่า replica จะ catch up → user เห็นค่าใหม่ของตัวเองทันที

Read-After-Write Patterns อื่น ๆ

  1. Read from primary หลัง write ในช่วงสั้น ๆ
  2. Sticky session → ส่ง user ไป replica เดียวกันที่ caught up
  3. Token-based → primary ส่ง LSN/version → replica รอจนถึง version นั้น
  4. Causal consistency (DynamoDB, Cassandra)

Pros & Cons

Pros:

  • Read scaling — replicas รับ SELECT
  • Region-based queries — DB ใน region ของ user → latency ต่ำ
  • High availability — replica ตาย ก็มีตัวอื่น (failover)
  • Backup natural — replica = live backup

Cons:

  • Eventual Consistency (async)
  • Slow writes (sync)
  • Multi-master ซับซ้อน — conflict resolution
  • กิน storage หลายเท่า — data ซ้ำในทุก replica

Demo: Postgres 13 Replication

# master config
# postgresql.conf: wal_level = replica, max_wal_senders = 3
# pg_hba.conf: host replication replicator <standby-ip>/32 trust
 
# standby setup
pg_basebackup -h <master-ip> -D /var/lib/postgresql/data -U replicator -P -R
# -R สร้าง standby.signal + primary_conninfo อัตโนมัติ

Key Points

  • Master/Backup = ง่ายสุด ไม่มี conflict — ใช้กันแพร่หลาย
  • Multi-Master = write throughput สูง แต่ต้อง resolve conflict
  • Sync = ปลอดภัย ช้า / Async = เร็ว เสี่ยงหาย
  • Eventual Consistency — รับได้สำหรับบาง use case (social), รับไม่ได้สำหรับ banking
  • Read-your-own-writes = pattern สำคัญแก้ eventual consistency ให้ user เห็นค่าตัวเอง
  • Database Sharding — sharding คือขั้นถัดไปเมื่อ replicas ไม่พอ
  • CAP Theorem — async replication = AP, sync = CP
  • WAL — mechanism ที่ใช้ stream changes จาก master ไป replica
  • PostgreSQL — synchronous_commit levels, pg_basebackup
  • Concurrency Control — consistency ข้าม replicas

มุมมองกราฟ

หน้าที่กล่าวถึง