PostgreSQL
 sql >> Cơ Sở Dữ Liệu >  >> RDS >> PostgreSQL

Quản lý tính khả dụng cao trong PostgreSQL - Phần III:Patroni

Trong các bài đăng trên blog trước đây của chúng tô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 Cluster Labs và Replication Manager (repmgr) của 2ndQuadrant. Trong bài cuối cùng của loạt bài này, chúng tôi sẽ xem xét giải pháp cuối cùng, Patroni của Zalando và so sánh cả ba ở cuối để bạn có thể xác định khung khả dụng cao nào là tốt nhất cho việc triển khai lưu trữ PostgreSQL của mình.

  • 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 II:Trình quản lý nhân rộng

Patroni cho PostgreSQL

Patroni có nguồn gốc là ngã ba của Thống đốc, một dự án từ Compose. Nó là một bộ công cụ mã nguồn mở, được viết bằng Python, để quản lý tính khả dụng cao của các cụm PostgreSQL. Thay vì xây dựng giao thức nhất quán của riêng mình, Patroni tận dụng một cách thông minh mô hình nhất quán do Cửa hàng cấu hình phân tán (DCS) cung cấp. Nó cũng hỗ trợ các giải pháp DCS khác như Zookeeper, etcd, Consul và Kubernetes.

Patroni đảm bảo thiết lập end-to-end của các cụm HA PostgreSQL, bao gồm sao chép trực tuyến. Nó hỗ trợ nhiều cách khác nhau để tạo nút chờ và hoạt động giống như một mẫu có thể được tùy chỉnh theo nhu cầu của bạn.

Công cụ giàu tính năng này thể hiện chức năng của nó thông qua API REST và cũng thông qua tiện ích dòng lệnh có tên patronictl. Nó hỗ trợ tích hợp với HAProxy bằng cách sử dụng các API kiểm tra tình trạng của nó để xử lý cân bằng tải.

Patroni cũng hỗ trợ thông báo sự kiện với sự trợ giúp của các lệnh gọi lại, là các tập lệnh được kích hoạt bởi các hành động nhất định. Nó cho phép người dùng thực hiện bất kỳ hành động bảo trì nào bằng cách cung cấp chức năng tạm dừng / tiếp tục. Tính năng hỗ trợ Cơ quan giám sát làm cho khung công tác trở nên mạnh mẽ hơn.

Cách hoạt động

Ban đầu, cần cài đặt mã nhị phân PostgreSQL và Patroni. Sau khi hoàn tất, bạn cũng cần thiết lập cấu hình HA DCS. Tất cả các cấu hình cần thiết để khởi động cụm cần được chỉ định trong tệp cấu hình yaml và Patroni sẽ sử dụng tệp này để khởi tạo. Trên nút đầu tiên, Patroni khởi tạo cơ sở dữ liệu, lấy khóa lãnh đạo từ DCS và đảm bảo nút đang được chạy với tư cách là nút chính.

Bước tiếp theo là thêm các nút chờ để Patroni cung cấp nhiều tùy chọn. Theo mặc định, Patroni sử dụng pg_basebackup để tạo nút dự phòng và cũng hỗ trợ các phương thức tùy chỉnh như WAL-E, pgBackRest, Barman và các phương thức khác để tạo nút dự phòng. Patroni làm cho việc thêm một nút chờ rất đơn giản và xử lý tất cả các tác vụ khởi động và thiết lập bản sao phát trực tuyến của bạn.

Quản lý tính khả dụng cao trong #PostgreSQL - Phần III:Patroni so với PAF so với repmgrNhấp vào Tweet

Sau khi thiết lập cụm của bạn hoàn tất, Patroni sẽ chủ động giám sát cụm và đảm bảo cụm ở trạng thái khỏe mạnh. Nút chính đổi mới khóa đầu sau mỗi giây (mặc định:30 giây). Khi nút chính không thể gia hạn khóa lãnh đạo, Patroni sẽ kích hoạt một cuộc bầu cử và nút sẽ có được khóa lãnh đạo sẽ được bầu làm nút chính mới.

