RUK-COM / MANAGED DATABASE CLUSTERS

ข้อมูลเดินต่อ
ธุรกิจเดินหน้า

Database Cluster สำหรับระบบสำคัญขององค์กร ออกแบบ Replication, Failover และ Recovery ให้เหมาะกับงาน พร้อมทีม Ruk-Com ดูแลตั้งแต่ Architecture จนถึงวันที่ต้องกู้คืนจริง

สำรวจ Cluster Architecture ปรึกษาทีม Database
HA + Recovery Expert Support SQL · NoSQL · K8s

HIGHLIGHT / CLOUDNATIVEPG

PostgreSQL บน Kubernetes ด้วย CloudNativePG

CNCF CloudNativePG CNCF Sandbox Project ดู Architecture และจำลอง Failover
8 Database Engines
16 Cluster Architectures
4 สถานะให้ลองจำลอง
K8s CloudNativePG Solution
+

KUBERNETES + CLOUDNATIVEPG

PostgreSQL บน Kubernetes
ออกแบบเพื่อ Production

Solution แนะนำสำหรับทีมที่ต้องการดูแล PostgreSQL ผ่าน Kubernetes API ใช้ CloudNativePG Operator จัดการ Cluster, Streaming Replication, Failover และวงจร Backup โดยคง Data Path ของ PostgreSQL ให้ชัดเจน

CLUSTER / ARCHITECTURE LAB
เส้นทางที่แสดง

Kubernetes + CloudNativePG

PostgreSQL บน Kubernetes ที่แยก Write Service, Read Service และ WAL replication ชัดเจน Operator จัดการ Lifecycle และ Failover; PgBouncer ลด connection ส่วน PVC, Backup และ PITR แยกหน้าที่ครบ

ภาพจำลอง Architecture
Application Choose Read / Write endpoint
Ready
Kubernetes API Cluster CRD · primary Lease
Ready
PgBouncer Pooler Optional · HA connection pool
Ready
CloudNativePG Operator Reconcile · health · roles
Ready
cluster-rw Service → current Primary
Ready
cluster-ro Service → Ready replicas
Ready
Primary · Pod 1 Worker A · Read / Write
Ready
Replica A · Pod 2 Worker B · Read-only
Ready
Replica B · Pod 3 Worker C · Read-only
Ready
PVC 1 Dedicated persistent volume
Ready
PVC 2 Dedicated persistent volume
Ready
PVC 3 Dedicated persistent volume
Ready
Barman Cloud sidecar ภายใน Primary Pod · แยกหน้าที่ให้เห็น
Ready
Object Storage Base backups + WAL archive
Ready
New recovery cluster PITR workflow · on demand
Ready
Write request Read result Replication Monitor / Control Recovery / Sync PVC attachment

Write = คำสั่งเขียนเข้า Database · Read = ผลลัพธ์ที่ส่งกลับ Client (คำสั่ง SELECT วิ่งเข้า Database ในทิศตรงข้าม)

Write ผ่าน PgBouncer → cluster-rw → Primary; Read result กลับจาก Replica ผ่าน cluster-ro ไปยังแอป Primary ส่ง WAL ตรงไป Replica และแต่ละ Pod มี PVC ของตัวเอง

รายละเอียดและเอกสาร Architecture

PgBouncer เป็นตัวเลือกและอยู่หน้า cluster-rw; cluster-ro ชี้เฉพาะ Replica ส่วน cluster-r (ไม่วาด) อ่านได้จากทุก instance Operator/API เป็น Control plane; ไม่ใช่เส้นทาง SQL การกู้ PITR สร้าง Cluster ใหม่แยกจาก Failover สีแดงคือ Write request เข้าสู่ฐานข้อมูล สีเขียวคือ Read result กลับสู่ Client; คำสั่ง SELECT วิ่งสวนทางกับผลลัพธ์ สีส้มคือ Replication และเส้นประสีน้ำเงินคือ Monitor / Control Barman แสดงแยกเป็นขั้นตอนเพื่อให้อ่านง่าย แต่ทำงานเป็น Sidecar ภายใน Primary Pod ที่เป็นแหล่ง Backup ในตัวอย่างนี้ ไม่ใช่เครื่อง Backup เพิ่มเติม

เอกสารอ้างอิง ↗
เส้นทางข้อมูลในสถานะนี้
  • Application → PgBouncer Pooler · Write request
  • PgBouncer Pooler → cluster-rw · Write request
  • cluster-rw → Primary · Pod 1 · Write request
  • Primary · Pod 1 → cluster-rw · Read result
  • cluster-rw → PgBouncer Pooler · Read result
  • PgBouncer Pooler → Application · Read result
  • cluster-ro → Application · Read result
  • CloudNativePG Operator → Kubernetes API · Reconcile Cluster / Lease
  • CloudNativePG Operator → cluster-rw · Follow elected primary
  • CloudNativePG Operator → cluster-ro · Ready replica membership
  • Replica A · Pod 2 → cluster-ro · Read result
  • Primary · Pod 1 → Replica A · Pod 2 · WAL streaming
  • Replica B · Pod 3 → cluster-ro · Read result
  • Primary · Pod 1 → Replica B · Pod 3 · WAL streaming
  • Primary · Pod 1 → PVC 1 · Dedicated PVC mount
  • Replica A · Pod 2 → PVC 2 · Dedicated PVC mount
  • Replica B · Pod 3 → PVC 3 · Dedicated PVC mount
  • Primary · Pod 1 → Barman Cloud sidecar · Base backup / WAL source
  • Barman Cloud sidecar → Object Storage · Backup + WAL archive
  • Object Storage → New recovery cluster · PITR · restore into new cluster

Operator ดูแลระบบ
SQL วิ่งตรงเข้า Database

Client เขียนผ่าน cluster-rw และอ่านจาก Replica ผ่าน cluster-ro ส่วน cluster-r ใช้อ่านจากทุก Instance ที่ Ready ได้ เลือก Endpoint ตามความต้องการด้านความสดของข้อมูล เพิ่ม PgBouncer ได้เมื่อต้องการ Connection Pooling

Backup + WAL
กู้คืนบน Cluster ใหม่

ใช้ Barman Cloud plugin เก็บ Base Backup และ WAL Archive ไปยัง Object Storage กู้คืนด้วย PITR บน Cluster ใหม่ แล้วตรวจข้อมูลก่อนเปลี่ยน Client ไม่เขียนทับ Production เดิม

เชื่อมกับ Ruk-Com Object Storage →
01 เลือก Recovery Point 02 Restore Base Backup 03 Replay WAL 04 Validate New Cluster

PRODUCTION CHECKLIST

Best Practices สำหรับ PostgreSQL บน K8s

แยก Failure Domain

กระจาย Primary / Replica คนละ Worker ด้วย Anti-affinity และข้าม Zone เมื่อรองรับ พร้อม Capacity สำหรับ Recovery

