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

Triển khai Switchover / Switchback trong PostgreSQL 9.3.

Bài đăng này hướng dẫn các DBA tinh vi về cách thiết lập môi trường Chuyển mạch và Chuyển ngược duyên dáng trong tính khả dụng cao của PostgreSQL. Đầu tiên, cảm ơn các tác giả bản vá Heikki và Fujii đã giúp cho việc chuyển đổi / chuyển ngược trở lại dễ dàng hơn trong PostgreSQL 9.3. (Xin thứ lỗi cho tôi nếu tôi bỏ sót các tên khác).

Hãy để tôi cố gắng minh họa điều đó ngắn gọn trước các bản vá này, tất cả các bạn đều biết Chế độ chờ là thành phần quan trọng trong việc khắc phục thảm họa nhanh chóng và an toàn. Trong PostgreSQL, khái niệm khôi phục chủ yếu đề cập đến các mốc thời gian để xác định một loạt các phân đoạn WAL trước và sau PITR hoặc quảng cáo Chế độ chờ để tránh chồng chéo các phân đoạn WAL. ID dòng thời gian được liên kết với tên tệp phân đoạn WAL (Ví dụ:- Trong $ PGDATA / pg_xlog / 0000000C000000020000009E đoạn “0000000C” là ID dòng thời gian). Trong tính năng Sao chép trực tuyến, cả Chính và Nô lệ sẽ tuân theo cùng một ID dòng thời gian, tuy nhiên khi Chế độ chờ được Switchover thăng cấp làm chủ mới, nó đụng phải ID dòng thời gian và Chính cũ từ chối khởi động lại ở chế độ Chờ do sự khác biệt về ID dòng thời gian và đưa ra thông báo lỗi là:

FATAL:  requested timeline 10 is not a child of this server's history
DETAIL: Latest checkpoint is at 2/9A000028 on timeline 9, but in the history of the requested timeline, the server forked off from that timeline at 2/99017E68.

Vì vậy, một Chế độ chờ mới phải được xây dựng từ đầu, nếu kích thước cơ sở dữ liệu lớn thì thời gian xây dựng lại lâu hơn và trong giai đoạn này, Chế độ chờ mới được quảng bá sẽ chạy mà không có Chế độ chờ. Ngoài ra còn có một vấn đề khác như khi Switchover xảy ra Primary tắt hoàn toàn, quy trình Walsender sẽ gửi tất cả các bản ghi WAL chưa xử lý đến chế độ chờ nhưng không đợi chúng được sao chép trước khi thoát. Walreceiver không thể áp dụng các bản ghi WAL tồn đọng đó vì nó phát hiện ra việc đóng kết nối và thoát.

Hôm nay, với hai bản cập nhật phần mềm quan trọng trong PostgreSQL 9.3, cả hai vấn đề đều được các tác giả giải quyết rất tốt và giờ đây, Chế độ chờ sao chép trực tuyến luôn tuân theo một chuyển đổi dòng thời gian nhất quán. Giờ đây, chúng tôi có thể chuyển đổi nhiệm vụ giữa Chính và Chờ một cách liền mạch và dễ dàng bằng cách khởi động lại và giảm đáng kể thời gian xây dựng lại của Chế độ chờ.

Lưu ý:Không thể thực hiện chuyển đổi / Chuyển lại nếu cả hai máy chủ và trong quy trình Chuyển đổi đều không truy cập được Lưu trữ WAL Cơ sở dữ liệu chính phải tắt hoàn toàn (chế độ bình thường hoặc nhanh).

Để giới thiệu, hãy bắt đầu với thiết lập Nhân bản truyền trực tuyến (wiki để thiết lập SR) mà tôi đã định cấu hình trong máy ảo cục bộ của mình giữa hai cụm (5432 ở chế độ Chính và 5433 ở chế độ chờ) chia sẻ một vị trí lưu trữ WAL chung, vì cả hai cụm đều có quyền truy cập đầy đủ trình tự của các kho lưu trữ WAL. Hãy xem ảnh chụp nhanh được chia sẻ bên dưới với chi tiết thiết lập và ID dòng thời gian hiện tại để hiểu rõ hơn về khái niệm.

Ở giai đoạn này, mọi người phải hiểu rõ rằng Switchover và Switchback là những hoạt động đã được lên kế hoạch. Bây giờ thiết lập SR tại chỗ, chúng ta có thể trao đổi các nhiệm vụ của chế độ chính và chế độ chờ như hình dưới đây:

Các bước chuyển đổi:

Bước 1. Tắt hoàn toàn chính [5432] (-m nhanh hoặc thông minh)

[postgres@localhost:/~]$ /opt/PostgreSQL/9.3/bin/pg_ctl -D /opt/PostgreSQL/9.3/data stop -mf
waiting for server to shut down.... done
server stopped

Bước 2. Kiểm tra trạng thái đồng bộ hóa và trạng thái khôi phục của Chế độ chờ [5433] trước khi quảng bá nó:

[postgres@localhost:/opt/PostgreSQL/9.3~]$  psql -p 5433 -c 'select pg_last_xlog_receive_location() "receive_location",
pg_last_xlog_replay_location() "replay_location",
pg_is_in_recovery() "recovery_status";'
receive_location | replay_location | recovery_status
------------------+-----------------+-----------------
2/9F000A20 | 2/9F000A20 | t
(1 row)

Đồng bộ hoàn toàn ở chế độ chờ. Ở giai đoạn này, chúng tôi có thể an toàn để quảng cáo nó là Chính.
Bước 3. Mở Chế độ chờ dưới dạng Chính mới bằng cách quảng cáo pg_ctl hoặc tạo tệp trình kích hoạt.

[postgres@localhost:/opt/PostgreSQL/9.3~]$ grep trigger_file data_slave/recovery.conf
trigger_file = '/tmp/primary_down.txt'
[postgres@localhost:/opt/PostgreSQL/9.3~]$ touch /tmp/primary_down.txt

[postgres@localhost:/opt/PostgreSQL/9.3~]$ psql -p 5433 -c "select pg_is_in_recovery();"
pg_is_in_recovery
-------------------
f
(1 row)

In Logs:
2014-12-29 00:16:04 PST-26344-- [host=] LOG: trigger file found: /tmp/primary_down.txt
2014-12-29 00:16:04 PST-26344-- [host=] LOG: redo done at 2/A0000028
2014-12-29 00:16:04 PST-26344-- [host=] LOG: selected new timeline ID: 14
2014-12-29 00:16:04 PST-26344-- [host=] LOG: restored log file "0000000D.history" from archive
2014-12-29 00:16:04 PST-26344-- [host=] LOG: archive recovery complete
2014-12-29 00:16:04 PST-26342-- [host=] LOG: database system is ready to accept connections
2014-12-29 00:16:04 PST-31874-- [host=] LOG: autovacuum launcher started

Chế độ chờ đã được nâng cấp thành chế độ chính và theo sau đó là một dòng thời gian mới mà bạn có thể nhận thấy trong nhật ký.
Bước 4. Khởi động lại Chính cũ ở chế độ chờ và cho phép theo dòng thời gian mới bằng cách chuyển “recovery_target_timline =’ mới nhất ”vào tệp $ PGDATA / recovery.conf.

[postgres@localhost:/opt/PostgreSQL/9.3~]$ cat data/recovery.conf
recovery_target_timeline = 'latest'
standby_mode = on
primary_conninfo = 'host=localhost port=5433 user=postgres'
restore_command = 'cp /opt/PostgreSQL/9.3/archives93/%f %p'
trigger_file = '/tmp/primary_131_down.txt'
[postgres@localhost:/opt/PostgreSQL/9.3~]$ /opt/PostgreSQL/9.3/bin/pg_ctl -D /opt/PostgreSQL/9.3/data start
server starting

Nếu bạn đi qua recovery.conf thì rất rõ ràng rằng Chính cũ đang cố gắng kết nối với cổng 5433 dưới dạng Chế độ chờ mới trỏ đến vị trí Lưu trữ WAL chung và đã bắt đầu.

In Logs:
2014-12-29 00:21:17 PST-32315-- [host=] LOG: database system was shut down at 2014-12-29 00:12:23 PST
2014-12-29 00:21:17 PST-32315-- [host=] LOG: restored log file "0000000E.history" from archive
2014-12-29 00:21:17 PST-32315-- [host=] LOG: entering standby mode
2014-12-29 00:21:17 PST-32315-- [host=] LOG: restored log file "0000000D00000002000000A0" from archive
2014-12-29 00:21:17 PST-32315-- [host=] LOG: restored log file "0000000D.history" from archive
2014-12-29 00:21:17 PST-32315-- [host=] LOG: consistent recovery state reached at 2/A0000090
2014-12-29 00:21:17 PST-32315-- [host=] LOG: record with zero length at 2/A0000090
2014-12-29 00:21:17 PST-32310-- [host=] LOG: database system is ready to accept read only connections
2014-12-29 00:21:17 PST-32325-- [host=] LOG: started streaming WAL from primary at 2/A0000000 on timeline 14

