1. Đặt vấn đề: Tại sao doanh nghiệp cần PostgreSQL High Availability (HA)?

Trong kỷ nguyên số, dữ liệu được ví như dòng máu của doanh nghiệp. Một phút gián đoạn dịch vụ (downtime) của hệ thống cơ sở dữ liệu không chỉ gây thiệt hại lớn về mặt tài chính mà còn làm suy giảm nghiêm trọng uy tín thương hiệu. Đối với các hệ thống sử dụng PostgreSQL, việc cấu hình một cơ chế có tính sẵn sàng cao (High Availability - HA) là yêu cầu bắt buộc đối với các kỹ sư hệ thống và kiến trúc sư giải pháp.

Mặc dù PostgreSQL hỗ trợ cơ chế Streaming Replication mặc định, nhưng giải pháp này lại thiếu khả năng tự động phát hiện sự cố và chuyển vùng dữ liệu (failover). Nếu nút chính (Primary Node) gặp sự cố, quản trị viên phải can thiệp thủ công để chuyển một nút phụ (Standby Node) lên làm nút chính. Điều này tốn thời gian và dễ xảy ra sai sót. Đó là lý do tại sao bộ ba Patroni, Etcd và PgBouncer trở thành kiến trúc vàng được các doanh nghiệp lớn tin dùng.

2. Kiến trúc giải pháp trên 3 Cloud Server

Để đảm bảo thuật toán đồng thuận (Consensus) hoạt động chính xác và tránh hiện tượng "não đôi" (Split-Brain), mô hình tối thiểu yêu cầu phải có 3 Cloud Server (3 Nodes). Dưới đây là vai trò của từng thành phần trong mô hình kiến trúc:

Patroni: Là một template mã nguồn mở được viết bằng Python, đóng vai trò quản lý và tự động hóa việc cấu hình, khởi tạo và quản lý failover cho PostgreSQL.
Etcd: Hệ thống lưu trữ dữ liệu dạng key-value phân tán, đóng vai trò làm nguồn chân lý (Distributed Configuration Store - DCS) để Patroni theo dõi trạng thái của cụm (cluster).
PgBouncer: Trình quản lý kết nối (Connection Pooler) giúp giảm tải số lượng kết nối trực tiếp đến PostgreSQL, đồng thời định tuyến chính xác traffic của ứng dụng đến đúng nút Primary hiện tại.

Kiến trúc 3 nút đảm bảo rằng nếu một nút bất kỳ bị sập, hai nút còn lại vẫn duy trì được số đông (Quorum) để bầu chọn ra một nút Primary mới mà không làm gián đoạn dịch vụ của doanh nghiệp.

3. Quy trình triển khai chi tiết trên 3 Cloud Server

Giả sử chúng ta có 3 Cloud Server với IP lần lượt là: 10.0.0.1 (Node 1), 10.0.0.2 (Node 2), và 10.0.0.3 (Node 3). Hệ điều hành khuyến nghị là Ubuntu Server 22.04 LTS hoặc Rocky Linux 9.

Bước 1: Cài đặt và cấu hình cụm Etcd

Etcd cần được cài đặt trên cả 3 node để tạo thành một cụm phân tán. Trên mỗi node, tiến hành cài đặt gói etcd và cấu hình tệp /etc/etcd/etcd.yml. Bạn cần chỉ định chính xác danh sách các thành viên trong cụm và địa chỉ IP lắng nghe kết nối.

Sau khi cấu hình, khởi động dịch vụ etcd và kiểm tra trạng thái hoạt động bằng lệnh:

etcdctl endpoint health --write-out=table

Đảm bảo tất cả các node đều báo trạng thái healthy trước khi chuyển sang bước tiếp theo.

Bước 2: Cài đặt PostgreSQL và Patroni

Lưu ý quan trọng: Khác với quy trình thông thường, bạn không được khởi tạo cơ sở dữ liệu PostgreSQL bằng lệnh initdb thủ công. Hãy để Patroni đảm nhận việc này.

Cài đặt PostgreSQL (phiên bản 15 hoặc 16) trên cả 3 node nhưng tắt dịch vụ tự khởi động (disable postgresql service).
Cài đặt Patroni thông qua trình quản lý gói pip hoặc kho lưu trữ của hệ điều hành.
Cấu hình tệp /etc/patroni/patroni.yml trên từng node. Tệp cấu hình này sẽ định nghĩa kết nối tới DCS (Etcd), thư mục lưu trữ dữ liệu của Postgres, và các thông số replication.

