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

Hướng dẫn về Pgpool cho PostgreSQL:Phần thứ hai

Đây là phần thứ hai của blog “Hướng dẫn về Pgpool cho PostgreSQL”. Bạn có thể tìm thấy phần đầu tiên bao gồm cân bằng tải, tổng hợp phiên, trong bộ nhớ đệm và cài đặt tại đây.

Nhiều người dùng hướng đến pgpool đặc biệt cho các tính năng Tính sẵn sàng cao và nó có rất nhiều thứ để cung cấp. Có rất ít hướng dẫn về pgpool HA trên web (ví dụ:một hướng dẫn dài hơn và ngắn hơn), vì vậy sẽ không có ý nghĩa gì nếu bạn lặp lại chúng. Chúng tôi cũng không muốn cung cấp một bộ giá trị cấu hình mù nào khác. Thay vào đó, tôi khuyên bạn nên làm theo các quy tắc và thử làm sai cách, vì vậy chúng ta sẽ thấy một số hành vi thú vị. Một trong những tính năng được mong đợi hàng đầu (ít nhất là ở trên đầu trang) là khả năng nhận ra khả năng sử dụng của bản chính cũ “đã chết” và sử dụng lại nó với pg_rewind. Nó có thể tiết kiệm hàng giờ kể từ khi mang lại chế độ chờ mới với dữ liệu lớn (vì chúng tôi bỏ qua rsync hoặc pg_basebackup, những thứ này sẽ sao chép hiệu quả TẤT CẢ các tệp từ bản chính mới). Nói một cách chính xác, pg_rewind được dùng để chuyển đổi dự phòng theo kế hoạch (trong quá trình nâng cấp hoặc chuyển sang phần cứng mới). Nhưng chúng tôi đã thấy khi nó giúp ích rất nhiều cho việc tắt máy không theo kế hoạch nhưng chưa có kế hoạch và chuyển đổi dự phòng tự động - ví dụ:ClusterControl sử dụng nó khi thực hiện chuyển đổi dự phòng tự động của các nô lệ sao chép. Giả sử chúng ta gặp trường hợp:chúng ta cần (bất kỳ) cái gì để có thể truy cập nhiều nhất có thể. Nếu vì lý do nào đó (lỗi mạng, vượt quá số kết nối tối đa hoặc bất kỳ “lỗi” nào khác cấm các phiên mới bắt đầu), chúng tôi không thể sử dụng một cái chính cho các hoạt động RW nữa, chúng tôi có một cụm chuyển đổi dự phòng được định cấu hình, với các nô lệ có thể chấp nhận các kết nối. Sau đó, chúng tôi có thể quảng bá một trong những nô lệ và không vượt qua được nó.

Trước tiên, hãy giả sử chúng ta có ba nút:

  • 10.1.10.124:5400 với / pg / 10 / m (pgpool cũng quay ở đây)
  • 10.1.10.147:5401 với / pg / 10 / m2
  • 10.1.10.124:5402 với / pg / 10 / s2

Đó thực sự là các nút giống như trong phần một, nhưng nút chuyển đổi dự phòng được chuyển sang một máy chủ khác và $ PGDATA. Tôi đã làm điều đó để đảm bảo rằng tôi không đánh máy hoặc quên một số trích dẫn bổ sung trong lệnh ssh từ xa. Ngoài ra, thông tin gỡ lỗi sẽ trông đơn giản hơn vì địa chỉ ip khác nhau. Cuối cùng, tôi không chắc mình sẽ có thể làm cho trường hợp sử dụng không được hỗ trợ này hoạt động, vì vậy tôi phải tận mắt chứng kiến.

Chuyển đổi dự phòng

Đầu tiên, chúng tôi đặt failover_command và chạy tải lại pgpool và cố gắng chuyển đổi dự phòng. Ở đây và xa hơn, tôi sẽ gửi lại một số thông tin tới / tmp / d trên máy chủ pgpool, vì vậy tôi có thể nối đuôi -f / tmp / d để xem quy trình.

[email protected]:~$ grep failover_command /etc/pgpool2/pgpool.conf
failover_command = 'bash /pg/10/fo.sh %D %H %R'