Nó xử lý tình huống phân tách não như thế nào?

Trong hệ thống phân tán, sự đồng thuận đóng một vai trò quan trọng trong việc xác định tính nhất quán và Patroni sử dụng DCS để đạt được sự đồng thuận. Chỉ nút giữ khóa lãnh đạo mới có thể là nút chính và khóa lãnh đạo có được thông qua DCS. Nếu nút chính không giữ khóa lãnh đạo, thì nó sẽ bị Patroni hạ cấp ngay lập tức để chạy ở chế độ chờ. Bằng cách này, tại bất kỳ thời điểm nào, chỉ có thể có một trang cái đang chạy trong hệ thống.

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

  • Patroni cần python 2.7 trở lên.
  • DCS và mô-đun python cụ thể của nó phải được cài đặt. Đối với mục đích thử nghiệm, DCS có thể được cài đặt trên cùng các nút đang chạy PostgreSQL. Tuy nhiên, trong quá trình sản xuất, DCS phải được cài đặt trên các nút riêng biệt.
  • Tệp cấu hình yaml phải có bằng cách sử dụng các cài đặt cấu hình cấp cao sau:

    Toàn cầu / Toàn cầu
    Điều này bao gồm cấu hình như tên của máy chủ (tên) cần phải là duy nhất cho cụm, tên của cụm (phạm vi) và đường dẫn để lưu trữ cấu hình trong DCS (không gian tên).

    Nhật ký Các cài đặt nhật ký cụ thể của
    Patroni bao gồm cấp độ, định dạng, tệp_num, tệp_kích_số, v.v.

    Cấu hình Bootstrap
    Đây là cấu hình chung cho một cụm sẽ được ghi vào DCS. Các tham số cấu hình này có thể được thay đổi với sự trợ giúp của API Patroni hoặc trực tiếp trong DCS. , chế độ đồng bộ, v.v. Phần này sẽ được viết vào / / / config của một kho lưu trữ cấu hình nhất định sau khi khởi tạo cụm mới.

    PostgreSQL
    Phần này chứa các tham số dành riêng cho PostgreSQL như xác thực, đường dẫn thư mục cho dữ liệu, nhị phân và cấu hình, địa chỉ ip lắng nghe, v.v.

    API REST
    Phần này bao gồm cấu hình cụ thể của Patroni liên quan đến REST API, chẳng hạn như địa chỉ lắng nghe, xác thực, SSL, v.v.

    Lãnh sự Các cài đặt
    dành riêng cho Lãnh sự DCS.

    v.v Các cài đặt
    dành riêng cho Etcd DCS.

    Nhà triển lãm Cài đặt
    dành riêng cho Nhà triển lãm DCS.

    Kubernetes Các cài đặt
    dành riêng cho Kubernetes DCS.

    ZooKeeper Các cài đặt
    dành riêng cho ZooKeeper DCS.

    Cơ quan giám sát Cài đặt
    dành riêng cho Cơ quan giám sát.

Chuyên gia Patroni

  • Patroni cho phép thiết lập end-to-end của cụm.
  • Hỗ trợ API REST và tích hợp HAproxy.
  • Hỗ trợ thông báo sự kiện thông qua các tập lệnh gọi lại được kích hoạt bởi các hành động nhất định.
  • Tận dụng DCS để có sự đồng thuận.

