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

Cách xây dựng lại một PostgreSQL Slave không nhất quán

PostgreSQL Streaming Replication là một cách tuyệt vời để mở rộng các cụm PostgreSQL và làm điều đó giúp tăng tính khả dụng cao cho chúng. Như với mọi bản sao, ý tưởng là nô lệ là một bản sao của chủ và nô lệ được cập nhật liên tục với những thay đổi đã xảy ra trên bản chính bằng cách sử dụng một số loại cơ chế sao chép.

Có thể xảy ra trường hợp nô lệ, vì lý do nào đó, không đồng bộ với chủ. Làm cách nào để đưa nó trở lại chuỗi nhân rộng? Làm cách nào để tôi có thể đảm bảo rằng máy chủ nô lệ lại được đồng bộ hóa với máy chủ? Hãy xem qua bài đăng blog ngắn này.

Điều rất hữu ích, không có cách nào để viết trên nô lệ nếu nó đang ở chế độ khôi phục. Bạn có thể kiểm tra nó như vậy:

postgres=# SELECT pg_is_in_recovery();

 pg_is_in_recovery

-------------------

 t

(1 row)

postgres=# CREATE DATABASE mydb;

ERROR:  cannot execute CREATE DATABASE in a read-only transaction

Vẫn có thể xảy ra trường hợp nô lệ không đồng bộ với chủ. Dữ liệu bị hỏng - cả phần cứng hay phần mềm đều không có lỗi và sự cố. Một số vấn đề với ổ đĩa có thể gây ra lỗi dữ liệu trên máy phụ. Một số vấn đề với quy trình "chân không" có thể dẫn đến dữ liệu bị thay đổi. Làm thế nào để khôi phục từ trạng thái đó?

Xây dựng lại Slave bằng pg_basebackup

Bước chính là cung cấp máy chủ sử dụng dữ liệu từ máy chủ. Vì chúng tôi sẽ sử dụng sao chép trực tuyến, chúng tôi không thể sử dụng sao lưu hợp lý. May mắn thay, có một công cụ sẵn sàng có thể được sử dụng để thiết lập mọi thứ:pg_basebackup. Hãy xem các bước chúng ta cần thực hiện để cung cấp một máy chủ nô lệ là gì. Để làm rõ hơn, chúng tôi đang sử dụng PostgreSQL 12 cho mục đích của bài đăng blog này.

Trạng thái ban đầu là đơn giản. Nô lệ của chúng ta không sao chép từ chủ nhân của nó. Dữ liệu trong đó bị hỏng và không thể sử dụng cũng như không đáng tin cậy. Do đó, bước đầu tiên chúng tôi sẽ làm là dừng PostgreSQL trên máy chủ của chúng tôi và xóa dữ liệu mà nó chứa:

[email protected]:~# systemctl stop postgresql

Hoặc thậm chí:

[email protected]:~# killall -9 postgres

Bây giờ, hãy kiểm tra nội dung của tệp postgresql.auto.conf, chúng ta có thể sử dụng thông tin đăng nhập nhân rộng được lưu trữ trong tệp đó sau này, cho pg_basebackup:

[email protected]:~# cat /var/lib/postgresql/12/main/postgresql.auto.conf

# Do not edit this file manually!

# It will be overwritten by the ALTER SYSTEM command.

promote_trigger_file='/tmp/failover_5432.trigger'

recovery_target_timeline=latest

primary_conninfo='application_name=pgsql_0_node_1 host=10.0.0.126 port=5432 user=cmon_replication password=qZnVoV7LV97CFX9F'

Chúng tôi quan tâm đến người dùng và mật khẩu được sử dụng để thiết lập bản sao.

Cuối cùng, chúng tôi có thể xóa dữ liệu:

[email protected]:~# rm -rf /var/lib/postgresql/12/main/*

Sau khi dữ liệu bị xóa, chúng ta cần sử dụng pg_basebackup để lấy dữ liệu từ cái chính:

[email protected]:~# pg_basebackup -h 10.0.0.126 -U cmon_replication -Xs -P -R -D /var/lib/postgresql/12/main/

Password:

waiting for checkpoint

Các cờ mà chúng tôi sử dụng có ý nghĩa sau:

  • -Xs:chúng tôi muốn phát trực tuyến WAL trong khi tạo bản sao lưu. Điều này giúp tránh các vấn đề với việc xóa tệp WAL khi bạn có một tập dữ liệu lớn.
  • -P:chúng tôi muốn xem tiến trình của quá trình sao lưu.
  • -R:chúng tôi muốn pg_basebackup tạo tệp standby.signal và chuẩn bị tệp postgresql.auto.conf với cài đặt kết nối.

