Hướng dẫn về PGpool - Gợi ý &Quan sát:Phần ba

Trong phần trước, tôi đã dám thử với một tính năng chưa được triển khai và tưởng tượng rằng nó sẽ hoạt động như thế nào. Vâng HA đầu tiên là vấn đề thiết kế và chỉ sau đó là thực hiện. Nó không bào chữa cho việc triển khai tồi, cũng không làm cho thiết kế ngây thơ trông thông minh. Tuy nhiên, sau khi bạn bao gồm tất cả các tình huống có thể xảy ra và tìm thấy một quy tắc tốt nhất thích hợp cho hầu hết các trường hợp, đôi khi một thay đổi nhỏ rất sơ khai có thể phá hỏng thành trì. Bên dưới tôi muốn hộp cát.

Điều gì sẽ xảy ra khi pgpool nên chuyển đổi dự phòng, nhưng không thể?

Khi kiểm tra tình trạng không thành công cho chính, lệnh failover_command được kích hoạt để biến đổi tất cả hoặc thăng cấp nô lệ tiếp theo thành chính. Nghe chắc chắn. Điều gì sẽ xảy ra nếu chính nó không thành công, ví dụ:kết nối ssh không thành công (ví dụ:do quản trị viên khác - xấu xóa khóa khỏi ~ / .ssh / allow_keys). Chúng tôi có gì?

Ngay sau khi health_check_timeout (mặc định 20) hết (cũng bị ảnh hưởng bởi độ trễ thử lại, tối đa ngừng hoạt động, v.v.) nút sẽ chết, vì vậy:

t=# select nid,port,st from dblink('host=localhost port=5433','show pool_nodes') as t (nid int,hostname text,port int,st text,lb_weight float,role text,cnt int,cur_node text,del int);
 nid | port |  st
-----+------+------
   0 | 5400 | down
   1 | 5401 | up
   2 | 5402 | up
(3 rows)

Vì vậy, không còn thử lại và chuyển đổi dự phòng không thành công. Tùy chọn đầu tiên rõ ràng là thực hiện chuyển đổi dự phòng theo cách thủ công. Nhưng nếu chuyển đổi dự phòng không thành công vì một số lỗi ngu ngốc, chủ nhân đã trở lại đường ray và vấn đề duy nhất bạn gặp phải là pgpool nghĩ rằng chủ nhân đang ngoại tuyến - bạn có thể sẽ muốn để mọi thứ như cũ trước khi xảy ra tai nạn - phải không? Tất nhiên chỉ chuyển master trở lại trực tuyến là không đủ. Pgpool đã "thoái hóa" cái chính. Chỉ thêm nó làm nút mới cũng không giúp được gì. Điều tồi tệ nhất là sau sự kiện, pgpool sẽ không cố gắng kiểm tra xem bản chính cũ có phải là pg_is_in_recovery () hay không, do đó sẽ không bao giờ chấp nhận nó là chính. Theo lỗi theo dõi, bạn phải "Hủy tệp pgpool_status và không khôi phục trạng thái trước đó" bằng lệnh pgpool -D.

Sau khi loại bỏ trạng thái, chúng tôi kết nối lại để tránh thấy máy chủ đóng kết nối đột ngột và chạy:

t=# select nid,port,st,role from dblink('host=localhost port=5433','show pool_nodes') as t (nid int,hostname text,port int,st text,lb_weight float,role text,cnt int,cur_node text,del int);
 nid | port | st |  role
-----+------+----+---------
   0 | 5400 | up | primary
   1 | 5401 | up | standby
   2 | 5402 | up | standby
(3 rows)

Tất cả các nút đều được sao lưu và chạy, pgpool nhận ra nút chính.

Cuối cùng, tôi muốn đề cập đến một số gợi ý và quan sát về việc sử dụng pgpool:

Thay đổi cài đặt phụ trợ hơi phức tạp:tên máy chủ, cổng và thư mục yêu cầu tải lại để thêm các nút mới, nhưng yêu cầu khởi động lại để chỉnh sửa hiện có. Trong khi trọng lượng và cờ có thể được thay đổi chỉ bằng cách tải lại.

Đừng nhầm lẫn các giá trị cột load_balance_node với cấu hình. Nếu bạn chỉ thấy một nút với true thì điều đó không chỉ OK - điều đó có nghĩa là như vậy. Nó không có nghĩa là bạn chỉ có một nút trong nhóm cân bằng - nó chỉ hiển thị nút nào được chọn cho phiên cụ thể này. Dưới đây là kết quả truy vấn với cả ba nút tham gia cân bằng câu lệnh SELECT, với id nút 2 được chọn:

t=# show pool_nodes;
 node_id | hostname  | port | status | lb_weight |  role   | select_cnt | load_balance_node | replication_delay
---------+-----------+------+--------+-----------+---------+------------+-------------------+-------------------
 0       | localhost | 5400 | up     | 0.125000  | primary | 61         | false             | 0
 1       | localhost | 5401 | up     | 0.312500  | standby | 8          | false             | 0
 2       | localhost | 5402 | up     | 0.562500  | standby | 11         | true              | 0
(3 rows)

Bạn có thể kiểm tra xem nút nào đã được chọn để cân bằng tải với show pool_nodes, nhưng bạn cần biết nó cho truy vấn của mình, không phải nút "hiển thị", vì vậy việc kiểm tra như vậy không phải lúc nào cũng đủ thông tin. Bạn cũng có thể theo dõi nút nào bạn sử dụng cho truy vấn hiện tại, với những thứ như:
```
t=# select *,current_setting('port') from now();
              now              | current_setting
-------------------------------+-----------------
 2018-04-09 13:56:17.501779+01 | 5401
(1 row)
```

Quan trọng! Nhưng không:

t=# select now, setting from now() join pg_settings on name='port';
             now             | setting
-----------------------------+---------
 2018-04-09 13:57:17.5229+01 | 5400
(1 row)

Vì nó LUÔN sẽ trả về cổng của chính. Áp dụng tương tự cho bất kỳ pg_catalog SELECT nào.

Như bạn đã nhận thấy trong các phần trước, tôi sử dụng cách phức tạp hơn, thay vì chỉ hiển thị pool_nodes để liệt kê các nút có trạng thái. Tôi cố tình làm điều đó để chứng minh cách bạn có thể quản lý kết quả. Sử dụng ở đâu làm cho truy vấn dài hơn, nhưng kết quả rõ ràng, bỏ qua tất cả những gì làm phân tán sự chú ý cho nhiệm vụ cụ thể của chúng ta. So sánh:

t=# select nid,port,st,role from dblink('host=localhost port=5433','show pool_nodes') as t (nid int,hostname text,port int,st text,lb_weight float,role text,cnt int,cur_node text,del int);
 nid | port | st |  role
-----+------+----+---------
   0 | 5400 | up | primary
   1 | 5401 | up | standby
   2 | 5402 | up | standby

Với đầu ra của chương trình pool_nodes ban đầu ...