Patroni Cons

  • Patroni sẽ không phát hiện ra cấu hình sai của chế độ chờ 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. Nút sẽ được hiển thị dưới dạng nút phụ ngay cả khi chế độ chờ đang chạy mà không kết nối với nút dự phòng chính / xếp tầng.
  • Người dùng cần xử lý quá trình thiết lập, quản lý và nâng cấp phần mềm DCS.
  • Yêu cầu mở nhiều cổng để giao tiếp các thành phần:
    • Cổng REST API cho Patroni
    • Tối thiểu 2 cổng cho DCS

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ý PostgreSQL HA bằng Patroni. Tất cả các bài kiểm tra này được thực hiện 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 Patroni đã đưa quy trình PostgreSQL trở lại trạng thái đang chạy.

  • Không có sự gián đoạn ứng dụng của người viết.
2 Dừng quá trình PostgreSQL Patroni đã đưa quy trình PostgreSQL trở lại trạng thái đang chạy.

  • Không có sự gián đoạn ứng dụng của người viết.
3 Khởi động lại máy chủ Patroni cần được khởi động sau khi khởi động lại, trừ khi được định cấu hình để không bắt đầu khi khởi động lại. Khi Patroni được khởi động, nó bắt đầu quá trình PostgreSQL và thiết lập cấu hình chờ.

  • Không có sự gián đoạn ứng dụng của người viết.
4 Dừng quy trình Patroni
  • Nó không dừng quá trình PostgreSQL.
  • danh sách bảo trợ không hiển thị máy chủ này.
  • Không có sự gián đoạn ứng dụng của người viết.

Vì vậy, về cơ bản, bạn cần phải theo dõi tình trạng của quá trình Patroni - nếu không, nó sẽ dẫn đến các vấn đề không hoạt động.

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 Patroni đã đưa quy trình PostgreSQL trở lại trạng thái đang chạy. Patroni đang chạy trên nút đó có khóa chính và do đó, cuộc bầu cử đã không được kích hoạt.

  • Có thời gian ngừng hoạt động trong ứng dụng nhà văn.
2 Dừng quá trình PostgreSQL và khôi phục lại ngay sau khi hết hạn kiểm tra sức khỏe Patroni đã đưa quy trình PostgreSQL trở lại trạng thái đang chạy. Patroni đang chạy trên nút đó có khóa chính và do đó, cuộc bầu cử đã không được kích hoạt.

  • Có thời gian ngừng hoạt động trong ứng dụng nhà văn.
3 Khởi động lại máy chủ Đã xảy ra chuyển đổi dự phòng và một trong các máy chủ dự phòng đã được bầu làm máy chủ mới sau khi nhận được khóa. Khi Patroni được khởi động trên chủ cũ, nó đưa chủ cũ trở lại và thực hiện pg_rewind và bắt đầu theo dõi chủ mới.T

  • Có thời gian ngừng hoạt động trong ứng dụng nhà văn.
4 Dừng / Dừng quy trình Patroni
  • Một trong những máy chủ dự phòng đã có được khóa DCS và trở thành máy chủ bằng cách tự quảng cáo.
  • Trang cái cũ vẫn đang chạy và nó dẫn đến kịch bản nhiều cái. Đơn vẫn đang viết cho chủ cũ.
  • Sau khi Patroni được khởi động trên trang cái cũ, nó sẽ quấn lại trang cái cũ ( use_pg_rewind được đặt thành true) sang dòng thời gian và lsn chính mới và bắt đầu theo dõi trang chính mới.

Như bạn thấy ở trên, việc theo dõi sức khỏe của quá trình Patroni trên master là rất quan trọng. Nếu không làm như vậy có thể dẫn đến kịch bản đa tổng thể và khả năng mất dữ liệu.

Kiểm tra cách ly mạng

Sl. Không Tình huống thử nghiệm Quan sát
1 Cách ly mạng máy chủ chính khỏi các máy chủ khác Giao tiếp DCS đã bị chặn đối với nút chính.

  • PostgreSQL đã bị hạ cấp trên máy chủ chính.
  • Một trang cái mới đã được bầu trong phân vùng đa số.
  • Có một thời gian ngừng hoạt động trong ứng dụng nhà văn.
