Tầm quan trọng của chuyển đổi dự phòng
Chuyển đổi dự phòng là một trong những cách thực hành cơ sở dữ liệu quan trọng nhất để quản trị cơ sở dữ liệu. Nó hữu ích không chỉ khi quản lý cơ sở dữ liệu lớn trong quá trình sản xuất mà còn nếu bạn muốn đảm bảo rằng hệ thống của mình luôn sẵn sàng bất cứ khi nào bạn truy cập - đặc biệt là ở cấp ứng dụng.
Trước khi chuyển đổi dự phòng có thể diễn ra, các cá thể cơ sở dữ liệu của bạn phải đáp ứng các yêu cầu nhất định. Trên thực tế, những yêu cầu này rất quan trọng đối với tính khả dụng cao. Một trong những yêu cầu mà các cá thể cơ sở dữ liệu của bạn phải đáp ứng là tính dự phòng. Dự phòng cho phép tiến hành chuyển đổi dự phòng, trong đó dự phòng được thiết lập để có một ứng cử viên chuyển đổi dự phòng có thể là một nút sao (phụ) hoặc từ một nhóm các bản sao hoạt động như các nút dự phòng hoặc nóng dự phòng. Ứng cử viên được chọn theo cách thủ công hoặc tự động dựa trên nút nâng cao hoặc cập nhật nhất. Thông thường, bạn sẽ muốn có một bản sao ở chế độ chờ nóng vì nó có thể lưu cơ sở dữ liệu của bạn khỏi việc kéo các chỉ mục từ đĩa vì chế độ chờ nóng thường đưa các chỉ mục vào vùng đệm cơ sở dữ liệu.
Chuyển đổi dự phòng là thuật ngữ được sử dụng để mô tả rằng một quá trình khôi phục đã xảy ra. Trước quá trình khôi phục, điều này xảy ra khi một nút cơ sở dữ liệu chính (hoặc chính) bị lỗi sau sự cố, sau thiên tai, sau sự cố phần cứng hoặc nó có thể bị phân vùng mạng; đây là những trường hợp phổ biến nhất khiến quá trình chuyển đổi dự phòng có thể diễn ra. Quá trình khôi phục thường tiến hành tự động và sau đó tìm kiếm thứ cấp (bản sao) mong muốn nhất và cập nhật nhất như đã nêu trước đây.
Chuyển đổi dự phòng nâng cao
Mặc dù quy trình khôi phục trong quá trình chuyển đổi dự phòng là tự động, nhưng có một số trường hợp không cần thiết phải tự động hóa quy trình và quy trình thủ công phải thực hiện. Sự phức tạp thường được xem xét chính liên quan đến các công nghệ bao gồm toàn bộ ngăn xếp cơ sở dữ liệu của bạn - chuyển đổi dự phòng tự động cũng có thể được kết hợp với chuyển đổi dự phòng thủ công.
Trong hầu hết các cân nhắc hàng ngày về việc quản lý cơ sở dữ liệu, phần lớn các mối quan tâm xung quanh chuyển đổi dự phòng tự động thực sự không hề nhỏ. Nó thường rất hữu ích để triển khai và thiết lập chuyển đổi dự phòng tự động trong trường hợp có sự cố xảy ra. Mặc dù điều đó nghe có vẻ hứa hẹn vì nó bao hàm sự phức tạp, nhưng vẫn có các cơ chế chuyển đổi dự phòng tiên tiến và liên quan đến các sự kiện "trước" và các sự kiện "sau" được gắn như móc nối trong phần mềm hoặc công nghệ chuyển đổi dự phòng.
Các sự kiện trước và sau này đi kèm với kiểm tra hoặc một số hành động nhất định phải thực hiện trước khi nó có thể tiến hành chuyển đổi dự phòng cuối cùng và sau khi chuyển đổi dự phòng xong, hãy dọn dẹp một số để đảm bảo rằng chuyển đổi dự phòng cuối cùng thành công một. May mắn thay, có sẵn các công cụ cho phép, không chỉ Tự động chuyển đổi dự phòng mà còn có khả năng áp dụng các móc tập lệnh trước và sau.
Trong blog này, chúng tôi sẽ sử dụng chuyển đổi dự phòng tự động ClusterControl (CC) và sẽ giải thích cách sử dụng các hook script trước và sau khi chúng áp dụng cho cụm nào.
Chuyển đổi dự phòng sao chép ClusterControl
Cơ chế chuyển đổi dự phòng ClusterControl có thể áp dụng hiệu quả trên sao chép không đồng bộ áp dụng cho các biến thể MySQL (MySQL / Percona Server / MariaDB). Nó cũng áp dụng cho các cụm PostgreSQL / TimescaleDB - ClusterControl hỗ trợ sao chép trực tuyến. Các cụm MongoDB và Galera có cơ chế riêng để chuyển đổi dự phòng tự động được tích hợp trong công nghệ cơ sở dữ liệu của riêng nó. Đọc thêm về cách ClusterControl thực hiện khôi phục cơ sở dữ liệu tự động và chuyển đổi dự phòng.
Chuyển đổi dự phòng ClusterControl không hoạt động trừ khi khôi phục Node và cụm (Tự động khôi phục được bật). Điều đó có nghĩa là các nút này phải có màu xanh lục.
Tài liệu cho biết rằng các tùy chọn cấu hình này cũng có thể được sử dụng để bật / vô hiệu hóa những điều sau:
| enable_cluster_autorecovery = |
|
| enable_node_autorecovery = |
|
$ systemctl khởi động lại cmon
Đối với blog này, chúng tôi chủ yếu tập trung vào cách sử dụng các móc tập lệnh trước / sau, về cơ bản là một lợi thế lớn cho chuyển đổi dự phòng sao chép nâng cao.
Hỗ trợ tập lệnh trước / sau sao chép dự phòng cụm chuyển đổi dự phòng
Như đã đề cập trước đó, các biến thể MySQL sử dụng sao chép không đồng bộ (bao gồm cả bán đồng bộ) và sao chép trực tuyến cho PostgreSQL / TimescaleDB hỗ trợ cơ chế này. ClusterControl có các tùy chọn cấu hình sau đây có thể được sử dụng cho các hook script trước và sau. Về cơ bản, các tùy chọn cấu hình này có thể được đặt thông qua tệp cấu hình của chúng hoặc có thể được đặt thông qua giao diện người dùng web (chúng tôi sẽ giải quyết vấn đề này sau).
Tài liệu của chúng tôi nói rằng đây là các tùy chọn cấu hình sau đây có thể thay đổi cơ chế chuyển đổi dự phòng bằng cách sử dụng các hook script trước / sau:
| replication_pre_failover_script = |
|
| replication_post_failover_script = |
|
| replication_post_unsuccessful_failover_script = |
|
Về mặt kỹ thuật, khi bạn đặt các tùy chọn cấu hình sau trong tệp cấu hình /etc/cmon.d/cmon_
$ systemctl restart cmon Ngoài ra, bạn cũng có thể đặt các tùy chọn cấu hình bằng cách đi tới
Cách tiếp cận này sẽ vẫn yêu cầu khởi động lại dịch vụ cmon trước khi nó có thể phản ánh các thay đổi được thực hiện cho các tùy chọn cấu hình này đối với các móc tập lệnh trước / sau.
Ví dụ về hook script trước / sau
Lý tưởng nhất là các hook script trước / sau được dành riêng khi bạn cần chuyển đổi dự phòng nâng cao mà ClusterControl không thể quản lý sự phức tạp của thiết lập cơ sở dữ liệu của bạn. Ví dụ:nếu bạn đang chạy các trung tâm dữ liệu khác nhau với bảo mật được thắt chặt và bạn muốn xác định xem cảnh báo mạng không thể truy cập được có phải là cảnh báo dương tính giả hay không. Nó phải kiểm tra xem cái chính và cái phụ có thể kết nối với nhau hay không và ngược lại, nó cũng có thể tiếp cận từ các nút cơ sở dữ liệu đến máy chủ ClusterControl.
Hãy làm điều đó trong ví dụ của chúng tôi và chứng minh cách bạn có thể hưởng lợi từ nó.
Chi tiết máy chủ và tập lệnh
Trong ví dụ này, tôi đang sử dụng một cụm Sao chép MariaDB chỉ với một bản sao chính và một bản sao. Được quản lý bởi ClusterControl để quản lý chuyển đổi dự phòng.
ClusterControl =192.168.40.110
primary (debnode5) =192.168.30.50
bản sao (debnode9) =192.168.30.90
Trong nút chính, hãy tạo tập lệnh như đã nêu bên dưới,
[email protected]:~# cat /opt/pre_failover.sh
#!/bin/bash
date -u +%s | ssh -i /home/vagrant/.ssh/id_rsa [email protected] -T "cat >> /tmp/debnode5.tmp"Đảm bảo rằng /opt/pre_failover.sh có thể thực thi được, tức là
$ chmod +x /opt/pre_failover.shSau đó, sử dụng tập lệnh này để tham gia qua cron. Trong ví dụ này, tôi đã tạo một tệp /etc/cron.d/ccfailover và có các nội dung sau:
[email protected]:~# cat /etc/cron.d/ccfailover
#!/bin/bash
* * * * * vagrant /opt/pre_failover.shTrong bản sao của bạn, chỉ cần sử dụng các bước sau mà chúng tôi đã làm cho bản chính ngoại trừ thay đổi tên máy chủ. Xem phần sau của những gì tôi có bên dưới trong bản sao của mình:
[email protected]:~# tail -n+1 /etc/cron.d/ccfailover /opt/pre_failover.sh
==> /etc/cron.d/ccfailover <==
#!/bin/bash
* * * * * vagrant /opt/pre_failover.sh
==> /opt/pre_failover.sh <==
#!/bin/bash
date -u +%s | ssh -i /home/vagrant/.ssh/id_rsa [email protected] -T "cat > /tmp/debnode9.tmp"và đảm bảo rằng tập lệnh được gọi trong cron của chúng tôi có thể thực thi được,
[email protected]:~# ls -alth /opt/pre_failover.sh
-rwxr-xr-x 1 root root 104 Jun 14 05:09 /opt/pre_failover.shTập lệnh trước / sau của ClusterControl
Trong phần trình diễn này, cluster_id của tôi là 3. Như đã nêu trước đó trong tài liệu của chúng tôi, nó yêu cầu các tập lệnh này phải nằm trong máy chủ điều khiển CC của chúng tôi. Vì vậy, trong /etc/cmon.d/cmon_3.cnf của tôi, tôi có những thứ sau:
[[email protected] cmon.d]# tail -n3 /etc/cmon.d/cmon_3.cnf
replication_pre_failover_script = /etc/cmon.d/failover/replication_failover_pre_clus3.sh
replication_post_failover_script = /etc/cmon.d/failover/replication_failover_post_clus3.sh
replication_post_unsuccessful_failover_script = /etc/cmon.d/failover/replication_unsuccessful_failover_post_clus3.shTrong khi đó, tập lệnh chuyển đổi dự phòng "trước" sau sẽ xác định xem cả hai nút có thể truy cập máy chủ điều khiển CC hay không. Xem phần sau:
[[email protected] cmon.d]# tail -n+1 /etc/cmon.d/failover/replication_failover_pre_clus3.sh
#!/bin/bash
arg1=$1
debnode5_tstamp=$(tail /tmp/debnode5.tmp)
debnode9_tstamp=$(tail /tmp/debnode9.tmp)
cc_tstamp=$(date -u +%s)
diff_debnode5=$(expr $cc_tstamp - $debnode5_tstamp)
diff_debnode9=$(expr $cc_tstamp - $debnode5_tstamp)
if [[ "$diff_debnode5" -le 60 && "$diff_debnode9" -le 60 ]]; then
echo "failover cannot proceed. It's just a false alarm. Checkout the firewall in your CC host";
exit 1;
elif [[ "$diff_debnode5" -gt 60 || "$diff_debnode9" -gt 60 ]]; then
echo "Either both nodes ($arg1) or one of them were not able to connect the CC host. One can be unreachable. Failover proceed!";
exit 0;
else
echo "false alarm. Failover discarded!"
exit 1;
fi
Whereas my post scripts just simply echoes and redirects the output to a file, just for the test.
[[email protected] failover]# tail -n+1 replication_*_post*3.sh
==> replication_failover_post_clus3.sh <==
#!/bin/bash
echo "post failover script on cluster 3 with args: [email protected]" > /tmp/post_failover_script_cid3.txt
==> replication_unsuccessful_failover_post_clus3.sh <==
#!/bin/bash
echo "post unsuccessful failover script on cluster 3 with args: [email protected]" > /tmp/post_unsuccessful_failover_script_cid3.txt
Demo chuyển đổi dự phòng
Bây giờ, chúng ta hãy thử mô phỏng sự cố mất mạng trên nút chính và xem nó sẽ phản ứng như thế nào. Trong nút chính của mình, tôi gỡ bỏ giao diện mạng được sử dụng để giao tiếp với bản sao và bộ điều khiển CC.
[email protected]:~# ip link set enp0s8 downTrong lần thử chuyển đổi dự phòng đầu tiên, CC đã có thể chạy tập lệnh trước của tôi được đặt tại /etc/cmon.d/failover/replication_failover_pre_clus3.sh. Xem bên dưới cách nó hoạt động:
Rõ ràng là nó không thành công vì dấu thời gian đã được ghi chưa quá một phút hoặc chỉ cách đây vài giây mà bộ điều khiển chính vẫn có thể kết nối với bộ điều khiển CC. Rõ ràng, đó không phải là cách tiếp cận hoàn hảo khi bạn đang đối phó với một kịch bản thực tế. Tuy nhiên, ClusterControl đã có thể gọi và thực thi tập lệnh một cách hoàn hảo như mong đợi. Bây giờ, nếu nó thực sự đạt hơn một phút (tức là> 60 giây) thì sao?
Trong lần thử chuyển đổi dự phòng thứ hai của chúng tôi, vì dấu thời gian đạt hơn 60 giây nên dấu thời gian đó được coi là số dương thực sự và điều đó có nghĩa là chúng tôi phải chuyển đổi dự phòng như dự định. CC đã có thể thực thi nó một cách hoàn hảo và thậm chí thực thi kịch bản bài đăng như dự định. Điều này có thể được nhìn thấy trong nhật ký công việc. Xem ảnh chụp màn hình bên dưới:
Xác minh xem tập lệnh bài đăng của tôi đã chạy hay chưa, nó có thể tạo nhật ký tệp trong thư mục CC / tmp như mong đợi,
[[email protected] tmp]# cat /tmp/post_failover_script_cid3.txtđăng tập lệnh chuyển đổi dự phòng trên cụm 3 với args:192.168.30.50 192.168.30.90 192.168.30.50 192.168.30.90 192.168.30.90
Bây giờ, cấu trúc liên kết của tôi đã được thay đổi và chuyển đổi dự phòng thành công!
Kết luận
Đối với bất kỳ thiết lập cơ sở dữ liệu phức tạp nào mà bạn có thể có, khi cần chuyển đổi dự phòng nâng cao, các tập lệnh trước / sau có thể rất hữu ích để giúp mọi thứ có thể đạt được. Vì ClusterControl hỗ trợ các tính năng này, chúng tôi đã chứng minh nó mạnh mẽ và hữu ích như thế nào. Ngay cả với những hạn chế của nó, luôn có những cách để làm cho mọi thứ có thể đạt được và hữu ích, đặc biệt là trong môi trường sản xuất.