Bạn không thể so sánh pgbouncer và pgpool. Nhưng nếu bạn làm vậy, điều quan trọng nhất cần biết là phân tích cú pháp các truy vấn trong pgpool phụ thuộc vào phiên bản pg. Vì vậy, khi nâng cấp postgreSQL, bạn cũng cần nâng cấp pgpool, trong khi một phiên bản pgbouncer có thể có cấu hình cho 8,9,10 cụm khác nhau trong cùng một tệp ini.
Tại sao tôi không thể chỉ sử dụng tập lệnh chuyển đổi dự phòng thay vì pgpool? Bạn có thể. Nhưng pgpool cung cấp nó CŨNG CÓ với tính năng tổng hợp kết nối và bộ nhớ đệm, cân bằng và phân chia kiểm soát não bộ và được kiểm tra bằng nhiều thập kỷ sử dụng.
Hệ thống theo dõi lỗi đã có sẵn - đáng để truy cập nếu bạn làm việc với pgpool:https://www.pgpool.net/mantisbt/my_view_page.php
Nhiều lỗi chính tả trong tài liệu, như bakance (backend + balance? ..), statemnet, allowd hoặc không khớp giữa các phiên bản (pool_nodes từng là int và bây giờ là enum, nhưng liên kết đến các giá trị cũ trong pcp_node-info vẫn còn đó) làm hỏng ấn tượng về sản phẩm tuyệt vời này. Mặc dù vậy, một biểu mẫu để gửi báo cáo về “lỗi” được tìm thấy trong tài liệu (giống như “gửi sửa chữa” trên tài liệu postgres) sẽ cải thiện đáng kể.

Mẹo quan trọng: trước khi dựa vào bất kỳ bước nào - hãy kiểm tra nó. Ví dụ. sau khi quảng cáo nút, bạn không thể quảng cáo lại nút đó (ở đây quảng cáo không phải là hoạt động postgres, mà là đăng ký nút dưới dạng chính cho pgpool):

[email protected]:~# sudo -u postgres pcp_promote_node -w -h 127.0.0.1 -U vao -n 1
pcp_promote_node -- Command Successful
[email protected]:~# sudo -u postgres pcp_promote_node -w -h 127.0.0.1 -U vao -n 1
FATAL:  invalid pgpool mode for process recovery request
DETAIL:  specified node is already primary node, can't promote node id 1

Âm thanh logic và trông tuyệt vời. Tuy nhiên, nếu bạn chạy điều này với nút sai (ví dụ:nút 0 là! Pg_is_in_recovery):

[email protected]:~# for i in $(seq 1 3); do pcp_promote_node -w -h 127.0.0.1 -U vao -n 0; echo $?; done
pcp_promote_node -- Command Successful
0
pcp_promote_node -- Command Successful
0
pcp_promote_node -- Command Successful
0

Điều này thật tệ vì bạn không thể đánh dấu lại nút và có thể xảy ra lỗi, nhưng bạn sẽ có trạng thái thoát 0…

Tải xuống Báo cáo chính thức hôm nay Quản lý &Tự động hóa PostgreSQL với ClusterControlTìm hiểu về những điều bạn cần biết để triển khai, giám sát, quản lý và mở rộng PostgreSQLTải xuống Báo cáo chính thức

Mẹo quan trọng:Đừng chơi quá nhiều. Không bao giờ chơi trên sản phẩm!

Đang chơi với recovery_1st_stage_command bằng cách sử dụng pg_rewind, tôi nghĩ vì tò mò nên thử một hack khỉ khác - truy vấn pgpool_recovery () mà không có đối số (vì tôi vẫn bỏ qua chúng trong thiết lập của mình) và sau đó chỉ cố gắng đính kèm nút vào pgpool:

[email protected]:~# psql -p 5433 -h localhost template1 -c "SELECT pgpool_recovery('or_1st.sh', '', '', '')"
 pgpool_recovery
-----------------
 t
(1 row)

[email protected]:~# pcp_attach_node -h 127.0.0.1 -U vao -w -n 1
pcp_attach_node -- Command Successful

Ý tưởng ngu ngốc này đã đưa tôi đến:

[email protected]:~# ps -aef | grep pgpool
postgres 15227     1  0 11:22 ?        00:00:00 pgpool -D
postgres 15240 15227  0 11:22 ?        00:00:00 pgpool: health check process(0)
postgres 15241 15227  0 11:22 ?        00:00:00 pgpool: health check process(1)
postgres 15242 15227  0 11:22 ?        00:00:00 pgpool: health check process(2)
postgres 15648 15227  0 11:24 ?        00:00:00 [pgpool] <defunct>
postgres 16264 15227  0 11:26 ?        00:00:00 pgpool: PCP: wait for connection request
postgres 16266 15227  0 11:26 ?        00:00:00 [pgpool] <defunct>
postgres 16506 16264  0 11:26 ?        00:00:00 pgpool: PCP: processing recovery request
postgres 16560 15227  0 11:26 ?        00:00:00 [pgpool] <defunct>
postgres 16835 15227  0 11:26 ?        00:00:00 [pgpool] <defunct>
postgres 16836 15227  0 11:26 ?        00:00:00 [pgpool] <defunct>