PVC แยกทุก Instance

ตรวจ IOPS, Latency, WAL headroom และ CSI ที่รองรับการขยาย Volume แต่ละ Instance เก็บข้อมูลของตัวเอง

เลือก Sync Policy ให้ตรง RPO

Async ให้ความคล่องตัว ส่วน Synchronous replication และ Failover quorum ต้องแลกกับ Latency และความพร้อมในบางสถานการณ์

TLS + NetworkPolicy

ควบคุมสิทธิ์ให้น้อยเท่าที่จำเป็น ดูแล Secret และ Certificate แยกจาก Backup ของ Database

Monitor ทั้ง WAL และ Backup

ใช้ Metrics และ Logs ติดตาม Replication lag, WAL retention, Archive และ Backup พร้อม Alert ที่มี Runbook รองรับ

ซ้อมก่อน Production

ทดสอบ Switchover, Restore และ Reconnect พร้อม Resource requests และ PDB ที่เหมาะสม PDB ไม่ป้องกัน Hardware Failure

PITR ต้องมี Base Backup และ WAL ต่อเนื่องถึงจุดกู้คืน พร้อมสิทธิ์และ Key ที่ใช้งานได้ การเลือก Sync Policy ไม่ใช่คำรับประกันว่าไม่มีข้อมูลสูญหายในทุกเหตุการณ์

CloudNativePG Documentation ↗ Ruk-Com Managed Kubernetes →

CHOOSE YOUR DATABASE

แต่ละ Engine มีวิธีรักษาข้อมูลของตัวเอง

เลือก Engine และ Mode แล้วลองจำลอง Node Failure, Failover และการ Sync กลับ ดูเส้นทาง Client, Replication และ Recovery แยกกันอย่างชัดเจน

MySQL

MariaDB

Percona

PostgreSQL

MongoDB

Redis

Couchbase

OpenSearch

CLUSTER / ARCHITECTURE LAB
เส้นทางที่แสดง

MySQL Primary–Primary

Client ส่ง SQL ผ่าน ProxySQL 2 โหนด ทั้งสอง Primary รับเขียนได้และส่ง binlog หากัน ส่วน Secondary เพิ่มเติมใช้รองรับงานอ่าน

ภาพจำลอง Architecture
Database Client Read / Write
Ready
ProxySQL 1 Query routing
Ready
ProxySQL 2 Query routing
Ready
Primary 1 Read / Write
Ready
Primary 2 Read / Write
Ready
Extra Replica 1 Read-only
Ready
Extra Replica 2 Read-only
Ready
Write request Read result Replication Recovery / Sync

Write = คำสั่งเขียนเข้า Database · Read = ผลลัพธ์ที่ส่งกลับ Client (คำสั่ง SELECT วิ่งเข้า Database ในทิศตรงข้าม)

ProxySQL แยกเส้นทางอ่านและเขียน Primary ทั้งคู่ทำงานพร้อมกันและส่ง binlog ไปยังคู่ของตน

รายละเอียดและเอกสาร Architecture

แสดง ProxySQL 2 โหนดตามค่าเริ่มต้น โหนดเส้นประคือส่วนขยายที่เปิดใช้งานในตัวอย่างนี้ จำนวนที่วาดไม่ใช่จำนวนขั้นต่ำ สีแดงคือ Write request เข้าสู่ฐานข้อมูล สีเขียวคือ Read result กลับสู่ Client; คำสั่ง SELECT วิ่งสวนทางกับผลลัพธ์ สีส้มคือ Replication และเส้นประสีน้ำเงินคือ Monitor / Control เส้นทางอ่านที่วาดเป็นตัวอย่าง ทั้งสอง Proxy ใช้กลุ่มโหนดตามบทบาทเดียวกัน

เอกสารอ้างอิง ↗
เส้นทางข้อมูลในสถานะนี้
  • Database Client → ProxySQL 1 · Write request
  • ProxySQL 1 → Database Client · Read result
  • Database Client → ProxySQL 2 · Write request
  • ProxySQL 2 → Database Client · Read result
  • ProxySQL 1 → Primary 1 · Write request
  • Primary 1 → ProxySQL 1 · Read result
  • ProxySQL 1 → Primary 2 · Write request
  • Extra Replica 1 → ProxySQL 1 · Read result
  • ProxySQL 2 → Primary 1 · Write request
  • ProxySQL 2 → Primary 2 · Write request
  • Primary 2 → ProxySQL 2 · Read result
  • Extra Replica 2 → ProxySQL 2 · Read result
  • Primary 1 → Primary 2 · Binlog
  • Primary 2 → Primary 1 · Binlog
  • Primary 1 → Extra Replica 1 · Binlog
  • Primary 2 → Extra Replica 2 · Binlog

MySQL Primary–Secondary

SQL ผ่าน ProxySQL 2 โหนด งานเขียนไป Primary เดียว งานอ่านใช้ Secondary ได้ ProxySQL ตรวจสุขภาพและจัดเส้นทาง แต่ไม่ได้รับประกันการเลื่อน Secondary อัตโนมัติ

ภาพจำลอง Architecture
Database Client Read / Write
Ready
ProxySQL 1 Query routing
Ready
ProxySQL 2 Query routing
Ready
Primary Read / Write
Ready
Secondary Read-only
Ready
Extra Replica Read-only
Ready
Write request Read result Replication Recovery / Sync

Write = คำสั่งเขียนเข้า Database · Read = ผลลัพธ์ที่ส่งกลับ Client (คำสั่ง SELECT วิ่งเข้า Database ในทิศตรงข้าม)

Primary รับเขียนและส่ง binlog แบบ asynchronous ไป Secondary ทั้งสอง ProxySQL ช่วยกระจายงานอ่าน

รายละเอียดและเอกสาร Architecture

แสดง ProxySQL 2 โหนดตามค่าเริ่มต้น โหนดเส้นประคือส่วนขยายที่เปิดใช้งานในตัวอย่างนี้ จำนวนที่วาดไม่ใช่จำนวนขั้นต่ำ สีแดงคือ Write request เข้าสู่ฐานข้อมูล สีเขียวคือ Read result กลับสู่ Client; คำสั่ง SELECT วิ่งสวนทางกับผลลัพธ์ สีส้มคือ Replication และเส้นประสีน้ำเงินคือ Monitor / Control เส้นทางอ่านที่วาดเป็นตัวอย่าง ทั้งสอง Proxy ใช้กลุ่มโหนดตามบทบาทเดียวกัน

เอกสารอ้างอิง ↗
เส้นทางข้อมูลในสถานะนี้
  • Database Client → ProxySQL 1 · Write request
  • ProxySQL 1 → Database Client · Read result
  • Database Client → ProxySQL 2 · Write request
  • ProxySQL 2 → Database Client · Read result
  • ProxySQL 1 → Primary · Write request
  • Primary → ProxySQL 1 · Read result
  • Extra Replica → ProxySQL 1 · Read result
  • ProxySQL 2 → Primary · Write request
  • Secondary → ProxySQL 2 · Read result
  • Primary → Secondary · Binlog
  • Primary → Extra Replica · Binlog