[email protected]:~$ cat /pg/10/fo.sh
rem_cmd="pg_ctl -D $3 promote"
cmd="ssh -T [email protected]$2 $rem_cmd"
echo "$(date) $cmd" >>/tmp/d
$cmd &>>/tmp/d

NB:Bạn có đặt $ PATH trong .bashrc trên máy chủ từ xa không? ..

Hãy ngăn chặn chủ nhân (tôi biết đó không phải là thảm họa xảy ra như thế nào, bạn mong đợi ít nhất một con khỉ khổng lồ hoặc robot sáng đỏ nào đó sẽ đập nát máy chủ bằng một chiếc búa lớn, hoặc ít nhất là những chiếc đĩa cứng nhàm chán chết đi, nhưng tôi đang sử dụng điều này một cách duyên dáng biến thể để giới thiệu khả năng sử dụng pg_rewind, vì vậy ở đây chuyển đổi dự phòng sẽ là kết quả của lỗi con người hoặc lỗi mạng trong nửa giây sau health_check_period), vì vậy:

/usr/lib/postgresql/10/bin/pg_ctl -D /pg/10/m stop
2018-04-18 13:53:55.469 IST [27433]  LOG:  received fast shutdown request
waiting for server to shut down....2018-04-18 13:53:55.478 IST [27433]  LOG:  aborting any active transactions
2018-04-18 13:53:55.479 IST [28855] postgres t FATAL:  terminating connection due to administrator command
2018-04-18 13:53:55.483 IST [27433]  LOG:  worker process: logical replication launcher (PID 27440) exited with exit code 1
2018-04-18 13:53:55.484 IST [27435]  LOG:  shutting down
2018-04-18 13:53:55.521 IST [27433]  LOG:  database system is shut down
 done
server stopped

Bây giờ kiểm tra đầu ra lệnh chuyển đổi dự phòng:

[email protected]:~$ cat /tmp/d
Wed Apr 18 13:54:05 IST 2018 ssh -T [email protected]
pg_ctl -D /pg/10/f promote
waiting for server to promote.... done
server promoted

Và kiểm tra sau một lúc:

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 | down | standby
   1 | 5401 | up   | primary
   2 | 5402 | up   | standby
(3 rows)

Ngoài ra, chúng tôi thấy trong nhật ký cụm chuyển đổi dự phòng cũ:

2018-04-13 14:26:20.823 IST [20713]  LOG:  received promote request
2018-04-13 14:26:20.823 IST [20713]  LOG:  redo done at 0/951EC20
2018-04-13 14:26:20.823 IST [20713]  LOG:  last completed transaction was at log time 2018-04-13 10:41:54.355274+01
2018-04-13 14:26:20.872 IST [20713]  LOG:  selected new timeline ID: 2
2018-04-13 14:26:20.966 IST [20713]  LOG:  archive recovery complete
2018-04-13 14:26:20.998 IST [20712]  LOG:  database system is ready to accept connections

Kiểm tra bản sao:

[email protected]:~$ psql -p 5401 t -c "select now() into test"
SELECT 1
[email protected]:~$ psql -p 5402 t -c "select * from test"
              now
-------------------------------
 2018-04-13 14:33:19.569245+01
(1 row)

Nô lệ / pg / 10 / s2:5402 đã chuyển sang dòng thời gian mới nhờ recovery_target_timeline =mới nhất trong recovery.conf, vì vậy chúng tôi rất ổn. Chúng tôi không cần điều chỉnh recovery.conf để trỏ đến cái chính mới, vì nó trỏ đến ip và cổng của pgpool và chúng vẫn giữ nguyên bất kể ai đang thực hiện vai trò chính chính.

Kiểm tra cân bằng tải:

[email protected]:~$ (for i in $(seq 1 9); do psql -h localhost -p 5433 t -c "select current_setting('port') from ts limit 1" -XAt; done) | sort| uniq -c
      6 5401
      3 5402

Tốt đẹp. Các ứng dụng sau pgpool sẽ thông báo ngừng hoạt động lần thứ hai và tiếp tục hoạt động.

Sử dụng lại bản chính cũ

Bây giờ chúng ta có thể chuyển cái cũ sang chế độ chờ chuyển đổi dự phòng và đưa nó trở lại (mà không cần thêm một nút mới vào pgpool, vì nó đã tồn tại ở đó). Nếu bạn chưa bật wal_log_hints hoặc tổng kiểm tra dữ liệu (sự khác biệt toàn diện giữa các tùy chọn này ở đây), bạn phải tạo lại cụm trên phiên bản cũ để theo một dòng thời gian mới:

[email protected]:~$ rm -fr /pg/10/m
[email protected]:~$ pg_basebackup -h localhost -p 5401 -D /pg/10/m/

Nhưng đừng vội chạy các câu lệnh trên! Nếu bạn quan tâm đến wal_log_hints (yêu cầu khởi động lại), bạn có thể thử sử dụng pg_rewind để chuyển đổi bản chính cũ sang máy chủ mới nhanh hơn nhiều.

Vì vậy, ATM chúng tôi có máy chủ cũ ngoại tuyến, máy chủ mới với dòng thời gian tiếp theo bắt đầu. Nếu máy chủ cũ ngoại tuyến do lỗi mạng tạm thời và nó hoạt động trở lại, trước tiên chúng ta cần tắt máy chủ. Trong trường hợp ở trên, chúng tôi biết nó đã bị lỗi, vì vậy chúng tôi có thể thử tua lại:

Các máy chủ
[email protected]:~$ pg_rewind -D /pg/10/m2 --source-server="port=5401 host=10.1.10.147"
servers diverged at WAL location 0/40605C0 on timeline 2
rewinding from last common checkpoint at 0/4060550 on timeline 2
Done!

Và một lần nữa:

[email protected]:~$ pg_ctl -D /pg/10/m2 start
server started
...blah blah 
[email protected]:~$ 2018-04-16 12:08:50.303 IST [24699]  LOG:  started streaming WAL from primary at 0/B000000 on timeline 2

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 | down | standby
   1 | 5401 | up   | primary
   2 | 5402 | up   | standby
(3 rows)

Hoạt động. Tât nhiên! Mặc dù thực tế là cụm tại cổng 5400 đang trực tuyến và tuân theo một dòng thời gian mới, chúng tôi cần nói với pgpool để nhận ra nó:

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

Bây giờ cả ba đều đã hoạt động (và pgpool biết điều đó) và đồng bộ hóa:

[email protected]:~$ sql="select ts.i::timestamp(0), current_setting('data_directory'),case when pg_is_in_recovery() then 'recovering' else 'mastering' end stream from ts order by ts desc"
[email protected]:~$ psql -h 10.1.10.147 -p 5401 t -c "$sql";
          i          | current_setting |  stream
---------------------+-----------------+-----------
 2018-04-30 14:34:36 | /pg/10/m2       | mastering
(1 row)

[email protected]:~$ psql -h 10.1.10.124 -p 5402 t -c "$sql";
          i          | current_setting |   stream
---------------------+-----------------+------------
 2018-04-30 14:34:36 | /pg/10/s2       | recovering
(1 row)

[email protected]:~$ psql -h 10.1.10.124 -p 5400 t -c "$sql";
          i          | current_setting |   stream
---------------------+-----------------+------------
 2018-04-30 14:34:36 | /pg/10/m        | recovering
(1 row)

Bây giờ tôi sẽ thử sử dụng recovery_1st_stage_command để sử dụng lại cái cũ:

[email protected]:~# grep 1st /etc/pgpool2/pgpool.conf
recovery_1st_stage_command = 'or_1st.sh'

Nhưng lệnh recovery_1st_stage_command không cung cấp các đối số cần thiết cho pg_rewind, mà tôi có thể thấy nếu tôi thêm vào recovery_1st_stage_command:

echo "online recovery started on $(hostname) $(date --iso-8601) $0 $1 $2 $3 $4"; exit 1;

Đầu ra:

online recovery started on u2 2018-04-30 /pg/10/m2/or_1st.sh /pg/10/m2 10.1.10.124 /pg/10/m 5401

Chà - sử dụng pg_rewind chỉ nằm trong danh sách việc cần làm - tôi đã mong đợi điều gì? .. Vì vậy, tôi cần thực hiện một số hack để lấy ip chính và cổng (hãy nhớ nó sẽ tiếp tục thay đổi sau khi chuyển đổi dự phòng).

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ột vụ hack khỉ

Vì vậy, tôi có một cái gì đó như thế này trong recovery_1st_stage_command:

[email protected]:~# cat /pg/10/or_1st.sh
pgpool_host=10.1.10.124
pgpool_port=5433
echo "online recovery started on $(hostname) $(date --iso-8601) $0 $1 $2 $3 $4" | ssh -T $pgpool_host "cat >> /tmp/d"
master_port=$(psql -XAt -h $pgpool_host -p $pgpool_port t -c "select port from dblink('host=$pgpool_host port=$pgpool_port','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) where role='primary'")
master_host=$(psql -XAt -h $pgpool_host -p $pgpool_port t -c "select hostname from dblink('host=$pgpool_host port=$pgpool_port','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) where role='primary'")
failover_host=$(psql -XAt -h $pgpool_host -p $pgpool_port t -c "select hostname from dblink('host=$pgpool_host port=$pgpool_port','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) where role!='primary' order by port limit 1")
src='"port=$master_port host=$master_host"'
rem_cmd="'pg_rewind -D $3 --source-server=\"port=$master_port host=$master_host\"'"
cmd="ssh -T $failover_host $rem_cmd"
echo $cmd | ssh -T $pgpool_host "cat >> /tmp/d"
$cmd

tmp=/tmp/rec_file_tmp
cat > $tmp <<EOF
standby_mode          = 'on'
primary_conninfo      = 'host=$master_host port=$master_port user=postgres'
trigger_file = '/tmp/tg_file'
recovery_target_timeline  = latest
EOF

scp $tmp $failover_host:$3/recovery.conf

rem_cmd="pg_ctl -D $3 start"
cmd="ssh -T $failover_host $rem_cmd"
echo $cmd | ssh -T $pgpool_host "cat >> /tmp/d"
$cmd
echo "OR finished $(date --iso-8601)" | ssh -T $pgpool_host "cat >> /tmp/d"
exit 0;

