Modify MySQL high availability module to receive custom VIP parameters

Source: Internet
Author: User

But every MySQL DBA must have heard of MHA's high-availability program, and many companies have made MySQL highly available by doing two development of MHA. If MHA does not combine VIP, it is troublesome to change the configuration of the database with the program every time the main library switch. In the case of MHA+VIP, the VIP can drift to the new main library during the main library switch, eliminating the process of changing the database configuration.

The company used to be each group of master and slave replication clusters are configured with a manager node, and then the VIP and network interfaces and other information are written to die in the Master_ip_failover and Master_ip_online_change scripts. When the number of master and slave clusters is too large to maintain a lot of manager node, management is cumbersome.

How can I implement a MySQL master-slave cluster with one manager node to manage multiple VIP support? There are two ways to achieve this:

1, each group of master-slave replication cluster maintains two switch scripts, the VIP and network interface information written dead in the script.

2, modify the relevant module of MHA, so that it can recognize our custom parameters, we only need in each set of master-slave replication cluster configuration file to give parameter values.

Obviously, the 1th way is too low to maintain a large number of switching scripts. So what modules do we need to modify?

Looking at the Masterha_check_repl script, you can see that the Mastermonitor module is called when the master-slave replication status is detected.

$exit _code = Mha::mastermonitor::main ("--interactive=0", "--check_only", "--check_repl_health", @ARGV); if ($exit _ Code = = 0) {print "\nmysql Replication health is ok.\n";} else {print "\nmysql Replication health is not ok!\n";}


By Masterha_master_switch This script you can see that the online switchover is called the Masterrotate module, and failover is called the Masterfailover module.

if ($master _state eq "dead") {$exit _code = Mha::masterfailover::main (@ARGV);} elsif ($master _state eq "Alive") {$exit _code = Mha::masterrotate::main (@ARGV);} else {pod2usage (1);}


MASTERMONITOR.PM,MASTERROTATE.PM,MASTERFAILOVER.PM all three modules call the CONFIG.PM module to read the parameter configuration, so we just need to modify these modules.


For an uneven network environment, I added these three configuration entries in the config file:

APP_VIP: VIP of the main library

Network bit of NETMASK:VIP

INTERFACE:VIP to bind the Web


The corresponding adjustment code is as follows:

CONFIG.PM:

Declaration variables:

My @PARAM_ARRAY = qw/hostname IP Port ssh_host ssh_ip ssh_port ssh_connection_timeout ssh_options Node_label candidate_m Aster no_master ignore_fail skip_init_ssh_check skip_reset_slave user password Repl_user repl_password disable_log_bin Master_pid_file handle_raw_binlog ssh_user remote_workdir master_binlog_dir log_level manager_workdir manager_log Check_repl_delay check_repl_filter latest_priority multi_tier_slave ping_interval ping_type secondary_check_script Master_ip_failover_script master_ip_online_change_script shutdown_script report_script init_conf_load_script Client _bindir client_libdir use_gtid_auto_pos app_vip netmask interface/;


Assign a value to a variable:

$value {APP_VIP} = $param _arg->{app_vip};  if (!defined ($value {APP_VIP})) {$value {APP_VIP} = $default->{app_vip};  } $value {Netmask} = $param _arg->{netmask};  if (!defined ($value {netmask})) {$value {netmask} = $default->{netmask};  } $value {Interface} = $param _arg->{interface};  if (!defined ($value {interface})) {$value {interface} = $default->{interface}; }


MASTERMONITOR.PM:

To modify a command when replication is detected:

"$current _master->{master_ip_failover_script}--command=status--ssh_user= $current _master->{ssh_user}-- orig_master_host= $current _master->{hostname}--orig_master_ip= $current _master->{ip}--orig_master_port=$ Current_master->{port}--app_vip= $current _master->{app_vip}--netmask= $current _master->{netmask}-- interface= $current _master->{interface} ";


MASTERMONITOR.PM:

To modify the commands that the primary repository writes:

"$orig _master->{master_ip_online_change_script}--command=stop--orig_master_host= $orig _master->{hostname} --orig_master_ip= $orig _master->{ip}--orig_master_port= $orig _master->{port}--orig_master_user= $orig _ Master->{escaped_user}--orig_master_password= $orig _master->{escaped_password}--new_master_host= $new _ Master->{hostname}--new_master_ip= $new _master->{ip}--new_master_port= $new _master->{port}--new_master_ user= $new _master->{escaped_user}--new_master_password= $new _master->{escaped_password}--app_vip= $orig _ MASTER->{APP_VIP}--netmask= $orig _master->{netmask}--interface= $orig _master->{interface} ";


Modify the commands that are allowed to be written to the new Main library:

"$new _master->{master_ip_online_change_script}--command=start--orig_master_host= $orig _master->{hostname} --orig_master_ip= $orig _master->{ip}--orig_master_port= $orig _master->{port}--orig_master_user= $orig _ Master->{escaped_user}--orig_master_password= $orig _master->{escaped_password}--new_master_host= $new _ Master->{hostname}--new_master_ip= $new _master->{ip}--new_master_port= $new _master->{port}--new_master_ user= $new _master->{escaped_user}--new_master_password= $new _master->{escaped_password}--app_vip= $orig _ MASTER->{APP_VIP}--netmask= $orig _master->{netmask}--interface= $orig _master->{interface} ";


MASTERFAILOVER.PM:

To modify a VIP command that disables the original from library:

"$dead _master->{master_ip_failover_script}--orig_master_host= $dead _master->{hostname}--orig_master_ip=$ DEAD_MASTER->{IP}--orig_master_port= $dead _master->{port}--app_vip= $dead _master->{app_vip}--netmask=$ Dead_master->{netmask}--interface= $dead _master->{interface} ";


To modify a command that enables the original from library VIP:

"$new _master->{master_ip_failover_script}--command=start--ssh_user= $new _master->{ssh_user}--orig_master_ host= $dead _master->{hostname}--orig_master_ip= $dead _master->{ip}--orig_master_port= $dead _master->{ Port}--new_m aster_host= $new _master->{hostname}--new_master_ip= $new _master->{ip}--new_master_port= $new _ Master->{port}--new_master_user= $new _master->{escaped_user}--new_master_password= $new _master->{ Escaped_password}--app_vip= $de Ad_master->{app_vip}--netmask= $dead _master->{netmask}--interface= $dead _ Master->{interface} ";


This article is from the "Always on the Road" blog, please be sure to keep this source http://chenql.blog.51cto.com/8732050/1939105

Modify MySQL high availability module to receive custom VIP parameters

Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.