MariaDB Primary–Primary

Client ส่ง SQL ผ่าน ProxySQL 2 โหนด ทั้งสอง Primary รับเขียนได้และส่ง binlog หากัน ส่วน Secondary เพิ่มเติมใช้รองรับงานอ่าน

ภาพจำลอง Architecture
Database Client Read / Write
Ready
ProxySQL 1 Query routing
Ready
ProxySQL 2 Query routing
Ready
Primary 1 Read / Write
Ready
Primary 2 Read / Write
Ready
Extra Replica 1 Read-only
Ready
Extra Replica 2 Read-only
Ready
Write request Read result Replication Recovery / Sync

Write = คำสั่งเขียนเข้า Database · Read = ผลลัพธ์ที่ส่งกลับ Client (คำสั่ง SELECT วิ่งเข้า Database ในทิศตรงข้าม)

ProxySQL แยกเส้นทางอ่านและเขียน Primary ทั้งคู่ทำงานพร้อมกันและส่ง binlog ไปยังคู่ของตน

รายละเอียดและเอกสาร Architecture

แสดง ProxySQL 2 โหนดตามค่าเริ่มต้น โหนดเส้นประคือส่วนขยายที่เปิดใช้งานในตัวอย่างนี้ จำนวนที่วาดไม่ใช่จำนวนขั้นต่ำ สีแดงคือ Write request เข้าสู่ฐานข้อมูล สีเขียวคือ Read result กลับสู่ Client; คำสั่ง SELECT วิ่งสวนทางกับผลลัพธ์ สีส้มคือ Replication และเส้นประสีน้ำเงินคือ Monitor / Control เส้นทางอ่านที่วาดเป็นตัวอย่าง ทั้งสอง Proxy ใช้กลุ่มโหนดตามบทบาทเดียวกัน

เอกสารอ้างอิง ↗
เส้นทางข้อมูลในสถานะนี้
  • Database Client → ProxySQL 1 · Write request
  • ProxySQL 1 → Database Client · Read result
  • Database Client → ProxySQL 2 · Write request
  • ProxySQL 2 → Database Client · Read result
  • ProxySQL 1 → Primary 1 · Write request
  • Primary 1 → ProxySQL 1 · Read result
  • ProxySQL 1 → Primary 2 · Write request
  • Extra Replica 1 → ProxySQL 1 · Read result
  • ProxySQL 2 → Primary 1 · Write request
  • ProxySQL 2 → Primary 2 · Write request
  • Primary 2 → ProxySQL 2 · Read result
  • Extra Replica 2 → ProxySQL 2 · Read result
  • Primary 1 → Primary 2 · Binlog
  • Primary 2 → Primary 1 · Binlog
  • Primary 1 → Extra Replica 1 · Binlog
  • Primary 2 → Extra Replica 2 · Binlog

MariaDB Primary–Secondary

SQL ผ่าน ProxySQL 2 โหนด งานเขียนไป Primary เดียว งานอ่านใช้ Secondary ได้ ProxySQL ตรวจสุขภาพและจัดเส้นทาง แต่ไม่ได้รับประกันการเลื่อน Secondary อัตโนมัติ

ภาพจำลอง Architecture
Database Client Read / Write
Ready
ProxySQL 1 Query routing
Ready
ProxySQL 2 Query routing
Ready
Primary Read / Write
Ready
Secondary Read-only
Ready
Extra Replica Read-only
Ready
Write request Read result Replication Recovery / Sync

Write = คำสั่งเขียนเข้า Database · Read = ผลลัพธ์ที่ส่งกลับ Client (คำสั่ง SELECT วิ่งเข้า Database ในทิศตรงข้าม)

Primary รับเขียนและส่ง binlog แบบ asynchronous ไป Secondary ทั้งสอง ProxySQL ช่วยกระจายงานอ่าน

รายละเอียดและเอกสาร Architecture

แสดง ProxySQL 2 โหนดตามค่าเริ่มต้น โหนดเส้นประคือส่วนขยายที่เปิดใช้งานในตัวอย่างนี้ จำนวนที่วาดไม่ใช่จำนวนขั้นต่ำ สีแดงคือ Write request เข้าสู่ฐานข้อมูล สีเขียวคือ Read result กลับสู่ Client; คำสั่ง SELECT วิ่งสวนทางกับผลลัพธ์ สีส้มคือ Replication และเส้นประสีน้ำเงินคือ Monitor / Control เส้นทางอ่านที่วาดเป็นตัวอย่าง ทั้งสอง Proxy ใช้กลุ่มโหนดตามบทบาทเดียวกัน

เอกสารอ้างอิง ↗
เส้นทางข้อมูลในสถานะนี้
  • Database Client → ProxySQL 1 · Write request
  • ProxySQL 1 → Database Client · Read result
  • Database Client → ProxySQL 2 · Write request
  • ProxySQL 2 → Database Client · Read result
  • ProxySQL 1 → Primary · Write request
  • Primary → ProxySQL 1 · Read result
  • Extra Replica → ProxySQL 1 · Read result
  • ProxySQL 2 → Primary · Write request
  • Secondary → ProxySQL 2 · Read result
  • Primary → Secondary · Binlog
  • Primary → Extra Replica · Binlog

MariaDB Galera

Client ใช้ ProxySQL 2 โหนดเพื่อเข้าถึงฐานข้อมูลที่รับเขียนได้หลายโหนด การรับรอง write set ช่วยให้สมาชิกในกลุ่มที่มี quorum รักษาความสอดคล้อง

ภาพจำลอง Architecture
Database Client Read / Write
Ready
ProxySQL 1 Query routing
Ready
ProxySQL 2 Query routing
Ready
Primary 1 Certified write sets
Ready
Primary 2 Certified write sets
Ready
Primary 3 Certified write sets
Ready
Primary 4 Certified write sets
Ready
Write request Read result Replication Recovery / Sync

Write = คำสั่งเขียนเข้า Database · Read = ผลลัพธ์ที่ส่งกลับ Client (คำสั่ง SELECT วิ่งเข้า Database ในทิศตรงข้าม)

สมาชิกทั้งสี่รับงานได้ โดยโหนดเส้นประคือส่วนขยายในตัวอย่าง ส่ง write set ระหว่างสมาชิก ไม่ใช่โครงสร้าง Primary เดียวกับ Secondary

รายละเอียดและเอกสาร Architecture

