Quản lý tính khả dụng cao trong PostgreSQL - Phần II:Trình quản lý nhân bản

Bạn đang triển khai PostgreSQL trên đám mây và muốn hiểu các tùy chọn của mình để đạt được tính khả dụng cao? Trong bài đăng trên blog trước của chúng tôi, Quản lý tính khả dụng cao trong PostgreSQL - Phần I, chúng tôi đã thảo luận về các khả năng và hoạt động của Chuyển đổi dự phòng tự động PostgreSQL (PAF) của ClusterLabs. Trong Phần II, chúng tôi sẽ giới thiệu cho bạn một công cụ mã nguồn mở thay thế, Replication Manager từ 2ndQuadrant, sẽ được tiếp nối chặt chẽ bởi Phần III, nơi chúng tôi đi sâu vào giải pháp thay thế thứ ba, Patroni của Zalando.

Quản lý tính khả dụng cao trong PostgreSQL - Phần I:Chuyển đổi dự phòng tự động PostgreSQL
Quản lý tính khả dụng cao trong PostgreSQL - Phần III:Patroni

Trình quản lý nhân bản (repmgr)

repmgr là bộ công cụ mã nguồn mở được phát triển bởi 2ndQuadrant để quản lý sao chép và chuyển đổi dự phòng các cụm PostgreSQL của bạn. Nó cung cấp các công cụ để thiết lập, cấu hình, quản lý và giám sát việc nhân bản PostgreSQL, đồng thời cho phép bạn thực hiện các tác vụ chuyển đổi thủ công và chuyển đổi dự phòng bằng tiện ích repmgr. Công cụ miễn phí này hỗ trợ và nâng cao tính năng sao chép phát trực tuyến tích hợp sẵn của PostgreSQL.

Replication Manager cung cấp hai công cụ chính để quản lý việc nhân rộng và chuyển đổi dự phòng của PostgreSQL.

repmgr

Tiện ích giao diện dòng lệnh cho phép bạn thực hiện các tác vụ quản trị khác nhau.
repmgr cho phép bạn thiết lập máy chủ dự phòng, thúc đẩy chế độ chờ, thực hiện chuyển đổi và theo dõi trạng thái của cụm PostgreSQL của bạn.
Nó cũng cung cấp tùy chọn chạy nhanh cho hầu hết các lệnh quản trị.

repmgrd

Đây là daemon:

Chủ động giám sát các cụm PostgreSQL và thực hiện các hành động cần thiết dựa trên trạng thái của cụm.
Thực hiện chuyển đổi dự phòng tự động trong trường hợp nút chính gặp sự cố bằng cách đặt chế độ chờ đủ điều kiện nhất làm nút chính mới.
Cung cấp tùy chọn để theo dõi và lưu trữ dữ liệu liên quan đến hiệu suất sao chép.
Cung cấp thông báo bằng cách gọi tập lệnh người dùng cho các sự kiện đã đăng ký.

Cách hoạt động

repmrg không chỉ quản lý việc nhân rộng các cụm PostgreSQL mà còn có khả năng thiết lập các máy chủ dự phòng để nhân rộng. Sau quá trình cài đặt ban đầu, chúng ta cần thực hiện các thay đổi đối với tệp cấu hình repmgr (repmgr.conf) với các chi tiết được yêu cầu trên mỗi máy chủ. Khi một máy chủ được cấu hình, nó cần được đăng ký với repmgr bằng lệnh đăng ký repmgr chính / dự phòng. Đầu tiên, nút chính được thiết lập và đăng ký. Sau đó, các máy chủ dự phòng được tạo và định cấu hình bằng lệnh sao chép dự phòng repmgr để sao chép nút dự phòng PostgreSQL từ một máy chủ PostgreSQL khác.

Replication Manager sử dụng tính năng mở rộng PostgreSQL và tạo lược đồ riêng trên cơ sở dữ liệu cụm để lưu trữ thông tin liên quan đến cụm. Việc cài đặt tiện ích mở rộng và tạo lược đồ diễn ra trong quá trình đăng ký máy chủ chính bằng cách sử dụng repmgr. Khi quá trình thiết lập hoàn tất, các thao tác quản trị thủ công như quảng bá, theo dõi, chuyển đổi, v.v. có thể được thực hiện bằng tiện ích repmgr. Đối với hoạt động chuyển đổi, nó yêu cầu thiết lập SSH không mật khẩu giữa các nút.

Có thể thiết lập chuyển đổi dự phòng tự động bằng cách sử dụng repmgrd. repmgrd yêu cầu một thư viện chia sẻ ‘repmgr’ được tải tại thời điểm khởi động máy chủ PostgreSQL. Tên thư viện phải được đề cập trong shared_preload_libraries tham số cấu hình trong tệp postgresql.conf. Ngoài ra, để repmgrd hoạt động, chuyển đổi dự phòng =tự động tham số cần được đặt trong tệp repmgr.conf. Khi tất cả các tham số này được thiết lập, daemon repmgrd bắt đầu tích cực giám sát cụm. Nếu có bất kỳ lỗi nào trong nút chính, nó sẽ cố gắng kết nối lại nhiều lần. Khi tất cả các nỗ lực kết nối với chế độ chính không thành công, chế độ chờ đủ điều kiện nhất sẽ được bầu chọn làm chế độ chờ chính mới theo repmgrd.

