Tự động chuyển đổi dự phòng trong PostgreSQL 9.1

Làm thế nào để thiết lập hai máy chủ giống hệt nhau để chuyển đổi dự phòng tự động trong PostgreSQL 9.1.

HĐH

Centos 5
PostgreSQL 9.1 được biên dịch từ nguồn
Tài khoản người dùng postgres tồn tại trên cả hai máy và có khóa mật khẩu ssh để kết nối với cả hai máy.

Cài đặt hiện tại của tôi:

Cấu hình máy chủ chính:

postgresql.conf:

listen_address = '*'
wal_level = hot_standby
max_wal_senders = 3
checkpoint_segments = 16    
wal_keep_segments = 8 
archive_mode = on    
archive_command = 'cp "%p" /opt/pgsql91/archive/"%f"'  

pg_hba.conf:

 host  replication   all   10.0.66.1/32      trust
 host  replication   all   10.0.66.2/32      trust

Máy chủ dự phòng

postgresql.conf và pg_hba.conf giống hệt với những gì được cấu hình trên máy chủ chính.

recovery.conf:

 standby_mode = 'on'
 primary_conninfo = 'host=10.0.66.1'
 trigger_file = '/opt/pgsql91/data/trigger.txt'

Nhờ hzRoot, giờ tôi đã hiểu cách chuyển máy chủ từ chế độ chờ sang chế độ chính.

Sử dụng các lệnh sau, tôi có thể đồng bộ hóa nô lệ mới với chủ mới và sau đó nhận bản sao lưu và chạy.

Trên bản gốc mới (10.0.66.2)

1. su - postgres
2. chạm vào trigger.txt trong / opt / pssql91 / data /
3. recovery.conf trở thành recovery.done
4. psql -c "; CHỌN pg_start_backup ('sao lưu', đúng)";
5. rsync -a -v -e ssh / opt / pssql91 / data / 10.0.66.1:/opt/pgsql91/data/ --exclude postmaster.pid
6. psql -c "; CHỌN pg_stop_backup ()";

Trên nô lệ mới (10.0.66.1)

1. tạo recovery.conf: cp recovery.done để recovery.conf
2. vi recovery.conf thay đổi địa chỉ IP: chính_conninfo = 'host = 10.0.66.2'
3. bắt đầu postgresql

Vì vậy, câu hỏi của tôi bây giờ là:

1. Đây có phải là cách chính xác để chuyển đổi vai trò?
2. Có ai đã tự động quá trình này, nếu vậy bạn đã làm gì?
3. Nếu sao chép đồng bộ được bật, tôi nhận thấy máy chủ chính mới sẽ không thực hiện bất kỳ giao dịch nào vì nó đang chờ nô lệ phản hồi. Tuy nhiên, không có nô lệ vì máy chủ khác, chủ cũ bị hỏng. Điều này có đúng không hay tôi cần tạm thời vô hiệu hóa sao chép đồng bộ trong khi nô lệ mới ngừng hoạt động?

Kiểm tra repmrg :

repmgr là một bộ công cụ nguồn mở giúp các DBA và quản trị viên hệ thống quản lý một cụm cơ sở dữ liệu PostgreQuery ..

Bằng cách tận dụng khả năng của Chế độ chờ nóng được giới thiệu trong PostgreSQL 9, repmgr đơn giản hóa đáng kể quá trình thiết lập và quản lý cơ sở dữ liệu với các yêu cầu về tính sẵn sàng và khả năng mở rộng cao.

repmgr đơn giản hóa việc quản trị và quản lý hàng ngày, nâng cao năng suất và giảm chi phí chung của cụm PostgreQuery bằng cách:

• giám sát quá trình nhân rộng; cho phép các DBA phát hành cao
• hoạt động sẵn có như chuyển đổi và không thành công.

Nó làm hai việc:

1. repmgr: chương trình lệnh thực hiện các tác vụ trên cụm của bạn và sau đó thoát
2. repmgrd: quản lý và giám sát daemon theo dõi cụm và có thể tự động hóa các hành động từ xa.

Đối với chuyển đổi dự phòng tự động, repmgrd thực hiện thủ thuật và không phải là SPOF trong mạng của bạn, như pgPool. Tuy nhiên, điều quan trọng là vẫn phải giám sát tất cả các deamon và đưa chúng trở lại sau thất bại.

Phiên bản 2.0 sắp được phát hành, bao gồm cả RPM.

trong tệp recovery.conf của bạn, bạn nên thêm một dòng thông báo cho postgres chuyển đổi dự phòng từ chủ sang nô lệ. bạn nên thêm

trigger_file = '/any/file/to/trigger'

khi bạn tạo tập tin này trên đường dẫn cụ thể. các nút sẽ thay đổi. (tập tin không bao gồm bất cứ điều gì nó chỉ là một kích hoạt)

bạn có thể tìm thêm thông tin về sao chép phát trực tuyến

mặt khác, có thể làm cho nó tự động được tạo bằng một số thủ thuật nhưng sử dụng các công cụ giám sát và thực hiện thất bại trên thủ công sẽ tốt hơn ..

Có ai đã cân nhắc sử dụng pgpool-II cho việc này chưa?

http://pgpool.projects.postgresql.org/contrib_docs/simple_sr_setting/index.html

Tôi thiết lập sao chép cho PostgreSQL. Có vẻ như phần khó khăn xảy ra khi chủ cũ quay trở lại.

Từ những gì tôi đã đọc, pgpool dường như có thể tự động hóa hầu hết điều đó. Tuy nhiên tôi không chắc có tận dụng các tính năng sao chép đã có trong PostgreQuery 9.1 hay không.