Tính khả dụng cao của PostgreSQL với các kiến ​​trúc Master-Slave &Master-Master

Dưới đây là một đoạn trích từ sách trắng của chúng tôi “Quản lý và tự động hóa PostgreSQL với ClusterControl” có thể được tải xuống miễn phí.

Lưu ý sửa đổi:Hãy nhớ rằng các thuật ngữ được sử dụng trong blog Master-Slave này đồng nghĩa với các thuật ngữ Master-Standby được PostgreSQL sử dụng. Chúng tôi đang sử dụng Master-Slave để duy trì sự song song với các công nghệ khác.

Đối với cấu hình HA, chúng ta có thể có một số kiến ​​trúc, nhưng những kiến ​​trúc cơ bản sẽ là kiến ​​trúc master-slave và master-master. ), hoặc cho phép một số máy tính cung cấp cùng một dữ liệu (cân bằng tải).

Kiến trúc Master-Slave của PostgreSQL

Những kiến ​​trúc này cho phép chúng tôi duy trì một cơ sở dữ liệu chính với một hoặc nhiều máy chủ dự phòng sẵn sàng tiếp quản các hoạt động nếu máy chủ chính bị lỗi. Các cơ sở dữ liệu dự phòng này sẽ vẫn được đồng bộ hóa (hoặc gần như đồng bộ hóa) với cơ sở dữ liệu chính.

Việc sao chép giữa chủ và các nô lệ có thể được thực hiện thông qua các câu lệnh SQL (các lệnh chờ lôgic) hoặc thông qua các sửa đổi cấu trúc dữ liệu bên trong (các lệnh chờ vật lý). PostgreSQL sử dụng luồng bản ghi ghi nhật ký trước (WAL) để giữ cho cơ sở dữ liệu dự phòng được đồng bộ hóa. Nếu máy chủ chính bị lỗi, chế độ chờ sẽ chứa gần như toàn bộ dữ liệu của máy chủ chính và có thể nhanh chóng làm máy chủ cơ sở dữ liệu chính mới. Điều này có thể đồng bộ hoặc không đồng bộ và chỉ có thể được thực hiện cho toàn bộ Máy chủ cơ sở dữ liệu.

Thiết lập tính năng sao chép trực tuyến là một công việc đòi hỏi một số bước phải được tuân thủ kỹ lưỡng. Để biết các bước đó và một số thông tin cơ bản khác về chủ đề này, vui lòng xem:Trở thành DBA PostgreSQL - Cách thiết lập tính năng nhân rộng luồng để có tính khả dụng cao.

Từ phiên bản 10, PostgreSQL bao gồm tùy chọn để thiết lập bản sao lôgic.

Sao chép lôgic cho phép một máy chủ cơ sở dữ liệu gửi một luồng sửa đổi dữ liệu đến một máy chủ khác. Bản sao lôgic PostgreSQL xây dựng một luồng sửa đổi dữ liệu lôgic từ WAL. Sao chép logic cho phép sao chép các thay đổi dữ liệu từ các bảng riêng lẻ. Nó không yêu cầu một máy chủ cụ thể được chỉ định là một máy chủ hay một bản sao nhưng cho phép dữ liệu truyền theo nhiều hướng.

Bạn có thể tìm thêm thông tin về sao chép lôgic:Blog:Tổng quan về sao chép lôgic trong PostgreSQL.

Để đảm bảo tính khả dụng cao một cách hiệu quả, chỉ cần có kiến ​​trúc chủ-tớ là chưa đủ. Chúng tôi cũng cần kích hoạt một số hình thức chuyển đổi dự phòng tự động, vì vậy nếu có sự cố nào đó, chúng tôi có thể có độ trễ nhỏ nhất có thể trong việc tiếp tục chức năng bình thường. PostgreSQL không bao gồm cơ chế chuyển đổi dự phòng tự động để xác định lỗi trên cơ sở dữ liệu chính và thông báo cho người cứu lấy quyền sở hữu, do đó, điều đó sẽ yêu cầu một chút công việc từ phía DBA. Bạn nên làm việc trên một tập lệnh bao gồm lệnh thúc đẩy pg_ctl, lệnh này sẽ thăng cấp nô lệ như một chủ mới. Ngoài ra còn có một số công cụ của bên thứ ba để tự động hóa này. Nhiều công cụ như vậy tồn tại và được tích hợp tốt với các cơ sở hệ điều hành cần thiết để chuyển đổi dự phòng thành công, chẳng hạn như Di chuyển địa chỉ IP.

Sau khi chuyển đổi dự phòng xảy ra, bạn cần phải sửa đổi ứng dụng của mình cho phù hợp để làm việc với bản chính mới. Bạn cũng sẽ chỉ có một máy chủ hoạt động, vì vậy cần phải tạo lại kiến ​​trúc master-slave để chúng ta quay lại tình trạng bình thường như trước khi sự cố.

Kiến trúc Master-Master PostgreSQL

Kiến trúc này cung cấp một cách giảm thiểu tác động của lỗi ở một trong các nút, vì nút kia có thể đảm nhận tất cả lưu lượng truy cập, có thể ảnh hưởng một chút đến hiệu suất, nhưng không bao giờ mất chức năng. Nó cũng được sử dụng để thực hiện (và có thể đây còn là một điểm thú vị hơn) khả năng mở rộng theo chiều ngang (scale-out), đối lập với khái niệm về khả năng mở rộng theo chiều dọc, nơi chúng tôi thêm nhiều tài nguyên hơn vào máy chủ (scale-up).

Để triển khai kiến ​​trúc này, bạn sẽ cần sử dụng các công cụ bên ngoài, vì tính năng này chưa (chưa) được hỗ trợ bởi PostgreSQL.

Bạn phải rất cẩn thận khi lựa chọn giải pháp thực hiện chế độ tổng thể, vì có rất nhiều sản phẩm khác nhau. Nhiều người trong số họ vẫn ở trạng thái "xanh", với một số ít người dùng nghiêm túc hoặc trường hợp thành công. Mặt khác, một số dự án khác đã bị bỏ dở do không có người bảo trì tích cực.

Để biết thêm thông tin về các công cụ có sẵn, vui lòng tham khảo:Blog:Giải pháp HA phân cụm PG hàng đầu cho PostgreSQL.

Cân bằng tải và tổng hợp kết nối

Có một số công cụ cân bằng tải có thể được sử dụng để quản lý lưu lượng truy cập từ ứng dụng của bạn nhằm tận dụng tối đa kiến ​​trúc cơ sở dữ liệu của bạn. Theo cách tương tự, có một số cách khác có thể giúp bạn quản lý cách ứng dụng kết nối với cơ sở dữ liệu, bằng cách gộp các kết nối này và sử dụng lại chúng giữa các yêu cầu khác nhau.

Có một số sản phẩm được sử dụng cho cả hai mục đích, như pgpool nổi tiếng và một số sản phẩm khác sẽ chỉ tập trung vào một trong những tính năng này, như pgbouncer (kết nối tổng hợp) và HAProxy (được sử dụng để cân bằng tải).