แสดง ProxySQL 2 โหนดตามค่าเริ่มต้น โหนดเส้นประคือส่วนขยายที่เปิดใช้งานในตัวอย่างนี้ จำนวนที่วาดไม่ใช่จำนวนขั้นต่ำ สีแดงคือ Write request เข้าสู่ฐานข้อมูล สีเขียวคือ Read result กลับสู่ Client; คำสั่ง SELECT วิ่งสวนทางกับผลลัพธ์ สีส้มคือ Replication และเส้นประสีน้ำเงินคือ Monitor / Control เส้นทางอ่านที่วาดเป็นตัวอย่าง ทั้งสอง Proxy ใช้กลุ่มโหนดตามบทบาทเดียวกัน เส้น Replication แสดงการแลกเปลี่ยน writeset ภายในกลุ่ม ไม่ใช่การส่งต่อแบบ chain replication

เอกสารอ้างอิง ↗
เส้นทางข้อมูลในสถานะนี้
  • Database Client → ProxySQL 1 · Write request
  • ProxySQL 1 → Database Client · Read result
  • Database Client → ProxySQL 2 · Write request
  • ProxySQL 2 → Database Client · Read result
  • ProxySQL 1 → Primary 1 · Write request
  • Primary 1 → ProxySQL 1 · Read result
  • ProxySQL 1 → Primary 2 · Write request
  • ProxySQL 1 → Primary 3 · Write request
  • Primary 3 → ProxySQL 1 · Read result
  • ProxySQL 1 → Primary 4 · Write request
  • ProxySQL 2 → Primary 1 · Write request
  • ProxySQL 2 → Primary 2 · Write request
  • Primary 2 → ProxySQL 2 · Read result
  • ProxySQL 2 → Primary 3 · Write request
  • ProxySQL 2 → Primary 4 · Write request
  • Primary 4 → ProxySQL 2 · Read result
  • Primary 1 → Primary 2 · Group writesets
  • Primary 2 → Primary 1 · Group writesets
  • Primary 2 → Primary 3 · Group writesets
  • Primary 3 → Primary 2 · Group writesets
  • Primary 3 → Primary 4 · Group writesets
  • Primary 4 → Primary 3 · Group writesets

Percona Primary–Primary

Client ส่ง SQL ผ่าน ProxySQL 2 โหนด ทั้งสอง Primary รับเขียนได้และส่ง binlog หากัน ส่วน Secondary เพิ่มเติมใช้รองรับงานอ่าน

ภาพจำลอง Architecture
Database Client Read / Write
Ready
ProxySQL 1 Query routing
Ready
ProxySQL 2 Query routing
Ready
Primary 1 Read / Write
Ready
Primary 2 Read / Write
Ready
Extra Replica 1 Read-only
Ready
Extra Replica 2 Read-only
Ready
Write request Read result Replication Recovery / Sync

Write = คำสั่งเขียนเข้า Database · Read = ผลลัพธ์ที่ส่งกลับ Client (คำสั่ง SELECT วิ่งเข้า Database ในทิศตรงข้าม)

ProxySQL แยกเส้นทางอ่านและเขียน Primary ทั้งคู่ทำงานพร้อมกันและส่ง binlog ไปยังคู่ของตน

รายละเอียดและเอกสาร Architecture

แสดง ProxySQL 2 โหนดตามค่าเริ่มต้น โหนดเส้นประคือส่วนขยายที่เปิดใช้งานในตัวอย่างนี้ จำนวนที่วาดไม่ใช่จำนวนขั้นต่ำ สีแดงคือ Write request เข้าสู่ฐานข้อมูล สีเขียวคือ Read result กลับสู่ Client; คำสั่ง SELECT วิ่งสวนทางกับผลลัพธ์ สีส้มคือ Replication และเส้นประสีน้ำเงินคือ Monitor / Control เส้นทางอ่านที่วาดเป็นตัวอย่าง ทั้งสอง Proxy ใช้กลุ่มโหนดตามบทบาทเดียวกัน

เอกสารอ้างอิง ↗
เส้นทางข้อมูลในสถานะนี้
  • Database Client → ProxySQL 1 · Write request
  • ProxySQL 1 → Database Client · Read result
  • Database Client → ProxySQL 2 · Write request
  • ProxySQL 2 → Database Client · Read result
  • ProxySQL 1 → Primary 1 · Write request
  • Primary 1 → ProxySQL 1 · Read result
  • ProxySQL 1 → Primary 2 · Write request
  • Extra Replica 1 → ProxySQL 1 · Read result
  • ProxySQL 2 → Primary 1 · Write request
  • ProxySQL 2 → Primary 2 · Write request
  • Primary 2 → ProxySQL 2 · Read result
  • Extra Replica 2 → ProxySQL 2 · Read result
  • Primary 1 → Primary 2 · Binlog
  • Primary 2 → Primary 1 · Binlog
  • Primary 1 → Extra Replica 1 · Binlog
  • Primary 2 → Extra Replica 2 · Binlog

Percona Primary–Secondary

SQL ผ่าน ProxySQL 2 โหนด งานเขียนไป Primary เดียว งานอ่านใช้ Secondary ได้ ProxySQL ตรวจสุขภาพและจัดเส้นทาง แต่ไม่ได้รับประกันการเลื่อน Secondary อัตโนมัติ

ภาพจำลอง Architecture
Database Client Read / Write
Ready
ProxySQL 1 Query routing
Ready
ProxySQL 2 Query routing
Ready
Primary Read / Write
Ready
Secondary Read-only
Ready
Extra Replica Read-only
Ready
Write request Read result Replication Recovery / Sync

Write = คำสั่งเขียนเข้า Database · Read = ผลลัพธ์ที่ส่งกลับ Client (คำสั่ง SELECT วิ่งเข้า Database ในทิศตรงข้าม)

Primary รับเขียนและส่ง binlog แบบ asynchronous ไป Secondary ทั้งสอง ProxySQL ช่วยกระจายงานอ่าน

รายละเอียดและเอกสาร Architecture

แสดง ProxySQL 2 โหนดตามค่าเริ่มต้น โหนดเส้นประคือส่วนขยายที่เปิดใช้งานในตัวอย่างนี้ จำนวนที่วาดไม่ใช่จำนวนขั้นต่ำ สีแดงคือ Write request เข้าสู่ฐานข้อมูล สีเขียวคือ Read result กลับสู่ Client; คำสั่ง SELECT วิ่งสวนทางกับผลลัพธ์ สีส้มคือ Replication และเส้นประสีน้ำเงินคือ Monitor / Control เส้นทางอ่านที่วาดเป็นตัวอย่าง ทั้งสอง Proxy ใช้กลุ่มโหนดตามบทบาทเดียวกัน

เอกสารอ้างอิง ↗
เส้นทางข้อมูลในสถานะนี้
  • Database Client → ProxySQL 1 · Write request
  • ProxySQL 1 → Database Client · Read result
  • Database Client → ProxySQL 2 · Write request
  • ProxySQL 2 → Database Client · Read result
  • ProxySQL 1 → Primary · Write request
  • Primary → ProxySQL 1 · Read result
  • Extra Replica → ProxySQL 1 · Read result
  • ProxySQL 2 → Primary · Write request
  • Secondary → ProxySQL 2 · Read result
  • Primary → Secondary · Binlog
  • Primary → Extra Replica · Binlog