repmgr cũng hỗ trợ thông báo sự kiện. Nó có một tập hợp các sự kiện được xác định trước và lưu trữ từng lần xuất hiện của các sự kiện này trong bảng repmgr.events. repmgr cho phép thông báo sự kiện được chuyển đến một chương trình hoặc tập lệnh do người dùng xác định. Chương trình này có thể thực hiện thêm hành động, chẳng hạn như gửi email hoặc kích hoạt bất kỳ cảnh báo nào. Điều này được thực hiện bằng cách đặt event_notification_command tham số trong repmgr.conf.

Nó xử lý tình huống não bị chia rẽ như thế nào?

repmgr giải quyết các tình huống chia rẽ não bộ bằng cách sử dụng vị trí tham số, trong đó mỗi nút phải chỉ định tham số vị trí dựa trên trung tâm dữ liệu mà nó được đặt. Trong trường hợp bất kỳ sự phân chia mạng nào, repmgr sẽ đảm bảo quảng bá nút ở cùng vị trí với nút chính. Nếu nó không tìm thấy bất kỳ nút nào ở vị trí đó, nó sẽ không quảng bá bất kỳ nút nào ở bất kỳ vị trí nào.

Nó cũng xử lý sự cô lập mạng trong trường hợp có số lượng máy chủ chẵn trong một cụm. Điều này được thực hiện bằng cách sử dụng một nút bổ sung được gọi là máy chủ nhân chứng. Máy chủ nhân chứng là một nút chỉ được coi là dành cho đa số phiếu bầu. Sẽ không có cài đặt PostgreSQL trên máy chủ đó và do đó, không có phần nào để chơi trong quá trình nhân rộng.

Có Bất kỳ Yêu cầu Thiết lập nào không?

repmgr sẽ yêu cầu cơ sở dữ liệu chuyên dụng và người dùng có đặc quyền người dùng cấp cao. Tuy nhiên, cũng có một tùy chọn cung cấp superuser nếu bạn không muốn cấp quyền truy cập superuser cho người dùng repmgr.
Nếu bạn muốn repmgr sao chép các tệp cấu hình nằm bên ngoài thư mục dữ liệu PostgreSQL và / hoặc để kiểm tra chức năng chuyển đổi, bạn cũng sẽ cần kết nối SSH không mật khẩu giữa cả hai máy chủ và rsync nên được cài đặt.
Nếu bạn định sử dụng các lệnh dựa trên dịch vụ khác với pg_ctl (được sử dụng bởi repmgr theo mặc định) để bắt đầu, dừng, tải lại và khởi động lại, bạn có thể chỉ định chúng trong repmgr tệp cấu hình (repmgr.conf).

Các thông số cấu hình cơ bản được yêu cầu trong tệp cấu hình repmgr như sau:

node_id (int) - Một số nguyên duy nhất lớn hơn 0 xác định nút. node_name (string) - Nên sử dụng một chuỗi tùy ý (nhưng duy nhất), sử dụng tên máy chủ của máy chủ hoặc một số nhận dạng khác được liên kết rõ ràng với máy chủ để tránh nhầm lẫn.

conninfo (chuỗi) - Thông tin kết nối cơ sở dữ liệu dưới dạng chuỗi conninfo. Tất cả các máy chủ trong cụm phải có thể kết nối với nút cục bộ bằng chuỗi này.

data_directory (chuỗi) - Thư mục dữ liệu của nút. Điều này là cần thiết bởi repmgr để thực hiện các hoạt động khi phiên bản PostgreSQL không chạy và không có cách nào khác để xác định thư mục dữ liệu.

Repmgr Ưu điểm

Repmgr cung cấp các tiện ích giúp thiết lập các nút chính và nút dự phòng cũng như định cấu hình sao chép.
Nó không sử dụng thêm bất kỳ cổng nào để giao tiếp. Nếu bạn muốn thực hiện chuyển đổi, chỉ khi đó nó mới yêu cầu cấu hình SSH không mật khẩu.
Cung cấp thông báo bằng cách gọi các tập lệnh người dùng cho các sự kiện đã đăng ký.
Thực hiện chuyển đổi dự phòng tự động trong trường hợp máy chủ chính bị lỗi.

repmgr Nhược điểm

repmgr không phát hiện xem chế độ chờ có được định cấu hình sai với một nút không xác định hoặc không tồn tại trong cấu hình khôi phục hay không. Nút sẽ được hiển thị ở chế độ chờ ngay cả khi nó đang chạy mà không kết nối với nút chờ chính / xếp tầng.
Không thể truy xuất trạng thái của nút khác từ nút có dịch vụ PostgreSQL ngừng hoạt động. Do đó, nó không cung cấp giải pháp kiểm soát phân tán.
Nó không xử lý được việc khôi phục tình trạng của các nút riêng lẻ.