2 Cách ly mạng máy chủ dự phòng với các máy chủ khác Giao tiếp DCS đã bị chặn đối với nút chờ.

  • Dịch vụ PostgreSQL đang chạy, tuy nhiên, nút không được xem xét để tổ chức bầu cử.
  • Không có sự gián đoạn nào trong ứng dụng của người viết.

PostgreSQL HA Framework tốt nhất là gì?

Patroni là một công cụ có giá trị dành cho quản trị viên cơ sở dữ liệu PostgreSQL (DBA), vì nó thực hiện thiết lập và giám sát end-to-end của một cụm PostgreSQL. Sự linh hoạt trong việc chọn DCS và tạo chế độ chờ là một lợi thế đối với người dùng cuối, vì họ có thể chọn phương pháp mà họ cảm thấy thoải mái.

API REST, tích hợp HaProxy, hỗ trợ Cơ quan giám sát, lệnh gọi lại và tính năng quản lý phong phú của nó làm cho Patroni trở thành giải pháp tốt nhất để quản lý PostgreSQL HA.

PostgreSQL HA Framework Kiểm tra:PAF so với repmgr so với Patroni

Dưới đây là bảng tổng hợp chi tiết kết quả của tất cả các thử nghiệm mà chúng tôi đã thực hiện trên cả ba khung - PostgreSQL Automatic Failover (PAF), Replication Manager (repmgr) và Patroni.

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

Tình huống kiểm tra Chuyển đổi dự phòng tự động PostgreSQL (PAF) Trình quản lý nhân bản (repmgr) Patroni
Kill the PostgreSQL process Pacemaker brought the PostgreSQL process back to running state.

  • There was no disruption of the writer application.
 Standby server was marked as failed. Manual intervention was required to start the PostgreSQL process again.

  • There was no disruption of the writer application.
 Patroni brought the PostgreSQL process back to running state.

  • There was no disruption of the writer application.
Stop the PostgreSQL process Pacemaker brought the PostgreSQL process back to running state.

  • There was no disruption of the writer application.
 Standby server was marked as failed. Manual intervention was required to start the PostgreSQL process again.

  • There was no disruption of the writer application.
 Patroni brought the PostgreSQL process back to running state.

  • There was no disruption of the writer application.
Reboot the server Standby server was marked offline initially. Once the server came up after reboot, PostgreSQL was started by Pacemaker and the server was marked as online. If fencing was enabled then node wouldn’t have been added automatically to cluster.

  • There was no disruption of the writer application.
 Standby server was marked as failed. Once the server came up after reboot, PostgreSQL was started manually and server was marked as running.

  • There was no disruption of the writer application.
 Patroni needs to be started after reboot, unless configured to not start on reboot. Once Patroni was started, it started the PostgreSQL process and setup the standby configuration.

  • There was no disruption of the writer application.
Stop the framework agent process Agent:pacemaker

  • The PostgreSQL process was stopped and was marked offline.
  • There was no disruption of the writer application.
 Agent:repmgrd

  • The standby server will not be part of automated failover situation.
  • PostgreSQL service was found to be running.
  • There was no disruption of the writer application.
 Agent:patroni

  • It did not stop the PostgreSQL process.
  • patronictl list did not display this server.
  • There was no disruption of the writer application.

Master/Primary Server Tests

Test Scenario PostgreSQL Automatic Failover (PAF) Replication Manager (repmgr) Patroni
Kill the PostgreSQL process Pacemaker brought the PostgreSQL process back to running state. Primary got recovered within the threshold time and hence election was not triggered.

  • There was downtime in the writer application.
 repmgrd started health check for primary server connection on all standby servers for a fixed interval. When all retries failed, an election was triggered on all the standby servers. As a result of the election, the standby which had the latest received LSN got promoted. The standby servers which lost the election will wait for the notification from the new master node and will follow it once they receive the notification.Manual intervention was required to start the postgreSQL process again.

  • There was downtime in the writer application.
 Patroni brought the PostgreSQL process back to running state. Patroni running on that node had primary lock and hence election was not triggered.

  • There was downtime in the writer application.