Percona XtraDB

Client ใช้ ProxySQL 2 โหนดเพื่อเข้าถึงฐานข้อมูลที่รับเขียนได้หลายโหนด การรับรอง write set ช่วยให้สมาชิกในกลุ่มที่มี quorum รักษาความสอดคล้อง

ภาพจำลอง Architecture
Database Client Read / Write
Ready
ProxySQL 1 Query routing
Ready
ProxySQL 2 Query routing
Ready
Primary 1 Certified write sets
Ready
Primary 2 Certified write sets
Ready
Primary 3 Certified write sets
Ready
Primary 4 Certified write sets
Ready
Write request Read result Replication Recovery / Sync

Write = คำสั่งเขียนเข้า Database · Read = ผลลัพธ์ที่ส่งกลับ Client (คำสั่ง SELECT วิ่งเข้า Database ในทิศตรงข้าม)

สมาชิกทั้งสี่รับงานได้ โดยโหนดเส้นประคือส่วนขยายในตัวอย่าง ส่ง write set ระหว่างสมาชิก ไม่ใช่โครงสร้าง Primary เดียวกับ Secondary

รายละเอียดและเอกสาร Architecture

แสดง ProxySQL 2 โหนดตามค่าเริ่มต้น โหนดเส้นประคือส่วนขยายที่เปิดใช้งานในตัวอย่างนี้ จำนวนที่วาดไม่ใช่จำนวนขั้นต่ำ สีแดงคือ Write request เข้าสู่ฐานข้อมูล สีเขียวคือ Read result กลับสู่ Client; คำสั่ง SELECT วิ่งสวนทางกับผลลัพธ์ สีส้มคือ Replication และเส้นประสีน้ำเงินคือ Monitor / Control เส้นทางอ่านที่วาดเป็นตัวอย่าง ทั้งสอง Proxy ใช้กลุ่มโหนดตามบทบาทเดียวกัน เส้น Replication แสดงการแลกเปลี่ยน writeset ภายในกลุ่ม ไม่ใช่การส่งต่อแบบ chain replication

เอกสารอ้างอิง ↗
เส้นทางข้อมูลในสถานะนี้
  • Database Client → ProxySQL 1 · Write request
  • ProxySQL 1 → Database Client · Read result
  • Database Client → ProxySQL 2 · Write request
  • ProxySQL 2 → Database Client · Read result
  • ProxySQL 1 → Primary 1 · Write request
  • Primary 1 → ProxySQL 1 · Read result
  • ProxySQL 1 → Primary 2 · Write request
  • ProxySQL 1 → Primary 3 · Write request
  • Primary 3 → ProxySQL 1 · Read result
  • ProxySQL 1 → Primary 4 · Write request
  • ProxySQL 2 → Primary 1 · Write request
  • ProxySQL 2 → Primary 2 · Write request
  • Primary 2 → ProxySQL 2 · Read result
  • ProxySQL 2 → Primary 3 · Write request
  • ProxySQL 2 → Primary 4 · Write request
  • Primary 4 → ProxySQL 2 · Read result
  • Primary 1 → Primary 2 · Group writesets
  • Primary 2 → Primary 1 · Group writesets
  • Primary 2 → Primary 3 · Group writesets
  • Primary 3 → Primary 2 · Group writesets
  • Primary 3 → Primary 4 · Group writesets
  • Primary 4 → Primary 3 · Group writesets

PostgreSQL Standard

Client เชื่อมต่อ PostgreSQL โดยตรง งานเขียนไป Primary เดียวและอ่านจาก Secondary ได้ตามการตั้งค่า ไม่มี proxy จัดการ failover อัตโนมัติ

ภาพจำลอง Architecture
Database Client Read / Write
Ready
Primary Read / Write
Ready
Secondary Read-only
Ready
Extra Replica Read-only
Ready
Write request Read result Replication Recovery / Sync

Write = คำสั่งเขียนเข้า Database · Read = ผลลัพธ์ที่ส่งกลับ Client (คำสั่ง SELECT วิ่งเข้า Database ในทิศตรงข้าม)

Primary ส่ง WAL ไปยัง Secondary แบบ asynchronous งานเขียนและงานอ่านแยกตามบทบาท สมาชิกเส้นประเป็นส่วนขยายในตัวอย่าง

รายละเอียดและเอกสาร Architecture

ภาพแสดง Primary 1, Secondary 1 และ Secondary เพิ่มเติม 1 โหนด เส้นประคือส่วนขยายที่เปิดใช้ในตัวอย่าง สีแดงคือ Write request เข้าสู่ฐานข้อมูล สีเขียวคือ Read result กลับสู่ Client; คำสั่ง SELECT วิ่งสวนทางกับผลลัพธ์ สีส้มคือ Replication และเส้นประสีน้ำเงินคือ Monitor / Control

เอกสารอ้างอิง ↗
เส้นทางข้อมูลในสถานะนี้
  • Database Client → Primary · Write request
  • Primary → Database Client · Read result
  • Secondary → Database Client · Read result
  • Extra Replica → Database Client · Read result
  • Primary → Secondary · WAL
  • Primary → Extra Replica · WAL

PostgreSQL + Pgpool-II

Client ส่ง SQL ผ่าน Pgpool-II ที่ active โดย Watchdog ประสานกับ proxy standby งานเขียนไป Primary และงานอ่านใช้ Secondary ได้ Pgpool-II ตรวจสุขภาพเพื่อจัดการ failover

ภาพจำลอง Architecture
Database Client Read / Write
Ready
Pgpool Active Read / Write routing
Ready
Pgpool Standby Watchdog
Ready
Pgpool Standby Watchdog
Ready
Primary Read / Write
Ready
Secondary Read-only
Ready
Extra Replica Read-only
Ready
Write request Read result Replication Monitor / Control Recovery / Sync

Write = คำสั่งเขียนเข้า Database · Read = ผลลัพธ์ที่ส่งกลับ Client (คำสั่ง SELECT วิ่งเข้า Database ในทิศตรงข้าม)

Primary ส่ง WAL ไปยัง Secondary แบบ asynchronous งานเขียนและงานอ่านแยกตามบทบาท สมาชิกเส้นประเป็นส่วนขยายในตัวอย่าง

รายละเอียดและเอกสาร Architecture

ภาพแสดง Pgpool-II active 1 และ standby เพิ่มเติม 2 โหนด พร้อมฐานข้อมูล 3 โหนด การทำสำเนา WAL เป็น asynchronous ไม่ใช่ Patroni สีแดงคือ Write request เข้าสู่ฐานข้อมูล สีเขียวคือ Read result กลับสู่ Client; คำสั่ง SELECT วิ่งสวนทางกับผลลัพธ์ สีส้มคือ Replication และเส้นประสีน้ำเงินคือ Monitor / Control

