replication ทำงานอย่างไรใน PostgreSQL?

Question

Accepted Answer

**Replication** คัดลอกข้อมูลจากฐานข้อมูล **primary** ไปยังเซิร์ฟเวอร์ **replica** (standby) หนึ่งตัวขึ้นไป เพื่อ high availability (failover หาก primary ล้มเหลว) และ read scaling (กระจาย query สำหรับอ่าน) PostgreSQL ใช้ **streaming replication** (physical) เป็นหลัก ซึ่งอิงกับ write-ahead log (WAL)

## streaming (physical) replication

```text
Primary  ──(streams WAL: the write-ahead log of changes)──▶  Replica(s)
  ✓ The primary handles all WRITES
  ✓ Replicas continuously apply the primary's WAL → stay in sync (near-real-time)
  ✓ Replicas can serve READ queries ("hot standby") → scale reads
```

primary stream **WAL** (write-ahead log บันทึกของทุกการเปลี่ยนแปลง) ไปยัง replica ซึ่ง apply มันเพื่อให้ sync กัน replica เป็นสำเนาแบบ read-only ที่สามารถให้บริการ query สำหรับอ่านได้

## ประโยชน์: HA และ read scaling

```text
HIGH AVAILABILITY → if the primary fails, a replica can be PROMOTED to primary (failover)
  → minimal downtime, no data loss (with synchronous replication)
READ SCALING → route read-only queries to replicas → offload the primary
  → handle more read traffic (great for read-heavy workloads)
BACKUPS → take backups from a replica without loading the primary
```

## synchronous กับ asynchronous replication

```text
ASYNCHRONOUS (default) → the primary commits without waiting for replicas
  ✓ faster writes (no wait)   ✗ a tiny window of potential data loss on failover
SYNCHRONOUS → the primary waits for a replica to confirm before committing
  ✓ no data loss on failover  ✗ slower writes (waits for the replica)
→ Choose based on the durability vs performance trade-off.
```

## logical replication (โมเดลที่แตกต่าง)

```text
LOGICAL replication → replicates specific TABLES/changes (not the whole cluster), based
on a publish/subscribe model. Enables: selective replication, cross-version, and
replicating to different schemas → good for migrations, integrations, partial replication.
```

## high availability ในทางปฏิบัติ

```text
Tools like Patroni, repmgr, or cloud-managed Postgres automate FAILOVER (detecting
primary failure and promoting a replica) → near-automatic high availability.
A load balancer / connection router directs writes to the primary, reads to replicas.
```

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

replication สำคัญต่อการสร้าง deployment ของ PostgreSQL ที่ **มี high availability และขยายได้** ดังนั้นการเข้าใจมันจึงเป็นความรู้ระดับ senior ที่มีคุณค่าสำหรับสถาปัตยกรรมฐานข้อมูล production

ประโยชน์หลักสองประการมีความสำคัญยิ่งต่อแอปพลิเคชันที่จริงจัง: **high availability** (หากฐานข้อมูล primary ล้มเหลว replica สามารถถูก promote ขึ้นมาทำหน้าที่แทน ลด downtime ซึ่งจำเป็นสำหรับระบบที่ต้องพร้อมใช้งานตลอดเวลา) และ **read scaling** (การ route query สำหรับอ่านไปยัง replica ช่วยลดภาระ primary ทำให้ระบบรองรับ traffic อ่านได้มากขึ้น มีคุณค่าสำหรับ workload ที่อ่านหนัก)

การเข้าใจ **streaming replication** (primary stream WAL ไปยัง replica ที่ sync กันและให้บริการอ่านได้) เป็นรากฐาน

การรู้ข้อแลกเปลี่ยน **synchronous กับ asynchronous** เป็นสิ่งสำคัญ: asynchronous (ค่าเริ่มต้น write เร็วกว่าแต่มีช่องเล็ก ๆ ที่อาจสูญเสียข้อมูลตอน failover) เทียบกับ synchronous (ไม่สูญเสียข้อมูลแต่ write ช้ากว่า) เป็นการตัดสินใจระหว่าง durability กับ performance ที่ส่งผลต่อความน่าเชื่อถือ

การเข้าใจ **logical replication** (การ replicate ตารางเฉพาะผ่าน pub/sub มีประโยชน์สำหรับ migration, cross-version และ partial/selective replication) ขยายตัวเลือกออกไป

การรู้ว่า **เครื่องมือ HA** (Patroni, repmgr, managed cloud Postgres) ทำให้ failover เป็นอัตโนมัติ และการ route read/write นำ traffic ไปอย่างเหมาะสม เป็นความรู้เชิงสถาปัตยกรรมที่ใช้ได้จริง

เนื่องจาก high availability และ scalability เป็นข้อกำหนดที่จำเป็นสำหรับระบบฐานข้อมูล production และเนื่องจาก replication (พร้อม HA failover, read scaling, ข้อแลกเปลี่ยน sync/async ด้าน durability และ logical replication สำหรับความยืดหยุ่น) เป็นกลไกหลักที่ PostgreSQL มอบให้สำหรับสิ่งเหล่านี้ การเข้าใจ replication จึงเป็นความรู้ระดับ senior ที่สำคัญต่อการออกแบบ deployment ของ Postgres ที่น่าเชื่อถือและขยายได้ เป็นความกังวลที่เกี่ยวข้องบ่อยสำหรับระบบ production และเป็นหัวข้อที่แสดงถึงความเข้าใจในด้าน availability และ scaling ของฐานข้อมูลที่คาดหวังสำหรับตำแหน่ง database/backend ระดับ senior