Stop the PostgreSQL process and bring it back immediately after health check expiry Pacemaker brought the PostgreSQL process back to running state. Primary got recovered within the threshold time and hence election was not triggered.

  • There was downtime in the writer application.
 repmgrd started health check for primary server connections on all standby servers for a fixed interval. When all the 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.

  • There was downtime in the writer application.
 Patroni brought the PostgreSQL process back to running state. Patroni running on that node had primary lock and hence election was not triggered.

  • There was downtime in the writer application.
Reboot the server Election was triggered by Pacemaker after the threshold time for which master was not available. The most eligible standby server was promoted as the new master. Once the old master came up after reboot, it was added back to the cluster as a standby. If fencing was enabled, then node wouldn’t have been added automatically to cluster.

  • There was downtime in the writer application.
 repmgrd started 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 run to add the server back to the cluster.

  • There was downtime in the writer application.
 Failover happened and one of the standby servers was elected as the new master after obtaining the lock. When Patroni was started on the old master, it brought back the old master up and performed pg_rewind and started following the new master.

  • There was downtime in the writer application.
Stop the framework agent process Agent:pacemaker

  • The PostgreSQL process was stopped and it was marked offline.
  • Election was triggered and new master was elected.
  • There was downtime in writer application.
 Agent:repmgrd

  • The primary server will not be part of the automated failover situation.
  • PostgreSQL service was found to be running.
  • There was no disruption in writer application.
 Agent:patroni

  • One of the standby servers acquired the DCS lock and became the master by promoting itself.
  • The old master was still running and it led to multi-master scenario. The application was still writing to the old master.
  • Once Patroni was started on the old master, it rewound the old master (use_pg_rewind was set to true) to the new master timeline and lsn and started following the new master.

Network Isolation Tests

Test Scenario PostgreSQL Automatic Failover (PAF) Replication Manager (repmgr) Patroni
Network isolate the master server from other servers (split brain scenario) Corosync traffic was blocked on the master server.

  • PostgreSQL service was turned off and master server was marked offline due to quorum policy.
  • A new master was elected in the majority partition.
  • There was a downtime in the writer application.
 All servers have the same value for location in repmgr configuration:

  • repmgrd started 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.

The standby servers have the same value for location but the primary had a different value for location in repmgr configuration:

  • repmgrd started election when master connection health check failed on all standby servers.
  • But, there was no new master elected since the standby servers had 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.
 DCS communication was blocked for master node.

  • PostgreSQL was demoted on the master server.
  • A new master was elected in the majority partition.
  • There was a downtime in the writer application.
Network-isolate the standby server from other servers Corosync traffic was blocked on the standby server.

  • The server was marked offline and PostgreSQL service was turned off due to quorum policy.
  • There was no disruption in the writer application.
  • repmgrd went into degrade monitoring mode.
  • The PostgreSQL process was still running on the standby node.
  • Manual intervention was required after the network isolation was corrected.
 DCS communication was blocked for the standby node.

  • The PostgreSQL service was running, however, the node was not considered for elections.
  • There was no disruption in the writer application.


  1. Database
    2.   
  2. Mysql
    3.   
  3. Oracle
    4.   
  4. Sqlserver
    5.   
  5. PostgreSQL
    6.   
  6. Access
    7.   
  7. SQLite
    8.   
  8. MariaDB

  1. Liquibase / PostgreSQL:Làm thế nào để bảo vệ bảng trường hợp chính xác?

  2. jsonb so với jsonb [] cho nhiều địa chỉ cho một khách hàng

  3. Thêm ngày vào một ngày trong PostgreSQL

  4. Cách cài đặt PgBackRest

  5. HEX () và UNHEX () của MySQL tương đương trong Postgres?