MySQL Replication là cách rất phổ biến để xây dựng các lớp cơ sở dữ liệu có tính khả dụng cao. Nó rất nổi tiếng, đã được thử nghiệm và mạnh mẽ. Tuy nhiên, nó không phải là không có giới hạn. Một trong số đó, chắc chắn, là thực tế là nó chỉ sử dụng một “điểm vào” - bạn có một máy chủ chuyên dụng trong cấu trúc liên kết, cái chính, và nó là nút duy nhất trong cụm mà bạn có thể viết. Điều này dẫn đến những hậu quả nghiêm trọng - chính là điểm duy nhất của lỗi và nếu nó bị lỗi, ứng dụng không thể thực hiện ghi. Không có gì ngạc nhiên khi nhiều công việc đã được thực hiện trong việc phát triển các công cụ, điều này sẽ làm giảm tác động của việc mất tổng thể. Chắc chắn, có những cuộc thảo luận về cách tiếp cận chủ đề, chuyển đổi dự phòng tự động có tốt hơn thủ công hay không. Cuối cùng, đây là một quyết định kinh doanh nên thực hiện nhưng nếu bạn quyết định đi theo con đường tự động hóa, bạn sẽ tìm kiếm các công cụ để giúp bạn đạt được điều đó. Một trong những công cụ vẫn còn rất phổ biến là MHA (Master High Avability). Mặc dù có thể nó không được bảo trì tích cực nữa, nhưng nó vẫn ở một hình dạng ổn định và sự phổ biến rộng lớn của nó vẫn khiến nó trở thành xương sống của các thiết lập nhân rộng MySQL có sẵn. Tuy nhiên, điều gì sẽ xảy ra nếu bản thân MHA trở nên không khả dụng? Nó có thể trở thành một điểm thất bại duy nhất không? Có cách nào để ngăn nó xảy ra không? Trong bài đăng trên blog này, chúng ta sẽ xem xét một số tình huống.
Điều đầu tiên, nếu bạn định sử dụng MHA, hãy đảm bảo rằng bạn sử dụng phiên bản mới nhất từ repo. Không sử dụng bản phát hành nhị phân vì chúng không chứa tất cả các bản sửa lỗi. Việc cài đặt khá đơn giản. MHA bao gồm hai phần, trình quản lý và nút. Node sẽ được triển khai trên các máy chủ cơ sở dữ liệu của bạn. Trình quản lý sẽ được triển khai trên một máy chủ riêng biệt, cùng với nút. Vì vậy, máy chủ cơ sở dữ liệu:nút, máy chủ quản lý:trình quản lý và nút.
Nó khá dễ dàng để biên dịch MHA. Đi tới kho lưu trữ GitHub và sao chép.
https://github.com/yoshinorim/mha4mysql-manager
https://github.com/yoshinorim/mha4mysql-node
Sau đó, tất cả về:
perl Makefile.PL
make
make installBạn có thể phải cài đặt một số phụ thuộc perl nếu bạn chưa cài đặt tất cả các gói bắt buộc. Trong trường hợp của chúng tôi, trên Ubuntu 16.04, chúng tôi phải cài đặt phần sau:
perl -MCPAN -e "install Config::Tiny"
perl -MCPAN -e "install Log::Dispatch"
perl -MCPAN -e "install Parallel::ForkManager"
perl -MCPAN -e "install Module::Install"Khi bạn đã cài đặt MHA, bạn cần phải cấu hình nó. Chúng tôi sẽ không đi sâu vào bất kỳ chi tiết nào ở đây, có rất nhiều tài nguyên trên internet đề cập đến phần này. Cấu hình mẫu (chắc chắn là cấu hình không sản xuất) có thể trông như thế này:
[email protected]:~# cat /etc/app1.cnf
[server default]
user=cmon
password=pass
ssh_user=root
# working directory on the manager
manager_workdir=/var/log/masterha/app1
# working directory on MySQL servers
remote_workdir=/var/log/masterha/app1
[server1]
hostname=node1
candidate_master=1
[server2]
hostname=node2
candidate_master=1
[server3]
hostname=node3
no_master=1Bước tiếp theo sẽ là xem mọi thứ có hoạt động hay không và cách MHA nhìn thấy bản sao:
[email protected]:~# masterha_check_repl --conf=/etc/app1.cnf
Tue Apr 9 08:17:04 2019 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Tue Apr 9 08:17:04 2019 - [info] Reading application default configuration from /etc/app1.cnf..
Tue Apr 9 08:17:04 2019 - [info] Reading server configuration from /etc/app1.cnf..
Tue Apr 9 08:17:04 2019 - [info] MHA::MasterMonitor version 0.58.
Tue Apr 9 08:17:05 2019 - [error][/usr/local/share/perl/5.22.1/MHA/MasterMonitor.pm, ln427] Error happened on checking configurations. Redundant argument in sprintf at /usr/local/share/perl/5.22.1/MHA/NodeUtil.pm line 195.
Tue Apr 9 08:17:05 2019 - [error][/usr/local/share/perl/5.22.1/MHA/MasterMonitor.pm, ln525] Error happened on monitoring servers.
Tue Apr 9 08:17:05 2019 - [info] Got exit code 1 (Not master dead).Chà, nó bị rơi. Điều này là do MHA cố gắng phân tích cú pháp phiên bản MySQL và nó không mong đợi dấu gạch nối trong đó. May mắn thay, bản sửa lỗi rất dễ tìm:https://github.com/yoshinorim/mha4mysql-manager/issues/116.
Bây giờ, chúng tôi có MHA sẵn sàng làm việc.
[email protected]:~# masterha_manager --conf=/etc/app1.cnf
Tue Apr 9 13:00:00 2019 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Tue Apr 9 13:00:00 2019 - [info] Reading application default configuration from /etc/app1.cnf..
Tue Apr 9 13:00:00 2019 - [info] Reading server configuration from /etc/app1.cnf..
Tue Apr 9 13:00:00 2019 - [info] MHA::MasterMonitor version 0.58.
Tue Apr 9 13:00:01 2019 - [info] GTID failover mode = 1
Tue Apr 9 13:00:01 2019 - [info] Dead Servers:
Tue Apr 9 13:00:01 2019 - [info] Alive Servers:
Tue Apr 9 13:00:01 2019 - [info] node1(10.0.0.141:3306)
Tue Apr 9 13:00:01 2019 - [info] node2(10.0.0.142:3306)
Tue Apr 9 13:00:01 2019 - [info] node3(10.0.0.143:3306)
Tue Apr 9 13:00:01 2019 - [info] Alive Slaves:
Tue Apr 9 13:00:01 2019 - [info] node2(10.0.0.142:3306) Version=5.7.25-28-log (oldest major version between slaves) log-bin:enabled
Tue Apr 9 13:00:01 2019 - [info] GTID ON
Tue Apr 9 13:00:01 2019 - [info] Replicating from 10.0.0.141(10.0.0.141:3306)
Tue Apr 9 13:00:01 2019 - [info] Primary candidate for the new Master (candidate_master is set)
Tue Apr 9 13:00:01 2019 - [info] node3(10.0.0.143:3306) Version=5.7.25-28-log (oldest major version between slaves) log-bin:enabled
Tue Apr 9 13:00:01 2019 - [info] GTID ON
Tue Apr 9 13:00:01 2019 - [info] Replicating from 10.0.0.141(10.0.0.141:3306)
Tue Apr 9 13:00:01 2019 - [info] Not candidate for the new Master (no_master is set)
Tue Apr 9 13:00:01 2019 - [info] Current Alive Master: node1(10.0.0.141:3306)
Tue Apr 9 13:00:01 2019 - [info] Checking slave configurations..
Tue Apr 9 13:00:01 2019 - [info] Checking replication filtering settings..
Tue Apr 9 13:00:01 2019 - [info] binlog_do_db= , binlog_ignore_db=
Tue Apr 9 13:00:01 2019 - [info] Replication filtering check ok.
Tue Apr 9 13:00:01 2019 - [info] GTID (with auto-pos) is supported. Skipping all SSH and Node package checking.
Tue Apr 9 13:00:01 2019 - [info] Checking SSH publickey authentication settings on the current master..
Tue Apr 9 13:00:02 2019 - [info] HealthCheck: SSH to node1 is reachable.
Tue Apr 9 13:00:02 2019 - [info]
node1(10.0.0.141:3306) (current master)
+--node2(10.0.0.142:3306)
+--node3(10.0.0.143:3306)
Tue Apr 9 13:00:02 2019 - [warning] master_ip_failover_script is not defined.
Tue Apr 9 13:00:02 2019 - [warning] shutdown_script is not defined.
Tue Apr 9 13:00:02 2019 - [info] Set master ping interval 3 seconds.
Tue Apr 9 13:00:02 2019 - [warning] secondary_check_script is not defined. It is highly recommended setting it to check master reachability from two or more routes.
Tue Apr 9 13:00:02 2019 - [info] Starting ping health check on node1(10.0.0.141:3306)..
Tue Apr 9 13:00:02 2019 - [info] Ping(SELECT) succeeded, waiting until MySQL doesn't respond..Như bạn có thể thấy, MHA đang theo dõi cấu trúc liên kết sao chép của chúng tôi, kiểm tra xem nút chính có khả dụng hay không. Hãy xem xét một vài tình huống.
Tình huống 1 - MHA bị hỏng
Giả sử MHA không có sẵn. Điều này ảnh hưởng đến môi trường như thế nào? Rõ ràng, vì MHA chịu trách nhiệm theo dõi sức khỏe của chủ và kích hoạt chuyển đổi dự phòng, điều này sẽ không xảy ra khi MHA bị lỗi. Master crash sẽ không được phát hiện, chuyển đổi dự phòng sẽ không xảy ra. Vấn đề là bạn không thể thực sự chạy nhiều phiên bản MHA cùng một lúc. Về mặt kỹ thuật, bạn có thể làm điều đó mặc dù MHA sẽ phàn nàn về tệp khóa:
[email protected]:~# masterha_manager --conf=/etc/app1.cnf
Tue Apr 9 13:05:38 2019 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Tue Apr 9 13:05:38 2019 - [info] Reading application default configuration from /etc/app1.cnf..
Tue Apr 9 13:05:38 2019 - [info] Reading server configuration from /etc/app1.cnf..
Tue Apr 9 13:05:38 2019 - [info] MHA::MasterMonitor version 0.58.
Tue Apr 9 13:05:38 2019 - [warning] /var/log/masterha/app1/app1.master_status.health already exists. You might have killed manager with SIGKILL(-9), may run two or more monitoring process for the same application, or use the same working directory. Check for details, and consider setting --workdir separately.Tuy nhiên, nó sẽ bắt đầu và sẽ cố gắng giám sát môi trường. Vấn đề là khi cả hai người trong số họ bắt đầu thực hiện các hành động trên cụm. Trường hợp tồi tệ hơn sẽ là nếu họ quyết định sử dụng các nô lệ khác nhau làm ứng cử viên chính và chuyển đổi dự phòng sẽ được thực hiện cùng một lúc (MHA sử dụng tệp khóa để ngăn chuyển đổi dự phòng tiếp theo xảy ra nhưng nếu mọi thứ xảy ra cùng một lúc và nó đã xảy ra trong kiểm tra, biện pháp bảo mật này là không đủ).
Thật không may, không có một cách tích hợp nào để chạy MHA một cách khả dụng cao. Giải pháp đơn giản nhất sẽ là viết một script để kiểm tra xem MHA có đang chạy hay không và nếu không, hãy khởi động nó. Tập lệnh như vậy sẽ phải được thực thi từ cron hoặc được viết dưới dạng daemon, nếu độ chi tiết 1 phút của cron là không đủ.
Tình huống 2 - Kết nối mạng bị mất nút quản lý MHA với thiết bị chính
Thành thật mà nói, đây là một tình huống thực sự tồi tệ. Ngay khi MHA không thể kết nối với chính, nó sẽ cố gắng thực hiện chuyển đổi dự phòng. Ngoại lệ duy nhất là nếu thứ cấp_check_script được xác định và nó đã xác minh rằng cái chính còn sống. Người dùng tùy thuộc vào việc xác định chính xác những hành động mà MHA nên thực hiện để xác minh trạng thái của chính - tất cả phụ thuộc vào môi trường và thiết lập chính xác. Một tập lệnh rất quan trọng khác cần xác định là master_ip_failover_script - tập lệnh này được thực thi khi chuyển đổi dự phòng và nó nên được sử dụng, trong số những tập lệnh khác, để đảm bảo rằng bản chính cũ sẽ không hiển thị. Nếu bạn tình cờ có quyền truy cập vào các cách bổ sung để tiếp cận và ngăn chặn chủ cũ, điều đó thực sự tuyệt vời. Nó có thể là các công cụ quản lý từ xa như Integrated Lights-out, có thể truy cập vào các ổ cắm điện có thể quản lý được (nơi bạn có thể tắt nguồn máy chủ), có thể là truy cập vào CLI của nhà cung cấp dịch vụ đám mây, điều này sẽ giúp bạn có thể dừng phiên bản ảo. . Điều quan trọng nhất là phải ngăn chặn chủ cũ - nếu không có thể xảy ra rằng, sau khi sự cố mạng không còn, bạn sẽ kết thúc với hai nút có thể ghi trong hệ thống, đây là một giải pháp hoàn hảo cho bộ não bị chia cắt, một điều kiện trong đó dữ liệu phân kỳ giữa hai phần của cùng một cụm.
Như bạn thấy, MHA có thể xử lý chuyển đổi dự phòng MySQL khá tốt. Nó chắc chắn yêu cầu cấu hình cẩn thận và bạn sẽ phải viết các tập lệnh bên ngoài, những tập lệnh này sẽ được sử dụng để giết chủ cũ và đảm bảo rằng não bị chia tách sẽ không xảy ra. Đã nói rằng, chúng tôi vẫn khuyên bạn nên sử dụng các công cụ quản lý chuyển đổi dự phòng nâng cao hơn như Orchestrator hoặc ClusterControl, có thể thực hiện phân tích nâng cao hơn về trạng thái cấu trúc liên kết sao chép (ví dụ:bằng cách sử dụng các nô lệ hoặc proxy để đánh giá tính khả dụng của chủ nhân) và sẽ được duy trì trong tương lai. Nếu bạn muốn tìm hiểu cách ClusterControl thực hiện chuyển đổi dự phòng, chúng tôi muốn mời bạn đọc bài đăng trên blog này về quy trình chuyển đổi dự phòng trong ClusterControl. Bạn cũng có thể tìm hiểu cách ClusterControl tương tác với ProxySQL để cung cấp chuyển đổi dự phòng trơn tru, minh bạch cho ứng dụng của bạn. Bạn luôn có thể kiểm tra ClusterControl bằng cách tải xuống miễn phí.
