基于 consul 架构的 MHA 自动切换

介绍 一直以来, 我们并未在线上启用 masterha_manager 自动切换脚本, 主要因为在网络抖动(网线, 所属机柜交换机不稳定)的情况下并不能保证数据库真的不能访问. 比如重启检测脚本所在机器的网卡并不能说明数据库出了问题, 所以从这方面看我们不能仅通过一个点的检测就判断数据库不可访问. 幸好可以通过 consul(因为 consul 提供 dns 接口, 笔者更倾向于使用 consul, 而不是 etcd)集群的特性, 我们增加多点检测机制, 在 n 个集群的环境中, 有超过半数的检测点检测到数据库有问题, 我们就认为数据库不可访问, 这时则开始调用 masterha_manager 脚本进行切换, 如下图所示: <checkmysql>…

Continue reading

MySQL 5.6主从故障处理说明

MySQL 5.6主从故障处理说明 5.6增加GTID特性作为主从复制的新协议, 如果开启需要指定 gtid_mode 为 on, 如果不开启主从复制采用传统的复制协议, 故障处理同5.1, 5.5. 以下讨论采用gtid协议后的故障处理; GTID配置 http://dev.mysql.com/doc/refman/5.6/en/replication-gtids-howto.html 与传统的复制相比, GTID去掉了文件及位置的参数信息, 改用 MASTER_AUTO_POSITION 替换.

Continue reading

MHA masterha manager检测master及failover处理说明

masterha_manager按照设置频率(ping_interval)定期检测 master 的访问情况, 超过3次检测失败则调用 master_ip_failover_script,master_ip_online_change_script和masterha_master_switch脚本提升一个slave为新的master, 老的master独立出来,供DBA手动操作或者恢复; 详见: https://code.google.com/p/mysql-master-ha/wiki/masterha_manager masterha_manager检测分为3部分: ping检测, ssh检测, MySQL connection检测; 1. MySQL connection检测: 使用init_conf_load_script参数提供的账号信息连接MySQL,成功则master->slave关系正常,失败转到ssh检测; 2. SSH检测: 在MySQL检测失败的情况下,继续检测ssh连接性,正常通信则拷贝binlog文件为提升新master做准备,失败则宣告master为dead状态,后续的slave提升会忽略该主机的binlog信息; 3. PING检测: 通用检测项,按照ping_interval参数定期ping master主机; masterha_manager循环检测,直到做一次主从切换(不论切换成功或失败)就退出(退出后发送报告,report_script参数指定); 调用unix daemonize让masterha_manager命令检测作为守护进程运行:

Continue reading