เอกสารอ้างอิง ↗
เส้นทางข้อมูลในสถานะนี้
  • Database Client → Pgpool Active · Write request
  • Pgpool Active → Database Client · Read result
  • Pgpool Active → Pgpool Standby · Watchdog
  • Pgpool Standby → Pgpool Active · Watchdog
  • Pgpool Active → Pgpool Standby · Watchdog
  • Pgpool Standby → Pgpool Active · Watchdog
  • Pgpool Active → Primary · Write request
  • Primary → Pgpool Active · Read result
  • Secondary → Pgpool Active · Read result
  • Extra Replica → Pgpool Active · Read result
  • Primary → Secondary · WAL
  • Primary → Extra Replica · WAL
  • Pgpool Active → Primary · Monitor / role check
  • Pgpool Active → Secondary · Monitor / role check
  • Pgpool Active → Extra Replica · Monitor / role check

PostgreSQL HA · Patroni + HAProxy

แยก Write endpoint ไป Primary และ Read endpoint ไป Replica ผ่าน HAProxy โดยใช้ PgBouncer เป็น connection pool เพิ่มเติม Patroni จัดการบทบาทร่วมกับ etcd quorum ส่วน WAL ส่งตรงระหว่าง PostgreSQL

ภาพจำลอง Architecture
Application Read / Write endpoints
Ready
HAProxy / Cloud LB Role-aware SQL routing
Ready
PgBouncer 1 Optional connection pool
Ready
PgBouncer 2 Optional connection pool
Ready
PgBouncer 3 Optional connection pool
Ready
PgBouncer 4 Optional connection pool
Ready
Replica · Node 1 PostgreSQL + Patroni
Ready
Primary · Node 2 PostgreSQL + Patroni
Ready
Replica · Node 3 PostgreSQL + Patroni
Ready
Extra Replica PostgreSQL + Patroni
Ready
etcd 1 DCS · quorum member
Ready
etcd 2 DCS · quorum member
Ready
etcd 3 DCS · quorum member
Ready
Write request Read result Replication Monitor / Control Recovery / Sync

Write = คำสั่งเขียนเข้า Database · Read = ผลลัพธ์ที่ส่งกลับ Client (คำสั่ง SELECT วิ่งเข้า Database ในทิศตรงข้าม)

HAProxy ส่ง Write ไป Node 2 ที่ถือ leader lock งานอ่านใช้ Replica; PgBouncer ลดจำนวน connection และ WAL วิ่งจาก Primary ไป Replica โดยตรง

รายละเอียดและเอกสาร Architecture

ภาพอ้างอิงแสดง PostgreSQL 3 โหนดและ Replica ที่ขยายเพิ่มได้ พร้อม etcd 3 โหนด; PgBouncer และ VIP เป็นตัวเลือก HAProxy ตรวจบทบาทผ่าน Patroni; etcd ไม่เก็บ SQL หรือ WAL ระบบนี้แยกจาก CloudNativePG สีแดงคือ Write request เข้าสู่ฐานข้อมูล สีเขียวคือ Read result กลับสู่ Client; คำสั่ง SELECT วิ่งสวนทางกับผลลัพธ์ สีส้มคือ Replication และเส้นประสีน้ำเงินคือ Monitor / Control

เอกสารอ้างอิง ↗
เส้นทางข้อมูลในสถานะนี้
  • Application → HAProxy / Cloud LB · Write request
  • HAProxy / Cloud LB → Application · Read result
  • HAProxy / Cloud LB → PgBouncer 2 · Write request
  • PgBouncer 2 → Primary · Node 2 · Write request
  • Primary · Node 2 → PgBouncer 2 · Read result
  • PgBouncer 2 → HAProxy / Cloud LB · Read result
  • Replica · Node 1 → PgBouncer 1 · Read result
  • PgBouncer 1 → HAProxy / Cloud LB · Read result
  • Primary · Node 2 → Replica · Node 1 · WAL streaming
  • Replica · Node 3 → PgBouncer 3 · Read result
  • PgBouncer 3 → HAProxy / Cloud LB · Read result
  • Primary · Node 2 → Replica · Node 3 · WAL streaming
  • Extra Replica → PgBouncer 4 · Read result
  • PgBouncer 4 → HAProxy / Cloud LB · Read result
  • Primary · Node 2 → Extra Replica · WAL streaming
  • HAProxy / Cloud LB → Primary · Node 2 · /primary health
  • Primary · Node 2 → etcd 2 · Patroni · leader / member state
  • HAProxy / Cloud LB → Replica · Node 1 · /replica?lag health
  • Replica · Node 1 → etcd 1 · Patroni · leader / member state
  • HAProxy / Cloud LB → Replica · Node 3 · /replica?lag health
  • Replica · Node 3 → etcd 3 · Patroni · leader / member state
  • HAProxy / Cloud LB → Extra Replica · /replica?lag health
  • Extra Replica → etcd 3 · Patroni · leader / member state
  • etcd 1 → etcd 2 · Raft quorum
  • etcd 2 → etcd 3 · Raft quorum

MongoDB Replica Set

Driver ค้นหาสมาชิก replica set และส่งเขียนไป Primary งานอ่านใช้ Primary ตามค่าเริ่มต้นหรือ Secondary ตาม read preference ไม่มี proxy แยกต่างหาก

ภาพจำลอง Architecture
MongoDB Driver Replica-set discovery
Ready
Primary Writes
Ready
Secondary 1 Oplog replica
Ready
Secondary 2 Oplog replica
Ready
Write request Read result Replication Monitor / Control Recovery / Sync

Write = คำสั่งเขียนเข้า Database · Read = ผลลัพธ์ที่ส่งกลับ Client (คำสั่ง SELECT วิ่งเข้า Database ในทิศตรงข้าม)

Primary บันทึกการเปลี่ยนแปลงใน oplog และส่งต่อแบบ asynchronous ไป Secondary ทั้งสอง Driver เลือกปลายทางตามบทบาท

รายละเอียดและเอกสาร Architecture

ตัวอย่างสมาชิกที่เก็บข้อมูล 3 โหนด ต้องมีเสียงข้างมากเพื่อเลือก Primary เวลา election ไม่ใช่ SLA และ Secondary อาจมีข้อมูลช้ากว่า Primary สีแดงคือ Write request เข้าสู่ฐานข้อมูล สีเขียวคือ Read result กลับสู่ Client; คำสั่ง SELECT วิ่งสวนทางกับผลลัพธ์ สีส้มคือ Replication และเส้นประสีน้ำเงินคือ Monitor / Control

