Tự động chuyển đổi dự phòng cơ sở dữ liệu Moodle PostgreSQL

Một trong những khía cạnh quan trọng của tính sẵn sàng cao là khả năng phản ứng nhanh với các lỗi. Không có gì lạ khi quản lý cơ sở dữ liệu theo cách thủ công và có phần mềm giám sát theo dõi tình trạng cơ sở dữ liệu. Trong trường hợp không thành công, phần mềm giám sát sẽ gửi cảnh báo đến nhân viên trực. Điều này có nghĩa là ai đó có thể cần phải thức dậy, truy cập vào máy tính và đăng nhập vào hệ thống và xem nhật ký - nghĩa là, có khá nhiều thời gian trước khi quá trình khắc phục có thể bắt đầu. Tốt nhất, toàn bộ quy trình nên được tự động hóa.

Trong blog này, chúng ta sẽ xem xét cách triển khai một hệ thống hoàn toàn tự động để phát hiện khi cơ sở dữ liệu chính bị lỗi và bắt đầu quy trình chuyển đổi dự phòng bằng cách thúc đẩy cơ sở dữ liệu thứ cấp. Chúng tôi sẽ sử dụng ClusterControl để thực hiện chuyển đổi dự phòng tự động cơ sở dữ liệu Moodle PostgreSQL.

Lợi thế của Chuyển đổi Dự phòng Tự động

Ít thời gian hơn để khôi phục dịch vụ cơ sở dữ liệu
Thời gian hoạt động của hệ thống cao hơn
Ít phụ thuộc hơn vào DBA hoặc quản trị viên đã thiết lập tính sẵn sàng cao cho cơ sở dữ liệu

Kiến trúc

Hiện tại chúng tôi có một máy chủ chính của Postgres và hai máy chủ phụ trong bộ cân bằng tải HAProxy gửi lưu lượng Moodle đến nút PostgreSQL chính. Khôi phục cụm và tự động khôi phục nút trong ClusterControl là những cài đặt quan trọng để thực hiện quá trình chuyển đổi dự phòng tự động.

Kiểm soát Máy chủ nào chuyển sang Dự phòng

ClusterControl đưa ra danh sách trắng và danh sách đen của một tập hợp các máy chủ mà bạn muốn tham gia vào quá trình chuyển đổi dự phòng hoặc loại trừ với tư cách là một ứng cử viên.

Có hai biến bạn có thể đặt trong cấu hình cmon,

replication_failover_whitelist:nó chứa danh sách IP hoặc tên máy chủ của các máy chủ phụ sẽ được sử dụng làm ứng viên chính tiềm năng. Nếu biến này được đặt, chỉ những máy chủ đó mới được xem xét.
replication_failover_blacklist:nó chứa danh sách các máy chủ sẽ không bao giờ được coi là ứng cử viên chính. Bạn có thể sử dụng nó để liệt kê các máy chủ thứ cấp được sử dụng để sao lưu hoặc truy vấn phân tích. Nếu phần cứng khác nhau giữa các máy chủ phụ, bạn có thể muốn đặt ở đây các máy chủ sử dụng phần cứng chậm hơn.

Quá trình chuyển đổi dự phòng tự động

Bước 1

Chúng tôi đã bắt đầu tải dữ liệu trên máy chủ chính (192.168.33.14) bằng công cụ sysbench.

[[email protected] sysbench]# /bin/sysbench --db-driver=pgsql --oltp-table-size=100000 --oltp-tables-count=24 --threads=2 --pgsql-host=****** --pgsql-port=6543 --pgsql-user=sbtest --pgsql-password=***** --pgsql-db=sbtest /usr/share/sysbench/tests/include/oltp_legacy/parallel_prepare.lua run

sysbench 1.0.20 (using bundled LuaJIT 2.1.0-beta2)



Running the test with following options:

Number of threads: 2

Initializing random number generator from current time




Initializing worker threads...



Threads started!



thread prepare0

Creating table 'sbtest1'...

Inserting 100000 records into 'sbtest1'

Creating secondary indexes on 'sbtest1'...

Creating table 'sbtest2'...

Bước 2

Chúng tôi sẽ dừng máy chủ chính của Postgres (192.168.33.14). Trong ClusterControl, tham số (enable_cluster_autorecovery) được kích hoạt, do đó, nó sẽ thúc đẩy tham số chính phù hợp tiếp theo.

# service postgresql-12 stop

Bước 3

ClusterControl phát hiện các lỗi trong hệ thống chính và thúc đẩy hệ thống thứ cấp với dữ liệu mới nhất dưới dạng dữ liệu chính mới. Nó cũng hoạt động trên phần còn lại của các máy chủ phụ để chúng tái tạo từ máy chủ chính mới.

Trong trường hợp của chúng tôi, (192.168.33.13) là máy chủ chính mới và máy chủ phụ hiện sao chép từ máy chủ chính mới này. Giờ đây, HAProxy định tuyến lưu lượng cơ sở dữ liệu từ máy chủ Moodle đến máy chủ chính mới nhất.

Từ (192.168.33.13)

postgres=# select pg_is_in_recovery();

 pg_is_in_recovery 

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

 f

(1 row)

Từ (192.168.33.15)

postgres=# select pg_is_in_recovery();

 pg_is_in_recovery 

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

 t

(1 row)

Cấu trúc liên kết hiện tại

Khi HAProxy phát hiện thấy một trong các nút của chúng ta, là nút chính hoặc nút sao, không thể truy cập được, nó sẽ tự động đánh dấu là ngoại tuyến. HAProxy sẽ không gửi bất kỳ lưu lượng nào từ ứng dụng Moodle đến nó. Việc kiểm tra này được thực hiện bằng các tập lệnh kiểm tra tình trạng được cấu hình bởi ClusterControl tại thời điểm triển khai.

Khi ClusterControl quảng bá máy chủ bản sao thành máy chủ chính, HAProxy của chúng tôi sẽ đánh dấu máy chủ chính cũ là ngoại tuyến và đặt nút được quảng bá trực tuyến.

Sau khi máy chính cũ trực tuyến trở lại, nó sẽ không tự động đồng bộ hóa với máy chủ chính mới. Chúng ta cần đưa nó trở lại cấu trúc liên kết và nó có thể được thực hiện thông qua giao diện ClusterControl. Điều này sẽ tránh khả năng mất dữ liệu hoặc không nhất quán, trong trường hợp chúng tôi muốn điều tra lý do tại sao máy chủ đó bị lỗi ngay từ đầu.

ClusterControl sẽ phát trực tuyến sao lưu từ máy chủ chính mới và định cấu hình sao chép.

Kết luận

Tự động chuyển đổi dự phòng là một phần quan trọng của bất kỳ cơ sở dữ liệu sản xuất Moodle nào. Nó có thể giảm thời gian chết khi máy chủ gặp sự cố, cũng như khi thực hiện các tác vụ bảo trì thông thường hoặc di chuyển. Điều quan trọng là phải làm đúng, vì điều quan trọng là phần mềm chuyển đổi dự phòng phải đưa ra quyết định đúng đắn.