คุณบรรลุ high availability ใน PostgreSQL อย่างไร?

Question

Accepted Answer

**high availability (HA)** หมายถึงการรักษาให้ฐานข้อมูลพร้อมใช้งานแม้เมื่อเกิดความล้มเหลว ผ่าน **replication** (standby replica), **automatic failover** (การ promote replica เมื่อ primary ล้มเหลว) และสถาปัตยกรรมที่เหมาะสม เป้าหมาย: ลด downtime และการสูญเสียข้อมูลให้น้อยที่สุด เนื่องจากการล่มของฐานข้อมูลทำให้ทั้งแอปพลิเคชันล่ม

## รากฐาน: replication + automatic failover

```text
Primary ──(streaming replication)──▶ Standby replica(s)

If the PRIMARY fails:
  → a STANDBY is automatically PROMOTED to become the new primary (FAILOVER)
  → the application reconnects to the new primary → minimal downtime
→ Without HA, a primary failure = total database outage = application down.
```

replication รักษาให้ standby replica sync กัน; **automatic failover** ตรวจจับความล้มเหลวของ primary และ promote replica เปลี่ยนการล่มทั้งหมดให้เป็นการหยุดชะงักสั้น ๆ

## เครื่องมือ HA (การทำ failover ให้อัตโนมัติ)

```text
Patroni → the popular HA solution: manages failover, uses a consensus store (etcd/
  Consul/ZooKeeper) to coordinate, prevents split-brain
repmgr → replication and failover management
Managed Postgres (AWS RDS/Aurora, Cloud SQL, etc.) → built-in HA with automatic failover
→ These automate detection + promotion, which is hard to do safely by hand.
```

การ failover ด้วยมือช้าและเกิดข้อผิดพลาดง่าย ดังนั้นเครื่องมือ HA (หรือ managed service) จึงทำให้มันอัตโนมัติอย่างปลอดภัย รวมถึงการป้องกัน **split-brain** (primary สองตัวที่รับ write ซึ่งทำให้ข้อมูลเสียหาย)

## connection routing

```text
Applications need to find the CURRENT primary after a failover:
  → a load balancer / proxy (HAProxy, PgBouncer) or service discovery routes
    WRITES to the current primary and READS to replicas
  → after failover, routing updates to point to the new primary
```

## ข้อพิจารณา HA สำคัญ

```text
✓ Synchronous replication → no data loss on failover (vs async's small loss window)
✓ Multiple replicas / multiple availability zones → survive zone failures
✓ Avoid SPLIT-BRAIN (two primaries) — consensus/fencing prevents it (critical for safety)
✓ Monitoring + health checks to detect failures quickly
✓ Test failover regularly (like backups, untested failover may not work)
→ Many teams use MANAGED Postgres for built-in, battle-tested HA.
```

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

high availability เป็นความรู้สำคัญต่อการดำเนินการระบบ PostgreSQL ที่ **วิกฤตต่อ production** เพราะการล่มของฐานข้อมูลทำให้ทั้งแอปพลิเคชันล่ม (ฐานข้อมูลมักเป็น dependency ที่วิกฤตที่สุดเพียงหนึ่งเดียว) ดังนั้นการเข้าใจวิธีรักษาให้ Postgres พร้อมใช้งานแม้เกิดความล้มเหลวจึงเป็นความรู้ระดับ senior ที่มีคุณค่าสำหรับระบบที่น่าเชื่อถือ

รากฐาน **replication บวกกับ automatic failover** เป็นสิ่งที่เปลี่ยนความล้มเหลวของฐานข้อมูล primary (ซึ่งมิเช่นนั้นจะเป็นการล่มของแอปพลิเคชันทั้งหมด) ให้เป็นการหยุดชะงักสั้น ๆ ที่ recover ได้: standby replica sync กันอยู่ และเมื่อ primary ล้มเหลว replica จะถูก promote ขึ้นมาทำหน้าที่แทนโดยอัตโนมัติ

การเข้าใจ **เครื่องมือ HA** (Patroni โซลูชันยอดนิยมที่ประสานงาน failover ผ่าน consensus store; repmgr; หรือ managed cloud Postgres ที่มี HA ในตัว) เป็นสิ่งสำคัญเพราะการทำ failover ให้อัตโนมัติอย่างปลอดภัยทำด้วยมือได้ยาก

การรู้ **ข้อพิจารณาสำคัญ** เป็นสิ่งวิกฤต: **synchronous replication** เพื่อไม่ให้สูญเสียข้อมูลตอน failover, **replica หลายตัวข้าม availability zone** เพื่อรอดจาก zone failure และโดยเฉพาะ **การหลีกเลี่ยง split-brain** (การป้องกันไม่ให้ primary สองตัวรับ write พร้อมกัน ซึ่งทำให้ข้อมูลเสียหาย เป็นความเสี่ยงร้ายแรงที่ consensus/fencing ป้องกัน)

การเข้าใจ **connection routing** (การนำแอปพลิเคชันไปยัง primary ปัจจุบันหลัง failover ผ่าน load balancer/proxy) และว่า failover (เช่นเดียวกับ backup) ควรถูก **ทดสอบ** ทำให้ความรู้เชิงปฏิบัติสมบูรณ์

การรู้ว่าหลายทีมใช้ **managed Postgres** สำหรับ HA ที่ผ่านการพิสูจน์มาแล้วก็เกี่ยวข้องเช่นกัน

เนื่องจาก availability ของฐานข้อมูลวิกฤตต่อระบบ production (การล่มทำให้ทุกอย่างล่ม) และเนื่องจากการบรรลุมันต้องเข้าใจ replication, automatic failover, การป้องกัน split-brain และ connection routing (หรือใช้ managed HA) การเข้าใจ high availability ของ PostgreSQL จึงเป็นความรู้ระดับ senior ที่สำคัญต่อการออกแบบระบบที่น่าเชื่อถือและทนทาน เป็นความกังวลที่มักวิกฤตสำหรับฐานข้อมูล production และเป็นหัวข้อที่แสดงถึงความเข้าใจในการสร้าง infrastructure ของฐานข้อมูลที่รอดจากความล้มเหลว ซึ่งคาดหวังสำหรับตำแหน่ง database/infrastructure ระดับ senior