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

Thực hiện thay đổi cấu trúc liên kết sao chép cho PostgreSQL

Nhân rộng đóng một vai trò quan trọng trong việc duy trì tính khả dụng cao. Máy chủ có thể bị lỗi, hệ điều hành hoặc phần mềm cơ sở dữ liệu có thể cần được nâng cấp. Điều này có nghĩa là sắp xếp lại các vai trò máy chủ và di chuyển các liên kết sao chép, đồng thời duy trì tính nhất quán của dữ liệu trên tất cả các cơ sở dữ liệu. Thay đổi cấu trúc liên kết sẽ được yêu cầu và có nhiều cách khác nhau để thực hiện chúng.

Quảng cáo Máy chủ Dự phòng

Có thể nói, đây là thao tác phổ biến nhất mà bạn cần thực hiện. Có nhiều lý do - ví dụ, việc bảo trì cơ sở dữ liệu trên máy chủ chính có thể ảnh hưởng đến khối lượng công việc theo cách không thể chấp nhận được. Có thể có thời gian ngừng hoạt động theo kế hoạch do một số hoạt động phần cứng. Sự cố của máy chủ chính khiến ứng dụng không thể truy cập được. Đây là tất cả các lý do để thực hiện chuyển đổi dự phòng, cho dù có kế hoạch hay không. Trong mọi trường hợp, bạn sẽ phải thúc đẩy một trong các máy chủ dự phòng trở thành máy chủ chính mới.

Để thúc đẩy một máy chủ dự phòng, bạn cần chạy:

[email protected]:~$ /usr/lib/postgresql/10/bin/pg_ctl promote -D /var/lib/postgresql/10/main/
waiting for server to promote.... done
server promoted

Thật dễ dàng để chạy lệnh này, nhưng trước tiên, hãy đảm bảo tránh bất kỳ trường hợp mất dữ liệu nào. Nếu chúng ta đang nói về tình huống "máy chủ chính ngừng hoạt động", bạn có thể không có quá nhiều lựa chọn. Nếu đó là một bảo trì theo kế hoạch, thì bạn có thể chuẩn bị cho nó. Bạn cần dừng lưu lượng trên máy chủ chính, sau đó xác minh rằng máy chủ dự phòng đã nhận và áp dụng tất cả dữ liệu. Điều này có thể được thực hiện trên máy chủ dự phòng, sử dụng truy vấn như sau:

postgres=# select pg_last_wal_receive_lsn(), pg_last_wal_replay_lsn();
 pg_last_wal_receive_lsn | pg_last_wal_replay_lsn
-------------------------+------------------------
 1/AA2D2B08              | 1/AA2D2B08
(1 row)

Khi mọi thứ đều ổn, bạn có thể dừng máy chủ chính cũ và quảng bá máy chủ 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

Khôi phục Máy chủ Dự phòng khỏi Máy chủ Chính mới

Bạn có thể có nhiều hơn một máy chủ dự phòng tắt máy chủ chính của mình. Rốt cuộc, các máy chủ dự phòng rất hữu ích để giảm tải lưu lượng truy cập chỉ đọc. Sau khi nâng cấp máy chủ dự phòng sang máy chủ chính mới, bạn cần phải làm gì đó với các máy chủ dự phòng còn lại vẫn được kết nối (hoặc đang cố gắng kết nối) với máy chủ chính cũ. Thật không may, bạn không thể chỉ thay đổi recovery.conf và kết nối chúng với máy chủ chính mới. Để kết nối chúng, trước tiên bạn cần xây dựng lại chúng. Có hai phương pháp bạn có thể thử tại đây:sao lưu cơ sở tiêu chuẩn hoặc pg_rewind.

Chúng tôi sẽ không đi sâu vào chi tiết cách thực hiện sao lưu cơ sở - chúng tôi đã đề cập đến vấn đề này trong bài đăng blog trước đây của mình, bài viết này tập trung vào việc sao lưu và khôi phục chúng trên PostgreSQL. Nếu bạn tình cờ sử dụng ClusterControl, bạn cũng có thể sử dụng nó để tạo một bản sao lưu cơ sở:

Mặt khác, hãy nói đôi lời về pg_rewind. Sự khác biệt chính giữa cả hai phương pháp là sao lưu cơ sở tạo ra một bản sao đầy đủ của tập dữ liệu. Nếu chúng ta đang nói về các tập dữ liệu nhỏ thì có thể không sao nhưng đối với các tập dữ liệu có kích thước hàng trăm gigabyte (hoặc thậm chí lớn hơn), nó có thể nhanh chóng trở thành một vấn đề. Cuối cùng, bạn muốn các máy chủ dự phòng của mình nhanh chóng khởi động và chạy - để giảm tải máy chủ đang hoạt động của bạn và có một chế độ chờ khác để chuyển đổi dự phòng, nếu có nhu cầu. Pg_rewind hoạt động theo cách khác - nó chỉ sao chép những khối đã được sửa đổi. Thay vì sao chép mọi thứ, nó chỉ sao chép các thay đổi, tăng tốc quá trình lên khá nhiều. Giả sử cái chủ mới của bạn có IP là 10.0.0.103. Đây là cách bạn có thể thực thi pg_rewind. Xin lưu ý rằng bạn phải dừng máy chủ đích - PostgreSQL không thể chạy ở đó.

[email protected]:~$ /usr/lib/postgresql/10/bin/pg_rewind --source-server="user=myuser dbname=postgres host=10.0.0.103" --target-pgdata=/var/lib/postgresql/10/main --dry-run
servers diverged at WAL location 1/AA4F1160 on timeline 3
rewinding from last common checkpoint at 1/AA4F10F0 on timeline 3
Done!

Điều này sẽ làm cho chạy khô , đang thử nghiệm quy trình nhưng không thực hiện bất kỳ thay đổi nào. Nếu mọi thứ đều ổn, tất cả những gì bạn phải làm là chạy lại, lần này không có thông số ‘--dry-run’. Sau khi hoàn tất, bước cuối cùng còn lại sẽ là tạo tệp recovery.conf, tệp này sẽ trỏ đến trang cái mới. Nó có thể trông như thế này:

standby_mode = 'on'
primary_conninfo = 'application_name=pgsql_node_0 host=10.0.0.103 port=5432 user=replication_user password=replication_password'
recovery_target_timeline = 'latest'
trigger_file = '/tmp/failover.trigger'

Bây giờ bạn đã sẵn sàng khởi động máy chủ dự phòng của mình và nó sẽ tái tạo từ máy chủ đang hoạt động mới.

Sao chép theo chuỗi

Có nhiều lý do tại sao bạn có thể muốn xây dựng một bản sao theo chuỗi, mặc dù nó thường được thực hiện để giảm tải trên máy chủ chính. Cung cấp WAL cho các máy chủ dự phòng sẽ làm tăng thêm một số chi phí. Không có vấn đề gì nhiều nếu bạn có một hoặc hai máy chủ ở chế độ chờ, nhưng nếu chúng ta đang nói về số lượng lớn máy chủ ở chế độ chờ, thì điều này có thể trở thành một vấn đề. Ví dụ:chúng tôi có thể giảm thiểu số lượng máy chủ dự phòng sao chép trực tiếp từ máy chủ đang hoạt động bằng cách tạo cấu trúc liên kết như sau:

Việc chuyển từ cấu trúc liên kết của hai máy chủ dự phòng sang một bản sao theo chuỗi khá đơn giản.

Bạn sẽ cần sửa đổi recovery.conf trên 10.0.0.103, hướng nó về phía 10.0.0.102 và sau đó khởi động lại PostgreSQL.

standby_mode = 'on'
primary_conninfo = 'application_name=pgsql_node_0 host=10.0.0.102 port=5432 user=replication_user password=replication_password'
recovery_target_timeline = 'latest'
trigger_file = '/tmp/failover.trigger'

Sau khi khởi động lại, 10.0.0.103 sẽ bắt đầu áp dụng các bản cập nhật WAL.

Đây là một số trường hợp thay đổi cấu trúc liên kết phổ biến. Một chủ đề không được thảo luận, nhưng vẫn quan trọng, là tác động của những thay đổi này đối với các ứng dụng. Chúng tôi sẽ đề cập vấn đề đó trong một bài đăng riêng cũng như cách làm cho các thay đổi cấu trúc liên kết này trở nên minh bạch đối với các ứng dụng.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. GeoDjango trên Windows:Không thể tìm thấy thư viện GDAL / OSError:[WinError 126] Không tìm thấy mô-đun đã chỉ định

  2. Chuyển từ MySQL sang PostgreSQL - mẹo, thủ thuật và mẹo gì?

  3. Cách justify_interval () hoạt động trong PostgreSQL

  4. Cách hiển thị giá trị rỗng khi chạy truy vấn trong psql (PostgreSQL)

  5. Cách khai báo biến trong PostgreSQL