PostgreSQL Failover - Tôi nên sử dụng công cụ nào?

Đây là kịch bản:

Có hai máy chạy CentOS 6.2 - machine0 và machine1

Cả hai đều đã cài đặt PostgreSQL 9.1.

Một trong số chúng phải được kích hoạt, như một hệ thống chính và thông qua sao chép phát trực tuyến không đồng bộ cho máy khác, chế độ chờ sẽ sao chép các thay đổi vào cơ sở dữ liệu từ hệ thống chính.

Giả sử máy0 là máy chủ và máy1 là chế độ chờ ở đầu.

Nếu bản gốc (giả sử máy0) không thành công (lỗi ở đây có nghĩa là máy chủ postgresql gặp sự cố), chế độ chờ sẽ tiếp quản từ bản gốc và trở thành bản gốc mới.

machine1, master mới xử lý tất cả các hoạt động của cơ sở dữ liệu và khi máy chủ postgresql trong machine0 trở lại trực tuyến, nó sẽ trở thành chế độ chờ, bắt đầu đồng bộ hóa từ điểm mất liên lạc với machine1 và sao chép tất cả các thay đổi vào cơ sở dữ liệu và ở chế độ chờ.

Khi máy1 bị lỗi, toàn bộ chu trình lặp lại.

Khi chế độ chờ không thành công và trở lại trực tuyến, nó sẽ bắt đầu đọc từ bản gốc và đồng bộ hóa dữ liệu.

Tôi bối rối không biết các công cụ mà tôi cần sử dụng để thiết lập là gì vì tôi hiểu PostgreSQL không đi kèm với failover theo mặc định.

Nếu ai đó có thể liên kết tôi với các chủ đề / trang mô tả cách thực hiện những gì tôi đang cố gắng, tôi sẽ thực sự biết ơn.

Nếu bạn quan tâm đến việc sao chép và chuyển đổi dự phòng DB đồng bộ, tôi có một gợi ý. Bạn có thể xem xét bằng hai công cụ:

• DRBD (Thiết bị chặn bản sao đĩa) cung cấp bản sao cấp đĩa (đồng bộ) giữa các đĩa trên hai máy chủ khác nhau. Các thay đổi đĩa được nhân rộng qua mạng. Tốt nhất là sử dụng cáp chéo trên eth2 cho các NIC bằng cách sử dụng netblock 192.168.xx.

• ucarp cho phép quản lý DBVIP và chuyển đổi dự phòng giữa hai máy chủ khác nhau.

Bạn có thể sử dụng chúng kết hợp như sau:

• DBServer1 có IP 10.1.2.30
• DBServer2 có IP 10.1.2.40
• DB VIP là 10.1.2,70

Thiết lập ucarp trên hai máy chủ khác nhau theo cách mà mỗi phiên bản ucarp giao tiếp với nhau dọc theo ID bộ định tuyến ảo

DBServer1 sẽ có

/usr/local/sbin/ucarp -v 200 -p sometagname --interface=eth2 -a 10.1.2.70 -s 10.1.2.30 -b 3 -r 5 --upscript=/usr/local/sbin/vip-up.sh --downscript=/usr/local/sbin/vip-down.sh --neutral -z -B

DBServer2 sẽ có

/usr/local/sbin/ucarp -v 200 -p sometagname --interface=eth2 -a 10.1.2.70 -s 10.1.2.40 -b 4 -r 5 --upscript=/usr/local/sbin/vip-up.sh --downscript=/usr/local/sbin/vip-down.sh --neutral -z -B

Lý do -b (chương trình phát sóng) là 3 trên một máy chủ và 4 trên máy chủ khác là gì? Trong trường hợp cả hai máy chủ được khởi động lại, máy chủ có mức thấp nhất sẽ mang lại ucarp trước. Đối với -r, đó là tỷ lệ chết. Do đó, DBServer1 sẽ xuất hiện sau 15 giây (3x5) và DBServer2 xuất hiện sau 20 giây (4x30).

Giả sử DBServer1 gặp sự cố. ucarp trên DBServer2 sẽ kiểm tra trong 20 giây để bắt tay fro ucarp trên DBServer1. Nếu không có gì được phát hiện, tập lệnh vip-up.sh trên DBServer2 sẽ kiểm soát DBVIP.

