- Streaming Replication của PostgreSQL là một cách hiệu quả để duy trì một hoặc nhiều bản sao gần như theo thời gian thực của DB chính trên các máy chủ standby
- Máy chủ chính liên tục truyền các bản ghi Write-Ahead Log (WAL) tới máy chủ standby ngay khi chúng được tạo ra, giúp giảm thiểu độ trễ trong quá trình sao chép
- Được thiết kế để cải thiện tính sẵn sàng cao và khả năng mở rộng, cho phép offload các truy vấn đọc sang máy chủ standby để giảm tải cho máy chủ chính
- Hỗ trợ cả chế độ đồng bộ và bất đồng bộ, cho phép linh hoạt cân bằng giữa tính nhất quán dữ liệu và hiệu năng
- Bao gồm quá trình máy chủ standby kết nối tới máy chủ chính để yêu cầu WAL streaming, sau đó áp dụng các bản ghi đã nhận vào bản sao DB của chính nó
- So với việc chuyển log dựa trên tệp, giải pháp này mang lại failover nhanh hơn và giảm rủi ro mất dữ liệu, rất phù hợp với các môi trường phân tán về mặt địa lý
Streaming Replication hoạt động như thế nào?
- Dữ liệu WAL được truyền liên tục theo thời gian thực từ máy chủ chính sang máy chủ standby, giúp DB trên standby luôn gần như đồng nhất với máy chủ chính
- Nhờ đó có thể sử dụng các bản sao cho failover hoặc xử lý tác vụ đọc, giúp hệ thống mở rộng quy mô lên nhiều lần
Tệp cấu hình PostgreSQL và vị trí
- Các tệp cấu hình PostgreSQL đóng vai trò quan trọng trong việc quản lý thiết lập và hành vi của máy chủ cơ sở dữ liệu.
postgresql.conf: Tệp cấu hình chính chứa hầu hết các thiết lập của máy chủ. Tùy hệ điều hành, tệp này có thể nằm ở nhiều vị trí khác nhau như /etc/postgresql/<version>/main/postgresql.conf (Debian/Ubuntu) hoặc /var/lib/pgsql/<version>/data/postgresql.conf (Red Hat/CentOS)pg_hba.conf: Kiểm soát xác thực client, định nghĩa cách client kết nối tới máy chủ. Thường nằm trong cùng thư mục với postgresql.confpg_ident.conf: Được dùng để ánh xạ tên người dùng nhưng ít được sử dụng hơnrecovery.conf: Được dùng để cấu hình máy chủ standby trong các phiên bản trước PostgreSQL 12, nhưng từ các phiên bản sau đó nội dung đã được chuyển sang postgresql.conf và postgresql.auto.conf
- Vị trí chính xác có thể khác nhau tùy theo hệ điều hành, phương thức cài đặt và phiên bản PostgreSQL
- Có thể dùng câu lệnh SQL
SHOW config_file; để tìm vị trí các tệp này từ bên trong instance PostgreSQL
Ví dụ và cấu trúc WAL (Write Ahead Logs)
- Có thể xem WAL bằng lệnh
pg_waldump
- Mỗi dòng đại diện cho một bản ghi WAL chứa thông tin về thao tác DB
- Các thành phần của mỗi bản ghi:
- rmgr: trình quản lý tài nguyên (ví dụ: Heap, Btree, Transaction)
- len: độ dài bản ghi
- tx: ID giao dịch
- lsn: số thứ tự log
- prev: LSN trước đó
- desc: mô tả thao tác
- Các loại thao tác có thể thấy:
- thao tác INSERT (Heap và Btree)
- thao tác MULTI_INSERT (Heap2)
- giao dịch COMMIT
- thao tác tệp (CREATE)
- Full Page Writes (FPW)
- Đầu ra WAL cho thấy chi tiết luồng giao dịch, thay đổi dữ liệu và hoạt động hệ thống, rất hữu ích cho việc phân tích hành vi DB, xử lý sự cố và khôi phục theo thời điểm
Cách làm việc với Docker
- Các thiết lập quan trọng liên quan đến Streaming Replication trong
postgresql.conf:
- wal_level, max_wal_senders, max_replication_slots, hot_standby, v.v.
- Những thành phần cần có cho ví dụ Docker Compose:
init-master.sh: Thiết lập PostgreSQL master cho mục đích sao chép. Tạo người dùng replication và slot, cập nhật các thiết lập liên quan đến WALinit-replica.sh: Chuẩn bị replica PostgreSQL để kết nối tới master và bắt đầu sao chép. Chờ cho tới khi master sẵn sàng, sau đó thực hiện bản sao lưu cơ sở và cấu hình replicastart-replica.sh: Khởi động replica PostgreSQL trong container Docker. Chạy script init-replica.sh rồi khởi động PostgreSQLdocker-compose.yml: Định nghĩa các service master và replica, đồng thời thiết lập các biến môi trường, volume, lệnh cần thiết, v.v.
- Sau khi cấp quyền thực thi cho các script, chạy
docker-compose up -d để khởi động master và replica
- Có thể kết nối tới master và kiểm tra trạng thái sao chép bằng
pg_stat_replication
- Có thể kết nối tới replica và kiểm tra có đang ở chế độ khôi phục hay không bằng
pg_is_in_recovery()
Ý kiến của GN⁺
- Streaming Replication có thể cải thiện đáng kể hiệu năng và khả năng phục hồi của hạ tầng cơ sở dữ liệu. Dù để chuẩn bị cho kịch bản failover hay phân tán tải đọc sang replica, cơ chế này đều giúp DB mở rộng tốt hơn và duy trì hiệu năng ổn định
- Việc trình bày toàn bộ quy trình cấu hình và đầu ra là rất quan trọng. Nó mang lại góc nhìn tổng thể về nhiều thành phần liên quan và giúp hiểu rõ hơn điều gì đang diễn ra
- Hiểu cách Streaming Replication hoạt động và cấu hình nó đúng cách là rất quan trọng. Hy vọng bài viết này đã làm rõ quy trình và mang lại cái nhìn sâu hơn về cách replication vận hành
- Những sản phẩm hoặc dự án khác có chức năng tương tự gồm có Replication của MySQL hoặc Data Guard của Oracle. Các giải pháp này cũng hoạt động bằng cách truyền các thay đổi từ master sang replica, nhưng chi tiết triển khai có thể khác nhau
- Khi sử dụng Streaming Replication, cần cân nhắc băng thông mạng và độ trễ. Việc truyền dữ liệu giữa master và replica có thể tiêu tốn đáng kể tài nguyên mạng. Khả năng mở rộng số lượng replica cũng là một yếu tố quan trọng
- Cần đánh giá cả yêu cầu về tính nhất quán dữ liệu. Replication đồng bộ có thể ảnh hưởng đến hiệu năng ghi nhưng cung cấp tính nhất quán mạnh hơn. Replication bất đồng bộ cho hiệu năng tốt hơn nhưng có một chút khả năng mất dữ liệu
1 bình luận
Ý kiến trên Hacker News
Có ý kiến cho rằng bài viết này rất hay, nhưng từ góc nhìn của một lập trình viên full-stack muốn tự quản lý cơ sở dữ liệu thì vẫn thiếu các trường hợp áp dụng thực tế
Có ý kiến cho rằng giải pháp dễ nhất cho replication của PostgreSQL là Kubernetes operator
Một trong những lý do để dùng Kubernetes và Helm là vì có thể giải quyết vấn đề này
Khuyến nghị StackGres cho người dùng Kubernetes
Cuối cùng, có ý kiến hoài nghi rằng bài viết này có vẻ được viết bởi AI