修改MySQL高可用模块接收自定义VIP参数

但凡是MySQL DBA肯定都听说过MHA个高可用方案,而且很多公司都是通过对MHA做二次开发来实现MySQL高可用的。如果MHA不结合VIP的话,每次主库切换都需要程序修改连数据库的配置,这样比较麻烦。而采用MHA+VIP的方式时可以在主库切换的过程中让VIP漂移到新主库,省去了改数据库配置这一过程。

公司以前是每一组主从复制集群都配置一个manager结点,然后将vip和网络接口等信息都写死在master_ip_failover和master_ip_online_change脚本中。当主从集群数量太多的情况下要维护的manager结点很多,管理起来很麻烦。

如何实现用一个Manager结点管理多个支持VIP的mysql主从集群呢?有两种实现方式:

1,每一组主从复制集群维护两个切换脚本,将VIP和网络接口信息写死在脚本里。

2,修改MHA的相关模块,使其能识别我们自定义的参数,我们只需要在每一组主从复制集群的配置文件中给参数传值。

很明显,第1种方式太low了,需要维护大量的切换脚本。那我们需要修改哪些模块呢?

看一下masterha_check_repl这段脚本,可以看到检测主从复制状态的时候会调用MasterMonitor模块。

$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";
}

通过masterha_master_switch这段脚本可以看到在线切换是调用的MasterRotate模块,故障切换是调用的MasterFailover模块。

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这三个模块都是调用Config.pm模块来读取参数配置,所以我们只需要修改这几个模块即可。

为了不平的网络环境,我在配置文件加了这三个配置项:

app_vip :主库的VIP

netmask :  VIP的网络位

interface :VIP要绑定的网上

对应调整的代码如下:

Config.pm:

申明变量:

my @PARAM_ARRAY =
  qw/ hostname ip port ssh_host ssh_ip ssh_port ssh_connection_timeout ssh_options node_label candidate_master 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/;

给变量赋值:

  $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 :

修改复制检测时的命令:

"$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 :

修改停原主库写入的命令:

"$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}";

修改允许在新主库写入的命令:

"$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:

修改禁用原从库的vip命令:

 "$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}";

修改启用原从库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}";
时间: 2024-10-12 07:49:15

修改MySQL高可用模块接收自定义VIP参数的相关文章

corosync+pacemaker+drbd实现mysql高可用

实验环境: 虚拟机2台安装corosync+pacemaker,使用的操作系统为CentOS6.5. 虚拟机IP:172.16.103.2.172.16.103.3 实验步骤: 前提准备:两台虚拟机时间同步,能够使用/etc/hosts文件基于主机名进行通信. 一.安装corosync + pacemaker: # yum install corosync # yum install pacemaker 二.安装drbd软件包: drbd软件包有两部分组成:内核模块和用户空间的管理工具,在内核版

搭建MySQL高可用负载均衡集群

1.简介 使用MySQL时随着时间的增长,用户量以及数据量的逐渐增加,访问量更是剧增,最终将会使MySQL达到某个瓶颈,那么MySQL的性能将会大大降低.这一结果也不利于软件的推广. 那么如何跨过这个瓶颈,提高MySQL的并发量呢?方法有很多,分布式数据库.读写分离.高可用负载均衡.增加缓存服务器等等.之前的文章里已经介绍了读写分离的方案了,接下来我将讲解MySQL高可用负载均衡这一方法. 其中实现高可用负载均衡的方法有很多,例如LVS+keepalived组合实现.haproxy+keepal

MySQL高可用之MHA的搭建

MySQL MHA架构介绍: MHA(Master High Availability)目前在MySQL高可用方面是一个相对成熟解决方案,它由日本DeNA公司youshimaton(现就职于Facebook公司)开发,是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件.在MySQL故障切换过程中,MHA能做到在0~30秒之内自动完成数据库故障切换操作,并且在进行故障切换的过程中,MHA能在最大程度上保证数据的一致性,以达到真正的高可用. 该软件由两部分组成:MHA Manag

Linux集群之corosync+pacemaker+drbd实现MySQL高可用

一.drbd简介 drbd即Distributed Replicated Block Device(分布式磁盘块设备),drbd一个基于软件实现的,不共享任何东西,通过复制的方式在存储之间构建所谓镜像模式机制的磁盘,从而使得一个数据可以存储为多份, drbd的核心功能是在内核中实现. 二.drbd原理 每一个主机都提供一个块设备,块的大小是一模一样的,当主机上的进程需要存储数据时,需要向内核申请,任何用户空间的进程都没有直接操作硬件的权限,事实上驱动磁盘是在内核靠驱动程序来实现的,任何一个进程存

MySQL高可用架构-MHA环境部署记录

一.MHA介绍 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 MHA(Master High Availability)目前在MySQL高可用方面是一个相对成熟的解决方案,它由日本DeNA公司youshimaton(现就职于Facebook公司)开发,是日本的一位 MySQL专家采用Perl语言编写的一个脚本管理工具,该工具仅适用于MySQLReplication(二层)环境,目的在于维持Master主库的高可用性.是一套优秀的作为MySQL高可用性 环境下故障切

MySQL高可用负载均衡

1.简介 使用MySQL时随着时间的增长,用户量以及数据量的逐渐增加,访问量更是剧增,最终将会使MySQL达到某个瓶颈,那么MySQL的性能将会大大降低.这一结果也不利于软件的推广. 那么如何跨过这个瓶颈,提高MySQL的并发量呢?方法有很多,分布式数据库.读写分离.高可用负载均衡.增加缓存服务器等等.之前的文章里已经介绍了读写分离的方案了,接下来我将讲解MySQL高可用负载均衡这一方法. 其中实现高可用负载均衡的方法有很多,例如LVS+keepalived组合实现.haproxy+keepal

MySQL 高可用之MHA

目录 MySQL高可用之MHA MHA简介 MHA工作流程 HMA架构 MHA工具介绍 部署MHA MySQL环境准备 配置GTID主从复制 配置关闭relaylog自动删除 安装MHA Node 安装MHA Manager 测试故障切换 修复主从和MHA 配置VIP漂移 配置binlog-server 故障排错 MySQL高可用之MHA MHA简介 MHA(Master High Availability)目前在MySQL高可用方面是一个相对成熟的解决方案,它由日本DeNA公司youshima

Mysql+DRBD+Heartbeat 实现mysql高可用的双击热备(DRBD篇)

DRBD官方tar包下载地址:   http://oss.linbit.com/drbd/ 环境介绍: 系统版本:CentOS 6.4 (64位) 内核版本  2.6.32-358.el6.x86_64 软件版本:drbd-8.4.3.tar.gz 主:10.0.0.1   从:10.0.0.2 两台机器上的hosts都需要修改: [[email protected] ~]# vim /etc/hosts 10.0.0.1    node1 10.0.0.2    node2 两台服务器双网卡,

企业中MySQL高可用集群架构三部曲之MM+keepalived

各位老铁们,老张与大家又见面了.看到各位在博客里面给我的留言和访问量的情况,我很是欣慰,也谢谢大家对我的认可.我写这些博客,就是想把自己对于MySQL数据库的一些看法和自己平时的实战经验分享出来,我们可以一起探讨,共同进步.也保证今后只要一有空就更新博文,推出更多的干货. 我的学生经常对我说:"张老师,每次我遇到报错,有时还是会百度,但是最烦的是不知道百度哪篇帖子说的是正确的".其实这些呢,都是因为自己还没有对MySQL数据库核心知识的不熟悉,和对技术掌握的不牢固.平时下得功夫还是不到