Bước 5. Xác minh trạng thái Chờ mới.

[postgres@localhost:/opt/PostgreSQL/9.3~]$ psql -p 5432 -c "select pg_is_in_recovery();"
pg_is_in_recovery
-------------------
t
(1 row)

Tuyệt vời, không cần thiết lập lại, chúng tôi đã đưa trở lại Chính cũ dưới dạng Chế độ chờ mới.

Các bước chuyển đổi:

Bước 1. Thực hiện tắt hoàn toàn Chính mới [5433]:

[postgres@localhost:/opt/~]$ /opt/PostgreSQL/9.3/bin/pg_ctl -D /opt/PostgreSQL/9.3/data_slave stop -mf
waiting for server to shut down.... done
server stopped

Bước 2. Kiểm tra trạng thái đồng bộ của Chế độ chờ mới [5432] trước khi quảng cáo.
Bước 3. Mở Chế độ chờ [5432] mới dưới dạng Chính bằng cách tạo tệp kích hoạt hoặc quảng cáo pg_ctl.

[postgres@localhost:/opt/PostgreSQL/9.3~]$ touch /tmp/primary_131_down.txt

Bước 4. Khởi động lại đã dừng Chính [5433] mới dưới dạng Chế độ chờ mới.

[postgres@localhost:/opt/PostgreSQL/9.3~]$ more data_slave/recovery.conf
recovery_target_timeline = 'latest'
standby_mode = on
primary_conninfo = 'host=localhost port=5432 user=postgres'
restore_command = 'cp /opt/PostgreSQL/9.3/archives93/%f %p'
trigger_file = '/tmp/primary_down.txt'

[postgres@localhost:/opt/PostgreSQL/9.3~]$ /opt/PostgreSQL/9.3/bin/pg_ctl -D /opt/PostgreSQL/9.3/data_slave start
server starting

Bạn có thể xác minh nhật ký của Chế độ chờ mới.

In logs:
[postgres@localhost:/opt/PostgreSQL/9.3/data_slave/pg_log~]$ more postgresql-2014-12-29_003655.log
2014-12-29 00:36:55 PST-919-- [host=] LOG: database system was shut down at 2014-12-29 00:34:01 PST
2014-12-29 00:36:55 PST-919-- [host=] LOG: restored log file "0000000F.history" from archive
2014-12-29 00:36:55 PST-919-- [host=] LOG: entering standby mode
2014-12-29 00:36:55 PST-919-- [host=] LOG: restored log file "0000000F.history" from archive
2014-12-29 00:36:55 PST-919-- [host=] LOG: restored log file "0000000E00000002000000A1" from archive
2014-12-29 00:36:55 PST-919-- [host=] LOG: restored log file "0000000E.history" from archive
2014-12-29 00:36:55 PST-919-- [host=] LOG: consistent recovery state reached at 2/A1000090
2014-12-29 00:36:55 PST-919-- [host=] LOG: record with zero length at 2/A1000090
2014-12-29 00:36:55 PST-914-- [host=] LOG: database system is ready to accept read only connections
2014-12-29 00:36:55 PST-929-- [host=] LOG: started streaming WAL from primary at 2/A1000000 on timeline 15
2014-12-29 00:36:56 PST-919-- [host=] LOG: redo starts at 2/A1000090

Rất hay, không mất nhiều thời gian, chúng tôi đã chuyển đổi nhiệm vụ của máy chủ Chính và Máy chủ chờ. Bạn thậm chí có thể nhận thấy sự gia tăng của các ID dòng thời gian từ nhật ký cho mỗi chương trình khuyến mãi.

Giống như những người khác, tất cả các bài viết của tôi đều là một phần của chia sẻ kiến ​​thức, mọi nhận xét hoặc chỉnh sửa đều được hoan nghênh nhất. 🙂


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. SQLAlchemy, Psycopg2 và Postgresql COPY

  2. Thực hiện WHERE IN trên nhiều cột trong Postgresql

  3. Python Postgres psycopg2 ThreadedConnectionPool đã cạn kiệt

  4. Cách Tand () hoạt động trong PostgreSQL

  5. PostgreSQL Tạo chỉ mục