Trong các blog trước đây của chúng tôi, chúng tôi đã thảo luận về MHA như một công cụ chuyển đổi dự phòng được sử dụng trong các thiết lập chủ-nô MySQL. Tháng trước, chúng tôi cũng đã viết blog về cách xử lý MHA khi nó gặp sự cố. Hôm nay, chúng ta sẽ xem các vấn đề hàng đầu mà DBA thường gặp phải với MHA và cách bạn có thể khắc phục chúng.
Giới thiệu tóm tắt về MHA (Tính khả dụng cao chính)
MHA là viết tắt của (Tính sẵn sàng cao) vẫn còn liên quan và được sử dụng rộng rãi cho đến ngày nay, đặc biệt là trong các thiết lập chủ-tớ dựa trên sao chép không phải GTID. MHA thực hiện tốt việc chuyển đổi dự phòng hoặc chuyển đổi tổng thể, nhưng nó đi kèm với một số cạm bẫy và hạn chế. Khi MHA thực hiện chuyển đổi dự phòng chính và xúc tiến nô lệ, nó có thể tự động hoàn thành hoạt động chuyển đổi dự phòng cơ sở dữ liệu trong vòng ~ 30 giây, điều này có thể chấp nhận được trong môi trường sản xuất. MHA có thể đảm bảo tính nhất quán của dữ liệu. Tất cả điều này không làm giảm hiệu suất và không yêu cầu điều chỉnh hoặc thay đổi bổ sung đối với các triển khai hoặc thiết lập hiện có của bạn. Ngoài ra, MHA được xây dựng dựa trên Perl và là một giải pháp HA mã nguồn mở - vì vậy việc tạo trợ giúp hoặc mở rộng công cụ phù hợp với thiết lập mong muốn của bạn là tương đối dễ dàng. Hãy xem bản trình bày này để biết thêm thông tin.
Phần mềm MHA bao gồm hai thành phần, bạn cần cài đặt một trong các gói sau phù hợp với vai trò cấu trúc liên kết của nó:
Nút trình quản lý MHA =Trình quản lý MHA (người quản lý) / Nút MHA (nút dữ liệu)
Nút Master / Slave =MHA Node (nút dữ liệu)
MHA Manager là phần mềm quản lý chuyển đổi dự phòng (tự động hoặc thủ công), đưa ra quyết định về thời gian và địa điểm cần chuyển đổi dự phòng, đồng thời quản lý việc khôi phục nô lệ trong quá trình thúc đẩy chủ ứng viên để áp dụng nhật ký chuyển tiếp khác biệt. Nếu cơ sở dữ liệu chính bị chết, MHA Manager sẽ phối hợp với tác nhân MHA Node vì nó áp dụng nhật ký chuyển tiếp khác biệt cho các nô lệ không có các sự kiện binlog mới nhất từ chính. Phần mềm MHA Node là một tác nhân cục bộ sẽ giám sát phiên bản MySQL của bạn và cho phép Trình quản lý MHA sao chép nhật ký chuyển tiếp từ các nô lệ. Kịch bản điển hình là khi ứng viên tổng thể cho chuyển đổi dự phòng hiện đang bị trễ và MHA phát hiện nó không có nhật ký chuyển tiếp mới nhất. Do đó, nó sẽ đợi lệnh của MHA Manager khi nó tìm kiếm nô lệ mới nhất có chứa các sự kiện binlog và sao chép các sự kiện còn thiếu từ nô lệ bằng cách sử dụng scp và áp dụng chúng cho chính nó.
Xin lưu ý rằng MHA hiện không được bảo trì tích cực, nhưng bản thân phiên bản hiện tại đã ổn định và có thể “đủ tốt” để sản xuất. Bạn vẫn có thể lặp lại giọng nói của mình qua github để giải quyết một số vấn đề hoặc cung cấp các bản vá cho phần mềm.
Các vấn đề phổ biến hàng đầu
Bây giờ, hãy xem xét các vấn đề phổ biến nhất mà một DBA sẽ gặp phải khi sử dụng MHA.
Slave bị trễ, chuyển đổi dự phòng không tương tác / tự động không thành công!
Đây là một sự cố điển hình khiến chuyển đổi dự phòng tự động bị hủy bỏ hoặc không thành công. Điều này nghe có vẻ đơn giản nhưng nó không chỉ đến một vấn đề cụ thể. Slave lag có thể do các lý do khác nhau:
- Các vấn đề về đĩa trên ứng cử viên chính khiến nó trở thành đĩa I / O bị ràng buộc để xử lý đọc và ghi. Nó cũng có thể dẫn đến hỏng dữ liệu nếu không được giảm thiểu.
- Các truy vấn không hợp lệ được sao chép, đặc biệt là các bảng không có khóa chính hoặc chỉ mục được nhóm lại.
- tải máy chủ cao.
- Máy chủ nguội và máy chủ vẫn chưa nóng lên
- Không đủ tài nguyên máy chủ. Có thể máy chủ của bạn có bộ nhớ hoặc tài nguyên máy chủ quá thấp trong khi sao chép các thao tác ghi hoặc đọc chuyên sâu cao.
Những điều đó có thể được giảm thiểu trước nếu bạn có sự giám sát thích hợp đối với cơ sở dữ liệu của mình. Một ví dụ liên quan đến độ trễ nô lệ trong MHA là bộ nhớ thấp khi kết xuất tệp nhật ký nhị phân lớn. Như một ví dụ bên dưới, một trang cái được đánh dấu là đã chết và nó phải thực hiện chuyển đổi dự phòng không tương tác / tự động. Tuy nhiên, vì ứng cử viên chủ bị trễ và nó phải áp dụng các nhật ký chưa được thực thi bởi các chuỗi nhân bản, MHA sẽ xác định vị trí nô lệ cập nhật nhất hoặc mới nhất vì nó sẽ cố gắng khôi phục một nô lệ so với nô lệ cũ nhất những cái. Do đó, như bạn có thể thấy bên dưới, trong khi nó đang thực hiện khôi phục nô lệ, bộ nhớ quá thấp:
[email protected]:~$ masterha_manager --conf=/etc/app1.cnf --remove_dead_master_conf --ignore_last_failover
Mon May 6 08:43:46 2019 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Mon May 6 08:43:46 2019 - [info] Reading application default configuration from /etc/app1.cnf..
Mon May 6 08:43:46 2019 - [info] Reading server configuration from /etc/app1.cnf..
…
Mon May 6 08:43:57 2019 - [info] Checking master reachability via MySQL(double check)...
Mon May 6 08:43:57 2019 - [info] ok.
Mon May 6 08:43:57 2019 - [info] Alive Servers:
Mon May 6 08:43:57 2019 - [info] 192.168.10.50(192.168.10.50:3306)
Mon May 6 08:43:57 2019 - [info] 192.168.10.70(192.168.10.70:3306)
Mon May 6 08:43:57 2019 - [info] Alive Slaves:
Mon May 6 08:43:57 2019 - [info] 192.168.10.50(192.168.10.50:3306) Version=5.7.23-23-log (oldest major version between slaves) log-bin:enabled
Mon May 6 08:43:57 2019 - [info] Replicating from 192.168.10.60(192.168.10.60:3306)
Mon May 6 08:43:57 2019 - [info] Primary candidate for the new Master (candidate_master is set)
Mon May 6 08:43:57 2019 - [info] 192.168.10.70(192.168.10.70:3306) Version=5.7.23-23-log (oldest major version between slaves) log-bin:enabled
Mon May 6 08:43:57 2019 - [info] Replicating from 192.168.10.60(192.168.10.60:3306)
Mon May 6 08:43:57 2019 - [info] Not candidate for the new Master (no_master is set)
Mon May 6 08:43:57 2019 - [info] Starting Non-GTID based failover.
….
Mon May 6 08:43:59 2019 - [info] * Phase 3.4: New Master Diff Log Generation Phase..
Mon May 6 08:43:59 2019 - [info]
Mon May 6 08:43:59 2019 - [info] Server 192.168.10.50 received relay logs up to: binlog.000004:106167341
Mon May 6 08:43:59 2019 - [info] Need to get diffs from the latest slave(192.168.10.70) up to: binlog.000005:240412 (using the latest slave's relay logs)
Mon May 6 08:43:59 2019 - [info] Connecting to the latest slave host 192.168.10.70, generating diff relay log files..
Mon May 6 08:43:59 2019 - [info] Executing command: apply_diff_relay_logs --command=generate_and_send --scp_user=vagrant --scp_host=192.168.10.50 --latest_mlf=binlog.000005 --latest_rmlp=240412 --target_mlf=binlog.000004 --target_rmlp=106167341 --server_id=3 --diff_file_readtolatest=/tmp/relay_from_read_to_latest_192.168.10.50_3306_20190506084355.binlog --workdir=/tmp --timestamp=20190506084355 --handle_raw_binlog=1 --disable_log_bin=0 --manager_version=0.58 --relay_dir=/var/lib/mysql --current_relay_log=relay-bin.000007
Mon May 6 08:44:00 2019 - [info]
Relay log found at /var/lib/mysql, up to relay-bin.000007
Fast relay log position search failed. Reading relay logs to find..
Reading relay-bin.000007
Binlog Checksum enabled
Master Version is 5.7.23-23-log
Binlog Checksum enabled
…
…...
Target relay log file/position found. start_file:relay-bin.000004, start_pos:106167468.
Concat binary/relay logs from relay-bin.000004 pos 106167468 to relay-bin.000007 EOF into /tmp/relay_from_read_to_latest_192.168.10.50_3306_20190506084355.binlog ..
Binlog Checksum enabled
Binlog Checksum enabled
Dumping binlog format description event, from position 0 to 361.. ok.
Dumping effective binlog data from /var/lib/mysql/relay-bin.000004 position 106167468 to tail(1074342689)..Out of memory!
Mon May 6 08:44:00 2019 - [error][/usr/local/share/perl/5.26.1/MHA/MasterFailover.pm, ln1090] Generating diff files failed with return code 1:0.
Mon May 6 08:44:00 2019 - [error][/usr/local/share/perl/5.26.1/MHA/MasterFailover.pm, ln1584] Recovering master server failed.
Mon May 6 08:44:00 2019 - [error][/usr/local/share/perl/5.26.1/MHA/ManagerUtil.pm, ln178] Got ERROR: at /usr/local/bin/masterha_manager line 65.
Mon May 6 08:44:00 2019 - [info]
----- Failover Report -----
app1: MySQL Master failover 192.168.10.60(192.168.10.60:3306)
Master 192.168.10.60(192.168.10.60:3306) is down!
Check MHA Manager logs at testnode20 for details.
Started automated(non-interactive) failover.
Invalidated master IP address on 192.168.10.60(192.168.10.60:3306)
The latest slave 192.168.10.70(192.168.10.70:3306) has all relay logs for recovery.
Selected 192.168.10.50(192.168.10.50:3306) as a new master.
Recovering master server failed.
Got Error so couldn't continue failover from here.Do đó, chuyển đổi dự phòng không thành công. Ví dụ trên cho thấy nút 192.168.10.70 chứa nhật ký chuyển tiếp được cập nhật nhiều nhất. Tuy nhiên, trong trường hợp ví dụ này, nút 192.168.10.70 được đặt là no_master vì nó có bộ nhớ thấp. Khi nó cố gắng khôi phục nô lệ 192.168.10.50, nó không thành công!
Bản sửa lỗi / Giải pháp:
Kịch bản này minh họa một điều rất quan trọng. Một môi trường giám sát tiên tiến phải được thiết lập! Ví dụ, bạn có thể chạy một tập lệnh nền hoặc daemon để giám sát tình trạng sao chép. Bạn có thể thêm dưới dạng một mục nhập thông qua một công việc cron. Ví dụ:thêm một mục nhập bằng cách sử dụng tập lệnh tích hợp sẵn masterha_check_repl :
/usr/local/bin/masterha_check_repl --conf=/etc/app1.cnfhoặc tạo một tập lệnh nền gọi tập lệnh này và chạy nó trong một khoảng thời gian. Bạn có thể sử dụng tùy chọn report_script để thiết lập thông báo cảnh báo trong trường hợp thông báo đó không phù hợp với yêu cầu của bạn, ví dụ:máy chủ bị trễ khoảng 100 giây khi tải cao điểm. Bạn cũng có thể sử dụng các nền tảng giám sát, chẳng hạn như ClusterControl, thiết lập nó để gửi thông báo cho bạn dựa trên các chỉ số bạn muốn theo dõi.
Ngoài ra, hãy lưu ý rằng, trong trường hợp ví dụ, chuyển đổi dự phòng không thành công do lỗi hết bộ nhớ. Bạn có thể cân nhắc việc đảm bảo tất cả các nút của mình có đủ bộ nhớ và kích thước phù hợp của nhật ký nhị phân vì chúng sẽ cần kết xuất binlog cho giai đoạn khôi phục nô lệ.
Nô lệ không nhất quán, Áp dụng các điểm khác biệt không thành công!
Liên quan đến độ trễ nô lệ, vì MHA sẽ cố gắng đồng bộ hóa nhật ký chuyển tiếp với một chủ ứng viên, hãy đảm bảo rằng dữ liệu của bạn được đồng bộ hóa. Lấy ví dụ dưới đây:
...
Concat succeeded.
Generating diff relay log succeeded. Saved at /tmp/relay_from_read_to_latest_192.168.10.50_3306_20190506054328.binlog .
scp testnode7:/tmp/relay_from_read_to_latest_192.168.10.50_3306_20190506054328.binlog to [email protected](22) succeeded.
Mon May 6 05:43:53 2019 - [info] Generating diff files succeeded.
Mon May 6 05:43:53 2019 - [info]
Mon May 6 05:43:53 2019 - [info] * Phase 3.5: Master Log Apply Phase..
Mon May 6 05:43:53 2019 - [info]
Mon May 6 05:43:53 2019 - [info] *NOTICE: If any error happens from this phase, manual recovery is needed.
Mon May 6 05:43:53 2019 - [info] Starting recovery on 192.168.10.50(192.168.10.50:3306)..
Mon May 6 05:43:53 2019 - [info] Generating diffs succeeded.
Mon May 6 05:43:53 2019 - [info] Waiting until all relay logs are applied.
Mon May 6 05:43:53 2019 - [info] done.
Mon May 6 05:43:53 2019 - [info] Getting slave status..
Mon May 6 05:43:53 2019 - [info] This slave(192.168.10.50)'s Exec_Master_Log_Pos equals to Read_Master_Log_Pos(binlog.000010:161813650). No need to recover from Exec_Master_Log_Pos.
Mon May 6 05:43:53 2019 - [info] Connecting to the target slave host 192.168.10.50, running recover script..
Mon May 6 05:43:53 2019 - [info] Executing command: apply_diff_relay_logs --command=apply --slave_user='cmon' --slave_host=192.168.10.50 --slave_ip=192.168.10.50 --slave_port=3306 --apply_files=/tmp/relay_from_read_to_latest_192.168.10.50_3306_20190506054328.binlog --workdir=/tmp --target_version=5.7.23-23-log --timestamp=20190506054328 --handle_raw_binlog=1 --disable_log_bin=0 --manager_version=0.58 --slave_pass=xxx
Mon May 6 05:43:53 2019 - [info]
MySQL client version is 5.7.23. Using --binary-mode.
Applying differential binary/relay log files /tmp/relay_from_read_to_latest_192.168.10.50_3306_20190506054328.binlog on 192.168.10.50:3306. This may take long time...
mysqlbinlog: Error writing file 'UNOPENED' (Errcode: 32 - Broken pipe)
FATAL: applying log files failed with rc 1:0!
Error logs from testnode5:/tmp/relay_log_apply_for_192.168.10.50_3306_20190506054328_err.log (the last 200 lines)..
ICwgMmM5MmEwZjkzY2M5MTU3YzAxM2NkZTk4ZGQ1ODM0NDEgLCAyYzkyYTBmOTNjYzkxNTdjMDEz
….
…..
M2QxMzc5OWE1NTExOTggLCAyYzkyYTBmOTNjZmI1YTdhMDEzZDE2NzhiNDc3NDIzNCAsIDJjOTJh
MGY5M2NmYjVhN2EwMTNkMTY3OGI0N2Q0MjMERROR 1062 (23000) at line 72: Duplicate entry '12583545' for key 'PRIMARY'
5ICwgMmM5MmEwZjkzY2ZiNWE3YTAxM2QxNjc4YjQ4
OTQyM2QgLCAyYzkyYTBmOTNjZmI1YTdhMDEzZDE2NzhiNDkxNDI1MSAsIDJjOTJhMGY5M2NmYjVh
N2EwMTNkMTczN2MzOWM3MDEzICwgMmM5MmEwZjkzY2ZiNWE3YTAxM2QxNzM3YzNhMzcwMTUgLCAy
…
--------------
Bye
at /usr/local/bin/apply_diff_relay_logs line 554.
eval {...} called at /usr/local/bin/apply_diff_relay_logs line 514
main::main() called at /usr/local/bin/apply_diff_relay_logs line 121
Mon May 6 05:43:53 2019 - [error][/usr/local/share/perl/5.26.1/MHA/MasterFailover.pm, ln1399] Applying diffs failed with return code 22:0.
Mon May 6 05:43:53 2019 - [error][/usr/local/share/perl/5.26.1/MHA/MasterFailover.pm, ln1584] Recovering master server failed.
Mon May 6 05:43:53 2019 - [error][/usr/local/share/perl/5.26.1/MHA/ManagerUtil.pm, ln178] Got ERROR: at /usr/local/bin/masterha_manager line 65.
Mon May 6 05:43:53 2019 - [info]Một cụm không nhất quán thực sự tồi tệ, đặc biệt là khi bật chuyển đổi dự phòng tự động. Trong trường hợp này, không thể tiến hành chuyển đổi dự phòng vì nó phát hiện mục nhập trùng lặp cho khóa chính ' 12583545 '.
Bản sửa lỗi / Giải pháp:
Có nhiều điều bạn có thể làm ở đây để tránh trạng thái không nhất quán của cụm của bạn.
- Bật sao chép bán đồng bộ không mất dữ liệu. Hãy xem blog bên ngoài này, đây là một cách hay để tìm hiểu lý do tại sao bạn nên cân nhắc sử dụng tính năng bán đồng bộ hóa trong thiết lập sao chép MySQL tiêu chuẩn.
- Liên tục chạy tổng kiểm tra đối với cụm chủ-tớ của bạn. Bạn có thể sử dụng pt-table-checksum và chạy nó giống như một lần một tuần hoặc một tháng tùy thuộc vào việc bảng của bạn được cập nhật liên tục như thế nào. Hãy lưu ý rằng pt-table-checksum có thể thêm chi phí vào lưu lượng cơ sở dữ liệu của bạn.
- Sử dụng sao chép dựa trên GTID. Mặc dù điều này sẽ không ảnh hưởng đến vấn đề. Tuy nhiên, sao chép dựa trên GTID giúp bạn xác định các giao dịch sai, đặc biệt là những giao dịch được chạy trực tiếp trên nô lệ. Một ưu điểm khác của điều này là việc quản lý sao chép dựa trên GTID sẽ dễ dàng hơn khi bạn cần chuyển đổi máy chủ chính trong quá trình nhân rộng.
Lỗi phần cứng trên Master nhưng các nô lệ vẫn chưa bắt được
Một trong nhiều lý do tại sao bạn sẽ đầu tư vào chuyển đổi dự phòng tự động là lỗi phần cứng trên tổng thể. Đối với một số thiết lập, lý tưởng hơn là chỉ thực hiện chuyển đổi dự phòng tự động khi thiết bị chính gặp lỗi phần cứng. Cách tiếp cận điển hình là thông báo bằng cách gửi báo thức - có thể có nghĩa là đánh thức người trực đang gọi vào nửa đêm để người đó quyết định việc cần làm. Loại tiếp cận này được thực hiện trên Github hoặc thậm chí là Facebook. Lỗi phần cứng, đặc biệt là nếu ổ đĩa nơi chứa binlog và thư mục dữ liệu của bạn bị ảnh hưởng, có thể gây rối với việc chuyển đổi dự phòng của bạn, đặc biệt nếu các bản ghi nhị phân được lưu trữ trên đĩa bị lỗi đó. Theo thiết kế, MHA sẽ cố gắng lưu các bản ghi nhị phân từ bản chính bị lỗi nhưng điều này không thể thực hiện được nếu đĩa bị lỗi. Một trường hợp có thể xảy ra là không thể truy cập máy chủ qua SSH. MHA không thể lưu nhật ký nhị phân và phải thực hiện chuyển đổi dự phòng mà không áp dụng các sự kiện nhật ký nhị phân chỉ tồn tại trên bản chính bị sự cố. Điều này sẽ dẫn đến việc mất dữ liệu mới nhất, đặc biệt là nếu không có máy chủ nào bắt kịp với máy chủ.
Bản sửa lỗi / Giải pháp
Là một trong những trường hợp sử dụng của MHA, bạn nên sử dụng sao chép bán đồng bộ vì nó làm giảm đáng kể nguy cơ mất dữ liệu như vậy. Điều quan trọng cần lưu ý là bất kỳ quá trình ghi nào tới bản chính phải đảm bảo rằng các nô lệ đã nhận được các sự kiện nhật ký nhị phân mới nhất trước khi đồng bộ hóa với đĩa. MHA có thể áp dụng các sự kiện cho tất cả các nô lệ khác để chúng có thể nhất quán với nhau.
Ngoài ra, tốt hơn hết bạn nên chạy một dòng sao lưu các bản ghi nhị phân của bạn để khôi phục thảm họa trong trường hợp ổ đĩa chính bị lỗi. Nếu máy chủ vẫn có thể truy cập được thông qua SSH, thì việc trỏ đường dẫn nhật ký nhị phân đến đường dẫn sao lưu của nhật ký nhị phân của bạn vẫn có thể hoạt động, vì vậy chuyển đổi dự phòng và khôi phục nô lệ vẫn có thể tiến lên. Bằng cách này, bạn có thể tránh mất dữ liệu.
Chuyển đổi dự phòng VIP (IP ảo) gây ra sự phân chia não bộ
MHA, theo mặc định, không xử lý bất kỳ quản lý VIP nào. Tuy nhiên, thật dễ dàng để kết hợp điều này với cấu hình của MHA và chỉ định các hook phù hợp với những gì bạn muốn MHA thực hiện trong quá trình chuyển đổi dự phòng. Bạn có thể thiết lập tập lệnh của riêng mình và nối nó với các tham số master_ip_failover_script hoặc master_ip_online_change_script. Có các tập lệnh mẫu cũng nằm trong thư mục
Trong quá trình chuyển đổi dự phòng tự động, khi tập lệnh của bạn có quản lý VIP được gọi và thực thi, MHA sẽ thực hiện những việc sau:kiểm tra trạng thái, xóa (hoặc dừng) VIP cũ, sau đó chỉ định lại VIP mới cho chủ mới. Một ví dụ điển hình của phân tách não là, khi một chủ được xác định là đã chết do sự cố mạng nhưng trên thực tế, các nút phụ vẫn có thể kết nối với chủ. Đây là một dương tính giả và thường dẫn đến sự không nhất quán của dữ liệu trên các cơ sở dữ liệu trong quá trình thiết lập. Các kết nối máy khách đến sử dụng VIP sẽ được gửi đến máy chủ mới. Mặt khác, có thể có các kết nối cục bộ đang chạy trên hệ thống chính cũ, được cho là đã chết. Các kết nối cục bộ có thể sử dụng ổ cắm unix hoặc máy chủ cục bộ để giảm bớt các bước nhảy mạng. Điều này có thể khiến dữ liệu bị lệch so với bản chính mới và phần còn lại của các nô lệ của nó, vì dữ liệu từ bản chính cũ sẽ không được sao chép vào các nô lệ.
Bản sửa lỗi / Giải pháp:
Như đã nêu trước đó, một số có thể muốn tránh chuyển đổi dự phòng tự động trừ khi các kiểm tra xác định rằng cái chính hoàn toàn bị lỗi (như lỗi phần cứng), tức là ngay cả các nút phụ cũng không thể truy cập được. Ý tưởng là dương tính giả có thể do trục trặc mạng giữa bộ điều khiển nút MHA và nút chính, vì vậy con người có thể phù hợp hơn trong trường hợp này để đưa ra quyết định có chuyển đổi dự phòng hay không.
Khi xử lý các cảnh báo sai, MHA có một tham số gọi là Secondary_check_script. Giá trị được đặt ở đây có thể là các tập lệnh tùy chỉnh của bạn hoặc bạn có thể sử dụng tập lệnh tích hợp sẵn / usr / local / bin / masterha_secondary_check được vận chuyển cùng với gói Trình quản lý MHA. Điều này bổ sung thêm các kiểm tra, đây thực sự là cách tiếp cận được khuyến nghị để tránh dương tính giả. Trong ví dụ bên dưới từ thiết lập của riêng tôi, tôi đang sử dụng tập lệnh tích hợp sẵn masterha_secondary_check :
secondary_check_script=/usr/local/bin/masterha_secondary_check -s 192.168.10.50 --user=root --master_host=testnode6 --master_ip=192.168.10.60 --master_port=3306Trong ví dụ trên, MHA Manager sẽ thực hiện một vòng lặp dựa trên danh sách các nút phụ (được chỉ định bởi đối số -s) sẽ kiểm tra kết nối với máy chủ MySQL master (192.168.10.60). Lưu ý rằng, các nút phụ này trong ví dụ này có thể là một số nút từ xa bên ngoài có thể thiết lập kết nối với các nút cơ sở dữ liệu trong cụm. Đây là cách tiếp cận được khuyến nghị đặc biệt cho những thiết lập mà Trình quản lý MHA đang chạy trên một trung tâm dữ liệu khác hoặc mạng khác với các nút cơ sở dữ liệu. Trình tự sau đây minh họa cách nó tiến hành kiểm tra:
- Từ Máy chủ lưu trữ MHA -> kiểm tra kết nối TCP với Nút nô lệ thứ nhất (IP:192.168.10.50). Hãy gọi đây là Kết nối A. Sau đó, từ Nút nô lệ, kiểm tra kết nối TCP với Nút chủ (192.168.10.60). Hãy gọi đây là Kết nối B.
Nếu "Kết nối A" thành công nhưng "Kết nối B" không thành công trong cả hai tuyến, masterha_secondary_check script thoát với mã trả về 0 và MHA Manager quyết định rằng MySQL master thực sự đã chết và sẽ bắt đầu chuyển đổi dự phòng. Nếu "Kết nối A" không thành công, masterha_secondary_check thoát với mã trả về 2 và MHA Manager đoán rằng có sự cố mạng và nó không bắt đầu chuyển đổi dự phòng. Nếu "Kết nối B" thành công, masterha_secondary_check thoát với mã trả về 3 và MHA Manager hiểu rằng máy chủ chính MySQL thực sự còn tồn tại và không bắt đầu chuyển đổi dự phòng.
Ví dụ về cách nó phản ứng trong quá trình chuyển đổi dự phòng dựa trên nhật ký,
Tue May 7 05:31:57 2019 - [info] OK.
Tue May 7 05:31:57 2019 - [warning] shutdown_script is not defined.
Tue May 7 05:31:57 2019 - [info] Set master ping interval 1 seconds.
Tue May 7 05:31:57 2019 - [info] Set secondary check script: /usr/local/bin/masterha_secondary_check -s 192.168.10.50 -s 192.168.10.60 -s 192.168.10.70 --user=root --master_host=192.168.10.60 --master_ip=192.168.10.60 --master_port=3306
Tue May 7 05:31:57 2019 - [info] Starting ping health check on 192.168.10.60(192.168.10.60:3306)..
Tue May 7 05:31:58 2019 - [warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '192.168.10.60' (110))
Tue May 7 05:31:58 2019 - [warning] Connection failed 1 time(s)..
Tue May 7 05:31:58 2019 - [info] Executing SSH check script: exit 0
Tue May 7 05:31:58 2019 - [info] Executing secondary network check script: /usr/local/bin/masterha_secondary_check -s 192.168.10.50 -s 192.168.10.60 -s 192.168.10.70 --user=root --master_host=192.168.10.60 --master_ip=192.168.10.60 --master_port=3306 --user=vagrant --master_host=192.168.10.60 --master_ip=192.168.10.60 --master_port=3306 --master_user=cmon [email protected] --ping_type=SELECT
Master is reachable from 192.168.10.50!
Tue May 7 05:31:58 2019 - [warning] Master is reachable from at least one of other monitoring servers. Failover should not happen.
Tue May 7 05:31:59 2019 - [warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '192.168.10.60' (110))
Tue May 7 05:31:59 2019 - [warning] Connection failed 2 time(s)..
Tue May 7 05:32:00 2019 - [warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '192.168.10.60' (110))
Tue May 7 05:32:00 2019 - [warning] Connection failed 3 time(s)..
Tue May 7 05:32:01 2019 - [warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '192.168.10.60' (110))
Tue May 7 05:32:01 2019 - [warning] Connection failed 4 time(s)..
Tue May 7 05:32:03 2019 - [warning] HealthCheck: Got timeout on checking SSH connection to 192.168.10.60! at /usr/local/share/perl/5.26.1/MHA/HealthCheck.pm line 343.
Tue May 7 05:32:03 2019 - [warning] Secondary network check script returned errors. Failover should not start so checking server status again. Check network settings for details.
Tue May 7 05:32:04 2019 - [warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '192.168.10.60' (110))
Tue May 7 05:32:04 2019 - [warning] Connection failed 1 time(s)..
Tue May 7 05:32:04 2019 - [info] Executing secondary network check script: /usr/local/bin/masterha_secondary_check -s 192.168.10.50 -s 192.168.10.60 -s 192.168.10.70 --user=root --master_host=192.168.10.60 --master_ip=192.168.10.60 --master_port=3306 --user=vagrant --master_host=192.168.10.60 --master_ip=192.168.10.60 --master_port=3306 --master_user=cmon [email protected] --ping_type=SELECT
Tue May 7 05:32:04 2019 - [info] Executing SSH check script: exit 0Một điều khác cần thêm là gán giá trị cho tham số shutdown_script. Tập lệnh này đặc biệt hữu ích nếu bạn phải triển khai STONITH hoặc hàng rào nút thích hợp để nó không sống lại từ cõi chết. Điều này có thể tránh được sự không nhất quán về dữ liệu.
Cuối cùng, hãy đảm bảo rằng Trình quản lý MHA nằm trong cùng một mạng cục bộ cùng với các nút cụm vì nó làm giảm khả năng mất mạng, đặc biệt là kết nối từ Trình quản lý MHA đến các nút cơ sở dữ liệu.
Tránh SPOF trong MHA
MHA có thể gặp sự cố vì nhiều lý do khác nhau và rất tiếc, không có tính năng tích hợp nào để khắc phục điều này, tức là Tính khả dụng cao cho MHA. Tuy nhiên, như chúng ta đã thảo luận trong blog trước của mình "Trình quản lý tính khả dụng cao (MHA) đã bị lỗi! Tôi phải làm gì bây giờ?", Có một cách để tránh SPOF cho MHA.
Bản sửa lỗi / Giải pháp:
Bạn có thể tận dụng Pacemaker để tạo các nút hoạt động / dự phòng do trình quản lý tài nguyên cụm (crm) xử lý. Ngoài ra, bạn có thể tạo một tập lệnh để kiểm tra tình trạng của nút trình quản lý MHA. Ví dụ:bạn có thể cung cấp một nút dự phòng chủ động kiểm tra nút trình quản lý MHA bằng cách ssh'ing để chạy tập lệnh tích hợp sẵn masterha_check_status giống như bên dưới:
[email protected]:~$ /usr/local/bin/masterha_check_status --conf=/etc/app1.cnf
app1 is stopped(2:NOT_RUNNING).sau đó thực hiện một số hàng rào nút nếu bộ điều khiển đó bị khóa. Bạn cũng có thể mở rộng công cụ MHA với một tập lệnh trợ giúp chạy qua cron job và theo dõi quá trình hệ thống của tập lệnh masterha_manager và tái tạo nó nếu quá trình bị chết.
Mất dữ liệu trong quá trình chuyển đổi dự phòng
MHA dựa trên bản sao không đồng bộ truyền thống. Mặc dù nó hỗ trợ bán đồng bộ hóa, tuy nhiên, bán đồng bộ hóa dựa vào sao chép không đồng bộ. Trong loại môi trường này, mất dữ liệu có thể xảy ra sau khi chuyển đổi dự phòng. Khi cơ sở dữ liệu của bạn không được thiết lập đúng cách và sử dụng phương pháp tái tạo kiểu cũ, thì đó có thể là một vấn đề khó khăn, đặc biệt là khi xử lý tính nhất quán của dữ liệu và các giao dịch bị mất.
Một điều quan trọng khác cần lưu ý khi mất dữ liệu với MHA, là khi GTID được sử dụng mà không bật tính năng bán đồng bộ hóa. MHA với GTID sẽ không kết nối thông qua ssh với master nhưng sẽ cố gắng đồng bộ hóa các bản ghi nhị phân để khôi phục nút với các nô lệ trước. Điều này có thể dẫn đến mất nhiều dữ liệu hơn so với MHA không phải GTID với tính năng bán đồng bộ hóa không được bật.
Bản sửa lỗi / Giải pháp
Khi thực hiện chuyển đổi dự phòng tự động, hãy xây dựng danh sách các tình huống khi bạn mong đợi MHA của mình chuyển đổi dự phòng. Vì MHA đang xử lý sao chép master-slave, nên lời khuyên của chúng tôi dành cho bạn để tránh mất dữ liệu là:
- Bật tính năng sao chép bán đồng bộ hóa không mất dữ liệu (tồn tại trong phiên bản MySQL 5.7)
- Sử dụng sao chép dựa trên GTID. Tất nhiên, bạn có thể sử dụng bản sao truyền thống bằng cách sử dụng tọa độ x &y của binlog. Tuy nhiên, nó làm cho mọi thứ trở nên khó khăn và tốn thời gian hơn khi bạn cần xác định một mục nhập nhật ký nhị phân cụ thể không được áp dụng trên nô lệ. Do đó, với GTID trong MySQL, việc phát hiện các giao dịch sai sót trở nên dễ dàng hơn.
- Để tuân thủ ACID của quá trình sao chép chủ-nô MySQL của bạn, hãy bật các biến cụ thể sau:sync_binlog =1, innodb_flush_log_at_trx_commit =1. Điều này tốn kém vì nó đòi hỏi nhiều sức mạnh xử lý hơn khi MySQL gọi hàm fsync () khi nó cam kết và hiệu suất có thể bị ràng buộc đĩa trong trường hợp số lần ghi cao. Tuy nhiên, sử dụng RAID với bộ nhớ đệm dự phòng pin sẽ tiết kiệm I / O đĩa của bạn. Ngoài ra, bản thân MySQL đã được cải thiện với cam kết nhóm nhật ký nhị phân nhưng vẫn sử dụng bộ nhớ đệm dự phòng có thể tiết kiệm một số đồng bộ hóa đĩa.
- Tận dụng sao chép song song hoặc sao chép nô lệ đa luồng. Điều này có thể giúp nô lệ của bạn trở nên hiệu quả hơn và tránh việc nô lệ bị tụt lại so với chủ. Bạn không muốn quá trình chuyển đổi dự phòng tự động của mình xảy ra khi bản gốc hoàn toàn không thể truy cập được thông qua kết nối ssh hoặc tcp, hoặc nếu nó gặp sự cố ổ đĩa và các nô lệ của bạn bị tụt lại phía sau. Điều đó có thể dẫn đến mất dữ liệu.
- Khi thực hiện chuyển đổi dự phòng trực tuyến hoặc thủ công, tốt nhất là bạn nên thực hiện nó trong thời gian không phải cao điểm để tránh những rủi ro không mong muốn có thể dẫn đến mất dữ liệu. Hoặc để tránh mất thời gian tìm kiếm qua nhật ký nhị phân của bạn trong khi có rất nhiều hoạt động đang diễn ra.
MHA cho biết APP không chạy hoặc chuyển đổi dự phòng không hoạt động. Tôi nên làm gì?
Việc chạy kiểm tra bằng tập lệnh tích hợp sẵn masterha_check_status sẽ kiểm tra xem tập lệnh mastreha_manager có đang chạy hay không. Nếu không, bạn sẽ gặp lỗi như dưới đây:
[email protected]:~$ /usr/local/bin/masterha_check_status --conf=/etc/app1.cnf app1 is stopped(2:NOT_RUNNING).Tuy nhiên, có một số trường hợp nhất định bạn có thể nhận được NOT_RUNNING ngay cả khi masterha_manager đang chạy. Điều này có thể do đặc quyền của ssh_user mà bạn đã đặt hoặc bạn chạy masterha_manager với một người dùng hệ thống khác hoặc người dùng ssh gặp phải một quyền bị từ chối.
Bản sửa lỗi / Giải pháp:
MHA sẽ sử dụng ssh_user được xác định trong cấu hình nếu được chỉ định. Nếu không, sẽ sử dụng người dùng hệ thống hiện tại mà bạn sử dụng để gọi các lệnh MHA. Khi chạy tập lệnh masterha_check_status ví dụ:bạn cần đảm bảo rằng masterha_manager chạy với cùng một người dùng được chỉ định trong ssh_user trong tệp cấu hình của bạn hoặc người dùng sẽ giao diện với các nút cơ sở dữ liệu khác trong cụm. Bạn cần đảm bảo rằng nó có khóa SSH không cần mật khẩu, không có cụm mật khẩu để MHA sẽ không gặp bất kỳ sự cố nào khi thiết lập kết nối với các nút mà MHA đang giám sát.
Lưu ý rằng bạn cần ssh_user để có quyền truy cập vào những thứ sau:
- Có thể đọc nhật ký chuyển tiếp và nhị phân của các nút MySQL mà MHA đang theo dõi
- Phải có quyền truy cập vào nhật ký giám sát MHA. Kiểm tra các thông số này trong MHA:master_binlog_dir, manager_workdir và manager_log
- Phải có quyền truy cập vào tệp cấu hình MHA. Điều này cũng rất quan trọng. Trong quá trình chuyển đổi dự phòng, khi kết thúc quá trình chuyển đổi dự phòng, nó sẽ cố gắng cập nhật tệp cấu hình và xóa mục nhập của tổng thể đã chết. Nếu tệp cấu hình không cho phép ssh_user hoặc người dùng hệ điều hành bạn đang sử dụng, nó sẽ không cập nhật tệp cấu hình, dẫn đến sự cố leo thang nếu thảm họa xảy ra một lần nữa.
Ứng viên Thạc sĩ Chậm, Cách Buộc và Tránh Không thành công
Tham chiếu đến wiki của MHA, theo mặc định, nếu nô lệ làm chủ hơn 100 MB nhật ký chuyển tiếp (=cần áp dụng hơn 100 MB nhật ký chuyển tiếp), MHA không chọn nô lệ làm chủ mới vì mất quá nhiều thời gian để khôi phục .
Bản sửa lỗi / Giải pháp
Trong MHA, điều này có thể được ghi đè bằng cách đặt tham số check_repl_delay =0. Trong quá trình chuyển đổi dự phòng, MHA bỏ qua độ trễ sao chép khi chọn một chủ mới và sẽ thực hiện các giao dịch bị thiếu. Tùy chọn này hữu ích khi bạn đặt ứng viên_master =1 trên một máy chủ cụ thể và bạn muốn đảm bảo rằng máy chủ đó có thể là máy chủ mới.
Bạn cũng có thể tích hợp với pt-heartbeat để đạt được độ chính xác của độ trễ nô lệ (xem bài đăng này và bài đăng này). Nhưng điều này cũng có thể được giảm bớt với các nô lệ sao chép song song hoặc sao chép đa luồng, có mặt kể từ MySQL 5.6 hoặc với MariaDB 10 - tuyên bố sẽ tăng gấp 10 lần cải tiến trong sao chép song song và nô lệ đa luồng. Điều này có thể giúp nô lệ của bạn sao chép nhanh hơn.
Mật khẩu MHA được hiển thị
Bảo mật hoặc mã hóa mật khẩu không phải do MHA xử lý. The parameters password or repl_password will be exposed via the configuration file. So your system administrator or security architect must evaluate the grants or privileges of this file as you don’t want to expose valuable database/SSH credentials.
Fixes/Resolution:
MHA has an optional parameter init_conf_load_script. This parameter can be used to have a custom script load your MHA config that will interface to e.g. a database, and retrieve the user/password credentials of your replication setup.
Of course, you can also limit the file attribute of the configuration and the user you are using, and limit the access to the specific Ops/DBA's/Engineers that will handle MHA.
MHA is Not My Choice, What Are the Alternatives for replication failover?
MHA is not a one-size-fits-all solution, it has its limitations and may not fit your desired setup. However, here's a list of variants that you can try.
- PRM
- Maxscale with Mariadb Monitor or MariaDB Replication Manager (MRM)
- Orchestrator
- ClusterControl