เอกสารอ้างอิง ↗
เส้นทางข้อมูลในสถานะนี้
  • MongoDB Driver → Primary · Write request
  • Primary → MongoDB Driver · Read result
  • Secondary 1 → MongoDB Driver · Read result · secondaryPreferred
  • Secondary 2 → MongoDB Driver · Read result · secondaryPreferred
  • Primary → Secondary 1 · Oplog
  • Primary → Secondary 2 · Oplog
  • Secondary 1 → Secondary 2 · Heartbeat / voting

Redis Cluster

Client ที่รองรับ Redis Cluster ส่งคำสั่งตรงไป Primary เจ้าของ hash slot แต่ละ Primary มี Replica หนึ่งโหนด ไม่มี proxy และไม่มี Sentinel ในโครงสร้างนี้

ภาพจำลอง Architecture
Cluster Client Hash-slot routing
Ready
Primary 1 Shard 1
Ready
Replica 1 Shard 1 copy
Ready
Primary 2 Shard 2
Ready
Replica 2 Shard 2 copy
Ready
Primary 3 Shard 3
Ready
Replica 3 Shard 3 copy
Ready
Write request Read result Replication Monitor / Control Recovery / Sync

Write = คำสั่งเขียนเข้า Database · Read = ผลลัพธ์ที่ส่งกลับ Client (คำสั่ง SELECT วิ่งเข้า Database ในทิศตรงข้าม)

ข้อมูลแบ่งเป็นสาม shard ทุก Primary รับเขียนเฉพาะ slot ที่ตนรับผิดชอบและส่งสำเนาให้ Replica ของตน

รายละเอียดและเอกสาร Architecture

3 Primary + 3 Replica รวม 6 โหนด ขยายเป็นคู่พร้อม reshard การทำสำเนา asynchronous จึงมีโอกาสสูญเสียงานเขียนบางส่วนขณะ failover สีแดงคือ Write request เข้าสู่ฐานข้อมูล สีเขียวคือ Read result กลับสู่ Client; คำสั่ง SELECT วิ่งสวนทางกับผลลัพธ์ สีส้มคือ Replication และเส้นประสีน้ำเงินคือ Monitor / Control

เอกสารอ้างอิง ↗
เส้นทางข้อมูลในสถานะนี้
  • Cluster Client → Primary 1 · Write request
  • Primary 1 → Cluster Client · Read result
  • Primary 1 → Replica 1 · Async replication
  • Cluster Client → Primary 2 · Write request
  • Primary 2 → Cluster Client · Read result
  • Primary 2 → Replica 2 · Async replication
  • Cluster Client → Primary 3 · Write request
  • Primary 3 → Cluster Client · Read result
  • Primary 3 → Replica 3 · Async replication

Couchbase Cluster

SDK ใช้แผนที่ vBucket เพื่อเข้าถึงโหนดเจ้าของข้อมูลโดยตรง แต่ละโหนดเก็บ active และ replica vBucket การเพิ่มหรือลดโหนดใช้ rebalance ไม่มี proxy แยกต่างหาก

ภาพจำลอง Architecture
Couchbase SDK vBucket routing
Ready
Couchbase 1 Active + replica vBuckets
Ready
Couchbase 2 Active + replica vBuckets
Ready
Couchbase 3 Active + replica vBuckets
Ready
Couchbase 4 Active + replica vBuckets
Ready
Write request Read result Replication Recovery / Sync

Write = คำสั่งเขียนเข้า Database · Read = ผลลัพธ์ที่ส่งกลับ Client (คำสั่ง SELECT วิ่งเข้า Database ในทิศตรงข้าม)

SDK ส่งงานตาม vBucket map และข้อมูลสำเนาอยู่บนสมาชิกอื่น ลูกศรแสดงตัวอย่างการกระจาย ไม่ใช่สำเนาฐานข้อมูลเต็มชุดทุกโหนด

รายละเอียดและเอกสาร Architecture

คงภาพอ้างอิงที่มี 2 โหนดทึบและ 2 โหนดเส้นประเพื่อสื่อการขยาย ไม่ได้หมายถึงเริ่มใช้งานด้วย 2 โหนด ค่าเริ่มต้นของแพ็กเกจคือ 3 โหนด ตัวอย่างนี้เปิดใช้ครบ 4 โหนดและต้องตั้ง replica / failover ให้เหมาะสม สีแดงคือ Write request เข้าสู่ฐานข้อมูล สีเขียวคือ Read result กลับสู่ Client; คำสั่ง SELECT วิ่งสวนทางกับผลลัพธ์ สีส้มคือ Replication และเส้นประสีน้ำเงินคือ Monitor / Control

เอกสารอ้างอิง ↗
เส้นทางข้อมูลในสถานะนี้
  • Couchbase SDK → Couchbase 1 · Write request
  • Couchbase 1 → Couchbase SDK · Read result
  • Couchbase SDK → Couchbase 2 · Write request
  • Couchbase 2 → Couchbase SDK · Read result
  • Couchbase SDK → Couchbase 3 · Write request
  • Couchbase 3 → Couchbase SDK · Read result
  • Couchbase SDK → Couchbase 4 · Write request
  • Couchbase 4 → Couchbase SDK · Read result
  • Couchbase 1 → Couchbase 2 · vBuckets
  • Couchbase 2 → Couchbase 3 · vBuckets
  • Couchbase 3 → Couchbase 4 · vBuckets
  • Couchbase 4 → Couchbase 1 · vBuckets

OpenSearch Cluster

Beats ส่งข้อมูลผ่าน Logstash เข้า OpenSearch ส่วน Dashboards ค้นหาและแสดงผล ตัวอย่างขยายชั้น OpenSearch เป็น 3 โหนดเพื่ออธิบาย shard recovery ไม่ใช่จำนวนขั้นต่ำของแพ็กเกจ

ภาพจำลอง Architecture
Beats Data shippers
Ready
Logstash Transform / ingest
Ready
Dashboards Search / visualize
Ready
OpenSearch 1 Shard A primary
Ready
OpenSearch 2 Shard A replica
Ready
OpenSearch 3 Other shards
Ready
Write request Read result Replication Recovery / Sync

Write = คำสั่งเขียนเข้า Database · Read = ผลลัพธ์ที่ส่งกลับ Client (คำสั่ง SELECT วิ่งเข้า Database ในทิศตรงข้าม)

Logstash ส่งข้อมูลเข้าคลัสเตอร์ Dashboards อ่านผลค้นหา shard A มี Primary บนโหนด 1 และ Replica บนโหนด 2 ส่วนโหนด 3 รองรับ shard อื่น

รายละเอียดและเอกสาร Architecture

รักษาลำดับ Beats → Logstash → OpenSearch ← Dashboards ตามภาพอ้างอิง Logstash และ Dashboards เป็นส่วนเสริม ตำแหน่ง shard A เป็นตัวอย่าง ไม่ใช่ Primary กลางของทั้งฐานข้อมูล สีแดงคือ Write request เข้าสู่ฐานข้อมูล สีเขียวคือ Read result กลับสู่ Client; คำสั่ง SELECT วิ่งสวนทางกับผลลัพธ์ สีส้มคือ Replication และเส้นประสีน้ำเงินคือ Monitor / Control