Không có lối thoát, tôi phải:

[email protected]:~# kill -9 
[email protected]:~# rm /var/run/pgpoolql/.s.PGSQL.5433
[email protected]:~# rm /var/run/pgpoolql/.s.PGSQL.9898

Trên 5433 là cổng pgpool và 9898 là cổng pcp. Rõ ràng là sau sự cố, các tệp không được quét, vì vậy bạn phải làm điều đó theo cách thủ công.

Đọc kỹ và đọc nhiều trước khi đưa pgpool vào sản xuất. Tìm trợ giúp với pgpool rồi tự postgres khó hơn nhiều. Một số câu hỏi không bao giờ được trả lời. Đặc biệt là khi hỏi sai chỗ (tôi trả lời dựa vào đúng chỗ để có câu trả lời) ...
Đừng quên mốc thời gian mới nhất để sao chép theo tầng (thực sự không phải là gợi ý của pgpool, nhưng mọi người thường không hiểu rằng để nhận một bản chính mới, chỉ định một điểm cuối phù hợp cho người nhận là không đủ).
Có thể tìm thấy kiến trúc với sơ đồ tại đây.

Kết luận

Trong 10 năm, các tính năng mới đầy hứa hẹn (watchdog và ip ảo) và các bản sửa lỗi quan trọng (ví dụ:serialize_accept) đã xuất hiện, nhưng nhìn chung nó để lại ấn tượng bị đánh giá thấp. Các tài liệu có lỗi chính tả đã tồn tại ở đó 10 năm. Tôi không tin là không có ai đọc tài liệu. Tôi không tin là không ai nhận ra. Bạn không thể báo cáo chúng theo bất kỳ cách nào dễ dàng. Có rất nhiều súng đã được nạp và chuẩn bị sẵn, nằm trên trang web tài liệu cho người mới sử dụng, chỉ vào chân và bóp cò. Tôi không có ý tưởng hợp lý về cách cải thiện nó - Tôi chỉ cảnh báo những kẻ bắn súng. Việc hiểu sai một tham số có thể khiến bạn rơi vào tình thế tuyệt vọng với kỹ thuật đảo ngược để tìm ra sai lầm của mình. Trong suốt những năm qua pgpool đã từng và vẫn là một sản phẩm dành cho người dùng cao cấp. Đọc tài liệu, tôi không thể không nhớ lại câu chuyện cười cũ của người Nga về Sherlock Holmes:Sherlock và Watson bay trên khinh khí cầu. Đột nhiên cơn gió mạnh thổi bay họ đi hàng nghìn dặm. Khi họ có thể hạ cánh, họ nhìn thấy cô gái đang chăn cừu. Holmes hỏi cô gái:"Em yêu, chúng ta đang ở đâu?" và cô gái trả lời "Bạn đang ở trên khinh khí cầu!". Sherlock cảm ơn và khi họ cất cánh nói "Gió đã đưa chúng tôi đi rất xa - chúng tôi đang ở Nga". "Nhưng bạn biết nó bằng cách nào?" Watson hỏi. “Đó là điều hiển nhiên - chỉ ở Nga những người viết mã mới chăn thả cừu” Sherlock trả lời. "Nhưng làm thế nào để bạn biết cô gái là coder?" - “Đó là điều hiển nhiên - cô ấy đã cho chúng tôi câu trả lời hoàn toàn chính xác và hoàn toàn vô ích”.