Bây giờ thật là một mớ hỗn độn! Chà - nếu bạn quyết định sử dụng tính năng không có sẵn - hãy chuẩn bị - nó sẽ trông tệ hại, hoạt động kém hơn và bạn sẽ vĩnh viễn cảm thấy xấu hổ về những gì mình đã làm. Vì vậy, từng bước:

  • Tôi cần IP và cổng pgpool để kết nối từ xa với nó, cả để truy vấn “show pool_nodes” và ghi nhật ký các bước cũng như chạy lệnh.
  • Tôi đang chuyển một số thông tin dbg tới / tmp / d qua ssh, vì lệnh sẽ được thực thi ở phía chính, lệnh này sẽ thay đổi sau khi thất bại
  • Tôi có thể sử dụng kết quả của “show pool_nodes” để nhận thông tin kết nối chính đang chạy chỉ đơn giản là lọc bằng mệnh đề WHERE
  • Tôi sẽ cần dấu ngoặc kép trong đối số cho pg_rewind, lệnh này sẽ cần chạy qua ssh, vì vậy tôi chỉ cần tách lệnh để dễ đọc, sau đó lặp lại lệnh và chạy
  • Đang chuẩn bị recovery.conf dựa trên kết quả từ “show pool_nodes” (viết nó ra, tôi tự hỏi mình - tại sao tôi không chỉ sử dụng cổng và IP pgpool thay thế? ..
  • Bắt đầu nô lệ chuyển đổi dự phòng mới (tôi biết tôi phải sử dụng bước thứ 2 - chỉ cần bỏ qua để tránh lấy lại tất cả IP và cổng)

Bây giờ những gì còn lại - cố gắng sử dụng mớ hỗn độn này trong pcp:

[email protected]:~# pcp_recovery_node -h 127.0.0.1 -U vao -n 0 -w
pcp_recovery_node -- Command Successful
[email protected]:~# psql -h localhost -p 5433 t -c"select nid,port,st,role from dblink('host=10.1.10.124 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 | standby
   1 | 5401 | up | primary
   2 | 5402 | up | standby
(3 rows)

Kiểm tra / tmp / d trên máy chủ pgpool:

[email protected]:~# cat /tmp/d
Tue May  1 11:37:59 IST 2018 ssh -T [email protected] /usr/lib/postgresql/10/bin/pg_ctl -D /pg/10/m2 promote
waiting for server to promote.... done
server promoted
online recovery started on u2 2018-05-01 /pg/10/m2/or_1st.sh /pg/10/m2
ssh -T 10.1.10.124 'pg_rewind -D --source-server="port=5401 host=10.1.10.147"'
ssh -T 10.1.10.124 pg_ctl -D start
OR finished 2018-05-01

Bây giờ rõ ràng chúng tôi muốn lật lại nó một lần nữa để xem nó có hoạt động trên bất kỳ máy chủ nào hay không:

[email protected]:~$ ssh -T 10.1.10.147 pg_ctl -D /pg/10/m2 stop             waiting for server to shut down.... done
server stopped
[email protected]:~$ psql -h localhost -p 5433 t -c"select nid,port,st,role from dblink('host=10.1.10.124 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 | down | standby
   2 | 5402 | up   | standby
(3 rows)

[email protected]:~# pcp_recovery_node -h 127.0.0.1 -U vao -n 1 -w

[email protected]:~$ psql -h localhost -p 5433 t -c"select nid,port,st,role from dblink('host=10.1.10.124 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)

Nhật ký trông giống nhau - chỉ IP và các cổng đã thay đổi:

 Tue May  1 11:44:01 IST 2018 ssh -T [email protected] /usr/lib/postgresql/10/bin/pg_ctl -D /pg/10/m promote
waiting for server to promote.... done
server promoted
online recovery started on u 2018-05-01 /pg/10/m/or_1st.sh /pg/10/m 10.1.10.147 /pg/10/m2 5400
ssh -T 10.1.10.147 'pg_rewind -D /pg/10/m2 --source-server="port=5400 host=10.1.10.124"'
ssh -T 10.1.10.147 pg_ctl -D /pg/10/m2 start
online recovery started on u 2018-05-01 /pg/10/m/or_1st.sh /pg/10/m
ssh -T 10.1.10.147 'pg_rewind -D --source-server="port=5400 host=10.1.10.124"'
ssh -T 10.1.10.147 pg_ctl -D start
OR finished 2018-05-01

Trong hộp cát này, tổng thể đã chuyển đến 5401 khi chuyển đổi dự phòng và sau khi sống ở đó một thời gian, nó chuyển trở lại 5400. Sử dụng pg_rewind sẽ làm cho nó nhanh nhất có thể. Trước đây, phần đáng sợ của chuyển đổi dự phòng tự động là - nếu bạn thực sự làm sai lệch cấu hình và không lường trước được một số trường hợp bất khả kháng, bạn có thể gặp phải tình trạng chuyển đổi dự phòng tự động sang nô lệ tiếp theo và tiếp theo và tiếp theo cho đến khi không còn nô lệ miễn phí. Và sau đó, bạn chỉ kết thúc với một số bậc thầy được phân chia và không có dự phòng chuyển đổi dự phòng. Thật là một sự an ủi tồi tệ trong tình huống như vậy khi có nhiều nô lệ hơn nữa để chuyển đổi dự phòng, nhưng nếu không có pg_rewind thì bạn thậm chí sẽ không có được điều đó. Rsync hoặc pg_basebackup “truyền thống” sao chép TẤT CẢ $ PGDATA để tạo chế độ chờ và không thể sử dụng lại bản chính cũ “không khác quá nhiều”.

Trong phần kết luận cho thử nghiệm này, tôi muốn nhấn mạnh một lần nữa - đây không phải là giải pháp phù hợp cho việc dán bản sao mù. Việc sử dụng pg_rewind không được khuyến khích cho pg_pool. Nó không thể sử dụng được ở tất cả các máy ATM. Tôi muốn thêm một chút không khí trong lành vào cấu hình pgpool HA, để các nubes như tôi có thể quan sát kỹ hơn một chút về cách nó hoạt động. Để coryphaeus mỉm cười với cách tiếp cận chủ nghĩa và có thể nhìn thấy nó bằng đôi mắt của chúng ta.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Nhận [archiver] phiên bản không được hỗ trợ (1.13) trong tiêu đề tệp khi chạy pg_restore

  2. Tại sao truy vấn không được lưu trong tệp csv trong khi nó có vẻ bình thường trong bảng điều khiển postgresql

  3. Lời khuyên khóa hoặc NOWAIT để tránh phải chờ các hàng bị khóa?

  4. lấy bản ghi ba tháng trước từ bảng

  5. Dấu hai chấm (::) ký hiệu trong SQL