เอกสารอ้างอิง ↗
เส้นทางข้อมูลในสถานะนี้
  • Beats → Logstash · Ingest events
  • Logstash → OpenSearch 1 · Index documents
  • Logstash → OpenSearch 3 · Index documents
  • OpenSearch 1 → Dashboards · Search result
  • OpenSearch 2 → Dashboards · Search result
  • OpenSearch 3 → Dashboards · Search result
  • OpenSearch 1 → OpenSearch 2 · Shard A replica

Failover อัตโนมัติขึ้นกับ Mode, Quorum และการตั้งค่า โดย MySQL / MariaDB / Percona แบบ Primary–Secondary และ PostgreSQL แบบ Standard ต้องมีขั้นตอน Promote และเปลี่ยนเส้นทางโดยผู้ดูแล

AVAILABILITY + RECOVERABILITY

ดูแลทั้งบริการที่ต้องพร้อม
และข้อมูลที่ต้องกู้กลับได้

Replication ช่วยให้มีสำเนาที่พร้อมใช้งาน ส่วน Backup ช่วยย้อนกลับก่อนข้อมูลถูกลบหรือแก้ผิด องค์กรต้องวางทั้งสองส่วนให้ทำงานร่วมกัน

Replication ที่เหมาะกับ Workload

เลือก Async, Streaming หรือ Quorum-based replication ตาม Engine และข้อกำหนดด้าน Latency, Consistency และ RPO

Failover ที่มีเงื่อนไขชัดเจน

ตรวจ Candidate, Quorum และการแยก Primary เดิม ก่อนเปิดเส้นทางเขียนใหม่ พร้อมทดสอบ Reconnect และ Retry จาก Client

Recovery ที่ทดสอบได้

กำหนด Retention, Recovery Point และ Restore Drill สำรองข้อมูลแยกจาก Cluster และตรวจว่ากู้ข้อมูลกลับมาใช้งานได้จริง

REJOIN ≠ READY

Node กลับมาออนไลน์ → ตรวจ Timeline / Log → Catch-up หรือ Rebuild → ตรวจความพร้อม → คืน Traffic

RUK-COM / DATABASE OPERATIONS

มากกว่าสร้าง Cluster
คือมีทีมดูแลวงจรชีวิตข้อมูล

กำหนดขอบเขตการดูแลและ SLA ให้ตรงความสำคัญของระบบ ตั้งแต่ Performance จนถึง Incident Response และแผน Recovery

Performance & Observability

ติดตาม Query latency, Connection, Replication lag, Slow query, Disk และผล Backup เพื่อให้ทีมเห็นปัญหาก่อนกระทบบริการ

Capacity & Scaling

วาง Read Replica, Connection Pool และการขยาย Storage ตาม Engine พร้อมประเมิน IOPS, WAL / Binlog และพื้นที่เผื่อ Recovery

Security by Design

ออกแบบ Private Network, TLS และสิทธิ์ตามหน้าที่ พร้อมจัดการ Secret, Patch และ Audit ตามนโยบายขององค์กร

Expert Incident Support

ทีมผู้เชี่ยวชาญช่วยวิเคราะห์ตั้งแต่ Client connection และ Query ไปจนถึง Proxy, Replication และ Infrastructure

Maintenance & Recovery Drill

ทดสอบ Switchover, Failover, Restore และ Rollback ก่อนเปลี่ยน Production เก็บ Runbook และผลการทดสอบให้ทีมใช้งานต่อได้

Ruk-Com Agent + ผู้เชี่ยวชาญ

Agent ช่วยสรุปสัญญาณผิดปกติและจัดลำดับตรวจสอบ โดยการเข้าถึงข้อมูลและการเปลี่ยนระบบอยู่ภายใต้สิทธิ์และขั้นตอนที่ตกลง

ASSESS / MIGRATE / OPERATE

ย้ายอย่างมีแผน
ดูแลต่ออย่างเป็นระบบ

01

Assess

ตรวจ Engine, Version, ขนาดข้อมูล, Extension และ RPO / RTO

สิ่งส่งมอบ ขอบเขตและเป้าหมายระบบ
02

Design & Rehearse

เลือก Topology และซ้อมย้ายด้วยข้อมูลที่ได้รับอนุญาต

สิ่งส่งมอบ Architecture และแผนทดสอบ
03

Sync & Cutover

ตรวจความครบถ้วน กำหนด Write Freeze และ Rollback ตามวิธีย้าย

สิ่งส่งมอบ ผลตรวจข้อมูลและแผน Rollback
04

Operate & Improve

ส่งมอบ Runbook, Monitoring และแผน Backup / Capacity

สิ่งส่งมอบ Runbook และแผนดูแล

BEFORE YOU DEPLOY

คำถามก่อนวาง
Database Cluster

มี HA แล้วต้อง Backup อีกไหม?

ต้องมีครับ การลบข้อมูลหรือแก้ไขผิดอาจถูก Replicate ไปทุกสำเนา ควรมี Backup แยก Retention ที่เหมาะสม และทดสอบ Restore เป็นระยะ

ทุก Mode สลับ Primary ให้อัตโนมัติหรือไม่?

ไม่ใช่ทุก Mode ครับ บางแบบอาศัย Quorum และระบบตรวจสอบ บางแบบต้อง Promote โดยผู้ดูแล โดยเฉพาะ MySQL-family Primary–Secondary และ PostgreSQL Standard ตาม Reference นี้

Rejoin แล้วรับ Traffic ได้เลยไหม?

ต้องตรวจความสอดคล้องและตามข้อมูลให้ทันก่อน อาจใช้ Binlog, WAL, Oplog, IST / SST หรือ Rebuild ตาม Engine และประวัติข้อมูลที่ยังมีอยู่

รับประกัน RPO / RTO เท่าไร?

กำหนดเป็นรายระบบจาก Sync Policy, ขนาดข้อมูล, Network, Backup และวิธี Recovery แล้วทดสอบก่อนตกลง SLA ไม่ใช้ตัวเลขเดียวกับทุก Engine

เริ่มต้นต้องเตรียมข้อมูลอะไร?

แจ้ง Engine / Version, ขนาดข้อมูล, Workload อ่านเขียน, Peak connection, Extension และข้อกำหนดด้าน Security พร้อมช่วงเวลาที่สะดวกในการย้าย

YOUR DATA / OUR EXPERTISE

เริ่มจากข้อมูลสำคัญของคุณ
ออกแบบ Cluster ที่เหมาะไปด้วยกัน

คุย Architecture, Migration และขอบเขต Managed Service กับทีม Ruk-Com

ปรึกษา Database Solution