Giới thiệu Tính năng Tự Sao lưu Dự phòng (Streaming Replication) tích hợp trong PostgreSQL 9.0+

Tính năng sao lưu dự phòng tự động một chiều Master->Slave (thuật ngữ tiêng Anh: Streaming Replication) trên PostgreSQL được giới thiệu lần đầu tiên ở phiên bản PostgreSQL 9.0.

Ở phiên bản 9.0, tính năng tự động sao lưu dự phòng mới chỉ hỗ trợ phương pháp Asynchronous Replication, có nghĩa là một transaction gửi đến Server chính (Master) được thực hiện và xác nhận hoàn thành với client ngay khi hoàn thành mà không cần quan tâm đến việc bản sao lưu của transaction này đã được hoàn thành ở server dự phòng (slave) hay chưa.

Sang phiên bản 9.1 (phiên bản chính thức đi kèm với Ubuntu 12.04), tính năng tự động sao lưu dự phòng được bổ sung thêm một phương pháp nữa, đó là Synchronous Replication. Phương pháp này hoạt đồng tương tự như Asynchronous Replication, chỉ khác duy nhất là Master sẽ đợi cho Slave xác nhận đã sao lưu xong, sau đó mới "trả lời" client.

Qua đó ta thấy, nếu xét về khía cạnh toàn vẹn dữ liệu thì phương pháp Synchronous Replication hoàn hảo hơn Asynchronous Replication. Nhưng cái giá phải trả cho việc này chính là hiệu năng hoạt động và tốc độ đáp ứng client bị giảm đáng kể. Giảm bao nhiêu thì phụ thuộc vào hiệu năng của Slave.

Phiên bản PostgreSQL mới nhất tại thời điểm viết bải này là 9.2. Ở phiên bản này, tính năng tự động sao lưu dự phòng được bổ sung thêm một khả năng mới: Cascade Streaming Replication. Tính năng này thực tế là vô dụng nếu mô hình tự động sao lưu dự phòng chỉ với một Master và một Slave. Tuy nhiên, đôi với một PostgreSQL farm gồm một Master và nhiều Slave, tính năng này tỏ ra vô cùng quý giá và hữu ích.

Để hiểu rõ hơn về Cascade Streaming Replication, ta hãy xem xét hai mô hình kết nối dưới đây

• Ở PostgreSQL phiên bản 9.0+ với tính năng streaming replication:

Trong mô hình này, ứng dụng và client truy xuất và tương tác (đọc/ghi) dữ liệu với Master. Master sẽ chịu trách nhiệm "giao tiếp" với Slave 01 và Slave 02 để tạo các bản sao lưu dự phòng trên Slave 01 và Slave 02. Như vậy, nếu số Slave càng lớn thì nhiệm vụ của Master càng nặng nề và dễ dẫn đến quá tải ở Master, đặc biệt là nếu áp dụng Synchronous Streaming Replication thì tốc độ đáp ứng của Master với Client sẽ rất thấp.

• Ở PostgreSQL phiên bản 9.2.x với tính năng Cascade Streaming Replication, mô hình kết nối như sau:

Rõ ràng, ở mô hình này với tính năng Cascade Streaming Replication, Master đã được giảm tải và nó chỉ phải làm việc với Slave 01. Việc tự động sao lưu dự phòng sang Slave 02 đã được chuyển giao cho Slave 01. Và cứ như thế nếu chúng ta có nhiều hơn 2 slave.

Kết luận:

Đến đây, chúng ta đã nắm được một số khái niệm cơ bản nhất về Streaming Replication trong PostgreSQL 9.0; 9.1; 9.2. Việc áp dụng mô hình nào hoặc áp dụng tổ hợp nhiều mô hình và phương thức sẽ do bạn lựa chọn sao cho phù hợp với đặc thù của Doanh nghiệp mình. Ví dụ, với những giao dịch quan trọng như tài chính, có lẽ bạn sẽ muốn áp dụng Synchronous Streaming Replication để đảm bảo tính toàn vẹn dữ liệu giữa Master và (các) Slave và chấp nhận đánh đổi hiệu năng & tốc độ đáp ứng của ưng dụng. Tuy nhiên, nếu hiệu năng & tốc độ đáp ứng là điều bạn quan tâm hơn cả thì có lẽ Asynchronous Streaming Replication là giải pháp phù hợp hơn. Nếu bạn có thể sử dụng PostgreSQL phiên bản 9.2 trở lên và bạn có nhiều hơn một Slave, hãy sử dụng mô hình Cascade  (đi kèm với Asynchronous hoặc Synchronous Streaming Replication). Dĩ nhiên, nếu bạn có một Master cực "khoẻ" và đang dư dả tài nguyên, trong khi các Slave có cấu hình thấp và luôn trong tình trạng hết tài nguyên thì việc không lựa chọn mô hình Cascade sẽ là một lựa chọn đúng đắn.

Chúc bạn lựa chọn cho mình được một giải pháp phù hợp nhất! Nếu bạn muốn thực hành ngay, hãy xem Cấu hình Tự sao lưu dự phòng (Asynchronous/Synchronous Streaming Replication) trong PostgreSQL 9.0 +

Hoan nghênh mọi ý kiến đóng góp & bình luận để bài viết này trở nên tốt hơn và hữu ích hơn.