OK tất cả điều này chỉ dành cho chuyển đổi dự phòng và quản lý DBVIP. Cơ sở dữ liệu PostgreQuery thì sao? Đáng ngạc nhiên, PostgreSQL chỉ chạy trên một máy chủ tại một thời điểm. Bất cứ ai có DBVIP nên có DRBD ở trạng thái Chính. Điều này liên quan trở lại vào kịch bản vip-up. Làm thế nào để bạn kịch bản nó?

Đây là tập lệnh /usr/local/sbin/vip-down.sh (khái niệm)

#! /bin/sh
exec 2> /dev/null
/sbin/drbdadm disconnect drbd0
/sbin/drbdadm  primary drbd0 &&
/bin/mount postgres-data-folder /mnt/drbd0
/sbin/ip addr add 10.1.2.70/24 dev eth2
/sbin/service postgres start &&
/usr/local/sbin/vipmon.sh &
touch /tmp/vip-up

Đây là tập lệnh /usr/local/sbin/vip-down.sh (khái niệm)

#! /bin/sh
exec 2> /dev/null
/sbin/service postgres stop
/bin/umount -l  /dev/drbd0
/sbin/drbdadm secondary drbd0
/sbin/ip addr del 10.1.2.70/24 dev eth2
/bin/rm /tmp/vip-up
/usr/bin/killall -9 ucarp
/usr/local/sbin/vip-down.sh
kill `ps auxww | grep vipmon | awk '{print $2}'`

Tất cả những gì bạn cần làm là thiết lập pg_hba.conf để đảm bảo tất cả người dùng đến qua 10.1.2,70

Về cơ bản, vip-up thực hiện chuỗi này

• Có DRBD đi tiểu học
• Gắn thư mục dữ liệu postgres trên / dev / drbd0
• Khởi nghiệp
• bắt đầu quá trình vipmon

Contrawise, vip-down thực hiện chuỗi này

• Tắt máy
• bỏ qua / dev / drbd0
• Có DRBD đi thứ cấp

Còn vipmon.sh thì sao? Bạn có thể kịch bản để kiểm tra, trong một vòng lặp không xác định, trạng thái của postgres (nó đang chạy), kiểm tra thiết bị DRBD (bạn vẫn có thể ghi vào thư mục dữ liệu bài viết)

Với thiết lập này, bạn có các postgres trên DRBD Primary và một bản sao cấp độ đĩa của thư mục dữ liệu postgres trên DBServer khác (DRBD thứ cấp). postgres không chạy trên DRBD thứ cấp.

Khi chuyển đổi dự phòng xảy ra, bạn chỉ cần thời gian để ucarp phát hiện là an toàn để gắn dữ liệu postgres, postgres khởi động và tạo ra tập lệnh vipmon.

Điều tuyệt vời về thiết lập này là trong trường hợp có chuyển đổi dự phòng, DBServer trở thành DRBD Chính phải có bản sao 100% cấp độ đĩa của máy chủ mà bạn đã thất bại. Do đó, bắt đầu postgres nên cấp cho bạn ở một trạng thái nhất quán. Nhật ký giao dịch (tính bằng pg_xlog) phải ở dạng thông minh (ít bị gián đoạn do chuyển đổi dự phòng)

Tôi hy vọng những gợi ý này sẽ giúp. Mặc dù tôi là một DBA của MySQL, tôi thường xuyên sử dụng MySQL và DRBD tại công ty lưu trữ web của chủ nhân. Tôi đã cài đặt MySQL / DRBD theo cách đã nói ở trên. Tôi đã làm điều này một lần cho một khách hàng sử dụng PostgreSQL / DRBD. Nó hoạt động rất tốt. Đó là mã nguồn mở. Bạn chỉ cần thực hiện sự siêng năng trong việc học DRBD và ucarp. Điều này sẽ bao gồm kết nối lại DRBD sau khi chuyển đổi dự phòng, xử lý tình huống não bị phân tách trong đó cả hai Máy chủ DB đều là Chính và những thứ như thế này.