Khi khởi động dịch vụ Patroni trên Node 1, nó sẽ nhận diện chưa có nút Primary nào và tự động khởi tạo database. Khi khởi động Patroni trên Node 2 và Node 3, chúng sẽ tự động kết nối với nút Primary và tiến hành đồng bộ dữ liệu ban đầu (cloning) thông qua pg_basebackup.

Bước 3: Cấu hình điều phối kết nối với PgBouncer

Nếu ứng dụng kết nối trực tiếp đến IP của Node 1, khi Node 1 bị sập, ứng dụng sẽ bị lỗi dù Patroni đã chuyển quyền Primary sang Node 2. Do đó, ta cần PgBouncer làm lớp đệm trung gian.PgBouncer sẽ kết hợp với một kịch bản kiểm tra (health check script) do Patroni cung cấp (thường gọi là Patroni REST API qua cổng 8008). Kịch bản này sẽ liên tục kiểm tra xem node nào đang giữ vai trò Primary. Khi có sự cố failover xảy ra, PgBouncer sẽ tự động định tuyến lại toàn bộ các truy vấn ghi (write queries) sang node mới một cách mượt mà, giúp ứng dụng không bị gián đoạn kết nối.

4. Kiểm thử tính năng tự động Failover (Mô phỏng sự cố)

Để đảm bảo hệ thống HA hoạt động đúng như kỳ vọng, việc kiểm thử là không thể bỏ qua. Chúng ta có thể thực hiện một bài kiểm tra tắt nguồn đột ngột nút Primary hiện tại.

Sử dụng công cụ quản trị của Patroni để theo dõi trạng thái cụm:

patronictl -c /etc/patroni/patroni.yml list

Tiến hành stop dịch vụ Patroni hoặc tắt nguồn Cloud Server đang đóng vai trò Primary. Ngay lập tức, bạn sẽ quan sát thấy:

Etcd phát hiện nút Primary bị mất liên lạc (heartbeat timeout).
Patroni trên hai nút còn lại sẽ tiến hành bầu cử.
Nút Standby có độ trễ dữ liệu thấp nhất sẽ được thăng cấp (promoted) lên làm Primary mới.
PgBouncer cập nhật cấu hình và chuyển hướng traffic của ứng dụng sang nút Primary mới này trong vòng vài giây.

5. Những lưu ý quan trọng khi vận hành hệ thống HA trong môi trường sản xuất

Mặc dù Patroni và PgBouncer giúp tự động hóa phần lớn quy trình, doanh nghiệp vẫn cần tuân thủ các nguyên tắc vận hành sau để đảm bảo an toàn tuyệt đối:

Giám sát chặt chẽ (Monitoring): Hãy tích hợp hệ thống giám sát như Prometheus và Grafana để theo dõi các chỉ số quan trọng như: độ trễ đồng bộ (replication lag), dung lượng ổ đĩa, số lượng kết nối trong PgBouncer, và trạng thái của cụm Etcd.

Chiến lược Sao lưu (Backup): Tính sẵn sàng cao (HA) không thay thế được sao lưu dữ liệu (Backup). Hãy thiết lập công cụ sao lưu liên tục như pgBackRest hoặc Barman để đề phòng các trường hợp lỗi logic (như xóa nhầm dữ liệu) mà cơ chế replication không thể cứu vãn.

Bảo trì định kỳ: Khi cần cập nhật hệ điều hành hoặc nâng cấp phiên bản PostgreSQL, hãy tận dụng tính năng pause của Patroni để tạm dừng cơ chế tự động failover, giúp kỹ sư hệ thống chủ động bảo trì từng node một mà không gây gián đoạn dịch vụ.

6. Lời kết

Xây dựng hệ thống PostgreSQL High Availability vững chắc với Patroni và PgBouncer trên 3 Cloud Server là một giải pháp đầu tư xứng đáng cho bất kỳ doanh nghiệp nào coi trọng tính toàn vẹn và sẵn sàng của dữ liệu. Hy vọng bài viết này đã cung cấp cho bạn một cái nhìn tổng quan và các bước triển khai thực tế rõ ràng để áp dụng thành công vào hệ thống của mình.

Hướng Dẫn Cấu Hình PostgreSQL High Availability (HA) Với Patroni Và PgBouncer Trên 3 Cloud Server