pg_basebackup sẽ đợi điểm kiểm tra trước khi bắt đầu sao lưu. Nếu mất quá nhiều thời gian, bạn có thể sử dụng hai tùy chọn. Đầu tiên, có thể đặt chế độ điểm kiểm tra thành nhanh trong pg_basebackup bằng cách sử dụng tùy chọn ‘-c fast’. Ngoài ra, bạn có thể buộc kiểm tra bằng cách thực hiện:

postgres=# CHECKPOINT;

CHECKPOINT

Bằng cách này hay cách khác, pg_basebackup sẽ bắt đầu. Với cờ -P, chúng tôi có thể theo dõi tiến trình:

 416906/1588478 kB (26%), 0/1 tablespaceceace

Khi quá trình sao lưu đã sẵn sàng, tất cả những gì chúng ta phải làm là đảm bảo nội dung thư mục dữ liệu có người dùng và nhóm được chỉ định chính xác - chúng tôi đã thực thi pg_basebackup là 'root', do đó chúng tôi muốn đổi nó thành 'postgres ':

[email protected]:~# chown -R postgres.postgres /var/lib/postgresql/12/main/

Đó là tất cả, chúng ta có thể khởi động nô lệ và nó sẽ bắt đầu sao chép từ bản chính.

[email protected]:~# systemctl start postgresql

Bạn có thể kiểm tra kỹ tiến trình sao chép bằng cách thực hiện truy vấn sau trên trang cái:

postgres=# SELECT * FROM pg_stat_replication;

  pid  | usesysid |     usename | application_name | client_addr | client_hostname | client_port |         backend_start | backend_xmin | state | sent_lsn | write_lsn | flush_lsn | replay_lsn | write_lag | flush_lag | replay_lag | sync_priority | sync_state |          reply_time

-------+----------+------------------+------------------+-------------+-----------------+-------------+-------------------------------+--------------+-----------+------------+------------+------------+------------+-----------+-----------+------------+---------------+------------+-------------------------------

 23565 |    16385 | cmon_replication | pgsql_0_node_1   | 10.0.0.128 | | 51554 | 2020-02-27 15:25:00.002734+00 |              | streaming | 2/AA5EF370 | 2/AA5EF2B0 | 2/AA5EF2B0 | 2/AA5EF2B0 | | |         | 0 | async | 2020-02-28 13:45:32.594213+00

 11914 |    16385 | cmon_replication | 12/main          | 10.0.0.127 | | 25058 | 2020-02-28 13:42:09.160576+00 |              | streaming | 2/AA5EF370 | 2/AA5EF2B0 | 2/AA5EF2B0 | 2/AA5EF2B0 | | |         | 0 | async | 2020-02-28 13:45:42.41722+00

(2 rows)

Như bạn có thể thấy, cả hai nô lệ đều đang sao chép chính xác.

Xây dựng lại Slave bằng ClusterControl

Nếu bạn là người dùng ClusterControl, bạn có thể dễ dàng đạt được điều đó giống hệt nhau chỉ bằng cách chọn một tùy chọn từ giao diện người dùng.

Tình huống ban đầu là một trong các nô lệ (10.0.0.127) là không hoạt động và nó không tái tạo. Chúng tôi cho rằng việc xây dựng lại là lựa chọn tốt nhất cho chúng tôi.

Là người dùng ClusterControl, tất cả những gì chúng ta phải làm là truy cập “Nút ”Và chạy công việc“ Rebuild Replication Slave ”.

Tiếp theo, chúng ta phải chọn nút để xây dựng lại nô lệ từ đó tất cả các. ClusterControl sẽ sử dụng pg_basebackup để thiết lập nô lệ nhân bản và định cấu hình sao chép ngay khi dữ liệu được truyền.

Sau một thời gian, công việc hoàn thành và nô lệ trở lại chuỗi sao chép:

Như bạn có thể thấy, chỉ với một vài cú nhấp chuột, nhờ ClusterControl, chúng tôi đã xây dựng lại nô lệ bị lỗi của mình và đưa nó trở lại cụm.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Tên cột PL / pgSQL giống như biến

  2. Ứng dụng Spring Boot bị kẹt trên Hikari-Pool-1 - Đang khởi động ...

  3. Postgres sao chép Heroku Production DB sang DB phát triển cục bộ

  4. PostgreSQL 11:Có gì mới

  5. Chọn dữ liệu vào một mảng Postgres