Quản lý tính khả dụng cao trong #PostgreSQL - Phần II:Công cụ repmgr mã nguồn mở Nhấp để đăng

Tình huống kiểm tra tính khả dụng cao

Chúng tôi đã tiến hành một vài thử nghiệm về quản lý tính khả dụng cao của PostgreSQL bằng cách sử dụng repmgr. Tất cả các bài kiểm tra này đều được chạy trong khi ứng dụng đang chạy và chèn dữ liệu vào cơ sở dữ liệu PostgreSQL. Ứng dụng được viết bằng Trình điều khiển Java JDBC của PostgreSQL tận dụng khả năng chuyển đổi dự phòng kết nối.

Kiểm tra máy chủ ở chế độ chờ

Sl. Không	Tình huống thử nghiệm	Quan sát
1	Hủy quy trình PostgreSQL	Máy chủ chờ được đánh dấu là không thành công. Không có sự gián đoạn trong ứng dụng của nhà văn. Cần có sự can thiệp thủ công để bắt đầu lại quy trình PostgreSQL.
2	Dừng quá trình PostgreSQL	Máy chủ chờ được đánh dấu là không thành công. Không có sự gián đoạn trong ứng dụng của nhà văn. Cần có sự can thiệp thủ công để bắt đầu lại quy trình PostgreSQL.
3	Khởi động lại máy chủ	Máy chủ chờ được đánh dấu là không thành công. Khi máy chủ xuất hiện sau khi khởi động lại, PostgreSQL được khởi động theo cách thủ công và máy chủ được đánh dấu là đang chạy. Không có sự gián đoạn trong ứng dụng của người viết.
4	Dừng quá trình repmgrd	Máy chủ dự phòng sẽ không nằm trong tình huống chuyển đổi dự phòng tự động. Dịch vụ PostgreSQL được phát hiện đang chạy. Không có sự gián đoạn trong ứng dụng của người viết.

Kiểm tra Máy chủ Chính / Chính

Sl. Không	Tình huống thử nghiệm	Quan sát
1	Hủy quy trình PostgreSQL	repmgrd đã bắt đầu kiểm tra tình trạng kết nối máy chủ chính trên tất cả các máy chủ dự phòng trong một khoảng thời gian cố định. Khi tất cả các lần thử lại không thành công, một cuộc bầu cử đã được kích hoạt trên tất cả các máy chủ dự phòng. Kết quả của cuộc bầu chọn, chế độ chờ có LSN nhận được mới nhất đã được thăng hạng. Máy chủ dự phòng bị thua cuộc bầu cử sẽ đợi thông báo từ nút chính mới và theo dõi sau khi họ nhận được thông báo. Có thời gian ngừng hoạt động trong ứng dụng người viết. Cần có sự can thiệp thủ công để bắt đầu lại quy trình PostgreSQL.
2	Stop the PostgreSQL process and bring it back immediately after health check expiry	repmgrd started the health check for the primary server connection on all standby servers for a fixed interval. When all retries failed, an election was triggered on all the standby nodes. However, the newly elected master didn’t notify the existing standby servers since the old master was back. Cluster was left in an indeterminate state and manual intervention was required.
3	Reboot the server	repmgrd started the election when master connection health check failed on all standby servers. The eligible standby was promoted. When this server came back, it didn’t join the cluster and was marked failed. repmgr node rejoin command was ran to add the server back to the cluster. There was downtime in the writer application.
4	Stop the repmgr process	The primary server will not be a part of the automated failover situation. PostgreSQL service was found to be running. There was no disruption in the writer application.

Network Isolation Tests

Sl. No	Test Scenario	Observation
1	Network isolate the primary server from other servers (all have same value for location in repmgr configuration)	repmgrd started the election when master connection health check failed on all standby servers. The eligible standby was promoted, but the PostgreSQL process was still running on the old master node. There were two nodes running as master. Manual intervention was required after the network isolation was corrected.
2	Network isolate the primary server from other servers (the standby servers has same value for location but primary had a different value for location in repmgr configuration)	repmgrd started the election when master connection health check failed on all standby servers. But, there was no new master elected since the standby servers had a location different from that of the primary. repmgrd went into degrade monitoring mode. PostgreSQL was running on all the nodes and there was only one master in the cluster.

Inference

repmgr provides several commands to setup and monitor PostgreSQL replication. It is feature-rich and also eases the job of the database administrator (DBA). However, it’s not a full fledged high availability management tool since it will not manage the resources. Manual intervention is required to ensure the resource is in proper state.

So, in this post, we’ve discussed the capabilities and workings of Replication Manager by 2ndQuadrant. In our next post, we’ll discuss the same high availability aspects using Patroni by Zalando. For users looking to automate their high availability in the cloud, check out our PostgreSQL on Azure and PostgreSQL on AWS fully managed solutions.