MHA 故障切换的高级配置与脚本定制

好的，各位观众，各位听众，欢迎来到“MHA故障切换高级配置与脚本定制”的现场！我是你们的老朋友，也是今天的主讲人，外号“Bug终结者”，人送外号“代码界的段子手”。😎

今天，我们要聊聊一个相当重要，但又容易让人头疼的话题：MHA（Master High Availability Manager）。这玩意儿，说白了，就是数据库界的大管家，专门负责在老大（Master）撂挑子不干的时候，赶紧扶持个新老大上位，保证咱们的数据服务始终在线。

但是呢，MHA默认的配置就像是买来的毛坯房，虽然能住，但总觉得缺了点个性，少了点舒适。所以，今天咱们就要来聊聊如何对MHA进行高级配置和脚本定制，把这毛坯房装修成豪华别墅，让咱们的数据库服务更加健壮、智能、高效！

第一部分：MHA的核心概念与基本流程

在深入高级配置之前，咱们先来回顾一下MHA的核心概念，打好地基，才能盖高楼嘛！

• Master: 数据库集群的“老大”，负责处理所有读写请求。
• Slave: 数据库集群的“小弟”，负责从Master同步数据，作为备用方案。
• MHA Manager: MHA的核心组件，负责监控Master的状态，并在Master失效时进行故障切换。
• MHA Node: 运行MHA Manager或Slave的服务器。

MHA的工作流程，简单来说，就像是古代的皇位传承：

1. 监控： MHA Manager时刻盯着Master，就像太监总管盯着皇帝，关注他的一举一动。
2. 检测： 一旦Master出现问题（比如驾崩了，或者CPU 100%了，或者网络瘫痪了），MHA Manager会立即发现。
3. 判断： MHA Manager会根据预设的策略，判断是否需要进行故障切换。这就像大臣们商议，看看皇帝是不是真的不行了，还是只是闹个小脾气。
4. 选择： 如果需要切换，MHA Manager会从Slave中选择一个合适的“皇子”（新的Master）。
5. 切换： MHA Manager会执行一系列操作，包括提升Slave为Master，更新所有Slave的复制配置，以及通知应用程序连接新的Master。这就像是举行登基大典，昭告天下。

第二部分：MHA高级配置：打造专属的数据库管家

MHA的配置文件通常是appliance.cnf或manager.cnf，位于MHA Manager所在的服务器上。我们可以通过修改这个文件，来定制MHA的行为。

下面，我们来聊聊一些常用的高级配置选项：

配置项	描述	示例
master_ip_failover	设置是否启用IP漂移。当Master失效时，MHA Manager可以将Master的IP地址漂移到新的Master上，从而避免应用程序需要修改连接配置。 这就像是皇帝驾崩后，太子直接继承皇位，连龙椅都不用换，省去了很多麻烦。	master_ip_failover=1
ping_type	设置用于检测Master状态的ping类型。MHA支持多种ping类型，包括mysql_ping（使用MySQL的ping命令）、tcp_ping（使用TCP连接）和ssh_ping（使用SSH连接）。 选择合适的ping类型可以提高检测的准确性和效率。 这就像医生给皇帝体检，可以用把脉，可以用听诊器，也可以用核磁共振，选择最适合的才能更准确地诊断病情。	ping_type=mysql_ping
remote_command	设置用于在远程服务器上执行命令的命令。默认情况下，MHA使用SSH执行远程命令。 你可以修改这个配置项，使用其他的远程命令执行工具，比如clusterssh或者pdsh。 这就像皇帝要下旨，可以用圣旨，也可以用电报，甚至可以用微信，只要能把旨意传达下去就行。	remote_command=ssh -o StrictHostKeyChecking=no
candidate_master	设置候选Master的选择策略。MHA支持多种选择策略，包括prefer_latest（选择拥有最新数据的Slave）、prefer_running_longest（选择运行时间最长的Slave）和prefer_priority（根据优先级选择Slave）。 选择合适的策略可以确保选出的新Master是最合适的。 这就像选太子，要考虑他的能力，他的资历，以及他的民意支持度，综合评估才能选出最合适的继承人。	candidate_master=prefer_latest
master_binlog_dir	设置Master的二进制日志目录。MHA Manager需要访问Master的二进制日志，才能进行故障切换。 这就像皇帝的起居注，记录了他每天的言行，以便后人研究。	master_binlog_dir=/var/log/mysql
slave_binlog_dir	设置Slave的二进制日志目录。MHA Manager需要访问Slave的二进制日志，才能进行故障切换。	slave_binlog_dir=/var/log/mysql
report_script	设置用于发送告警通知的脚本。当MHA检测到Master失效时，可以执行这个脚本发送告警通知，以便管理员及时处理。 这就像皇帝驾崩后，要立刻发布讣告，通知全国人民。	report_script=/usr/local/bin/send_alert.sh
shutdown_script	设置用于关闭旧Master的脚本。当故障切换完成后，MHA可以执行这个脚本关闭旧Master，避免数据冲突。 这就像新皇帝登基后，要处决旧皇帝的亲信，以巩固自己的统治。	shutdown_script=/usr/local/bin/shutdown_master.sh
master_ip_online_change_script	设置IP切换后执行的脚本，用于让新Master上线，接管业务流量。这就像新皇帝登基后，要发布新政，让国家机器重新运转起来。	master_ip_online_change_script=/usr/local/bin/online_master.sh
secondary_check_script	设置二次检测脚本，用于更准确的判断Master是否真的失效。这就像医生会进行多次会诊，以确保诊断的准确性。	secondary_check_script=/usr/local/bin/secondary_check.sh

第三部分：MHA脚本定制：让MHA拥有你的灵魂

MHA的强大之处不仅在于它的配置选项，更在于它的脚本定制能力。我们可以通过编写自定义脚本，来扩展MHA的功能，满足我们特定的需求。

下面，我们来聊聊一些常用的脚本定制场景：

1. 自定义告警通知：

   MHA默认的告警通知可能不够灵活，我们可以编写自定义脚本，发送更加详细的告警信息，或者将告警信息发送到不同的渠道，比如邮件、短信、微信等等。

   #!/bin/bash
   
   # 获取告警信息
   ALERT_MESSAGE="$1"
   
   # 发送邮件
   echo "$ALERT_MESSAGE" | mail -s "MHA Alert" [email protected]
   
   # 发送短信 (需要安装短信发送工具)
   # sendsms -n 13800000000 "$ALERT_MESSAGE"
   
   # 发送微信 (需要调用微信API)
   # curl -X POST -H "Content-Type: application/json" -d '{"msgtype": "text", "text": {"content": "'"$ALERT_MESSAGE"'"}}' https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=YOUR_WECHAT_ROBOT_KEY

   这个脚本可以发送邮件、短信和微信告警通知，你可以根据自己的需求选择合适的通知方式。

2. 自定义故障切换逻辑：

   MHA默认的故障切换逻辑可能不适用于所有场景，我们可以编写自定义脚本，来控制故障切换的行为。

   比如，我们可以编写一个脚本，在故障切换之前，先检查新的Master是否满足特定的条件，比如磁盘空间是否足够，CPU负载是否过高等等。

   #!/bin/bash
   
   # 获取候选Master的IP地址
   NEW_MASTER_IP="$1"
   
   # 检查磁盘空间
   DISK_SPACE=$(ssh root@$NEW_MASTER_IP "df -h / | awk '{print $4}' | tail -n 1")
   if [[ "$DISK_SPACE" == *"G"* ]]; then
       DISK_SPACE_GB=$(echo "$DISK_SPACE" | sed 's/G//')
       if [[ "$DISK_SPACE_GB" -lt 50 ]]; then
           echo "Disk space is too low, aborting failover."
           exit 1
       fi
   fi
   
   # 检查CPU负载
   CPU_LOAD=$(ssh root@$NEW_MASTER_IP "uptime | awk '{print $NF}' | sed 's/,//'")
   if [[ $(echo "$CPU_LOAD > 0.8" | bc -l) -eq 1 ]]; then
       echo "CPU load is too high, aborting failover."
       exit 1
   fi
   
   # 如果所有检查都通过，则允许故障切换
   exit 0

   这个脚本会检查新的Master的磁盘空间和CPU负载，如果任何一个条件不满足，则会阻止故障切换。

3. 自定义数据恢复逻辑：

   在某些情况下，故障切换后可能需要进行一些额外的数据恢复操作，比如清理旧Master上的数据，或者将数据同步到新的Slave上。

   我们可以编写自定义脚本，来执行这些数据恢复操作。

   #!/bin/bash
   
   # 获取旧Master的IP地址
   OLD_MASTER_IP="$1"
   
   # 清理旧Master上的数据
   ssh root@$OLD_MASTER_IP "rm -rf /var/lib/mysql/*"
   
   # 将数据同步到新的Slave上 (需要使用mysqldump和mysql命令)
   # mysqldump -u root -pPASSWORD --all-databases | mysql -u root -pPASSWORD -h NEW_SLAVE_IP
   
   # 重启旧Master
   ssh root@$OLD_MASTER_IP "reboot"

   这个脚本会清理旧Master上的数据，并将数据同步到新的Slave上。

4. 与监控系统集成：

   我们可以编写自定义脚本，将MHA的状态信息发送到监控系统，比如Zabbix或者Prometheus，以便实时监控数据库集群的健康状况。

   #!/bin/bash
   
   # 获取MHA状态信息 (需要调用MHA的命令行工具)
   MHA_STATUS=$(masterha_check_repl)
   
   # 将状态信息发送到Zabbix (需要安装zabbix_sender)
   zabbix_sender -z zabbix_server_ip -p 10051 -s hostname -k mha.status -o "$MHA_STATUS"

   这个脚本会将MHA的状态信息发送到Zabbix，以便在Zabbix上进行监控。

5. 自动化部署与配置：

   我们可以编写脚本，自动化部署和配置MHA，简化部署流程，减少人为错误。可以使用Ansible, Chef, Puppet等配置管理工具。

第四部分：MHA故障切换演练：真刀真枪，检验成果

光说不练假把式，咱们需要进行故障切换演练，才能真正检验MHA的配置是否正确，脚本是否有效。

建议定期进行故障切换演练，模拟各种故障场景，比如Master宕机，网络中断，磁盘损坏等等。

在演练过程中，需要密切关注MHA的行为，检查是否按照预期执行，并记录演练结果，以便进行分析和改进。

第五部分：MHA的常见问题与解决方案

在使用MHA的过程中，可能会遇到一些问题，下面我们来聊聊一些常见问题和解决方案：

• MHA Manager无法连接到Master/Slave：

  • 检查网络连接是否正常。
  • 检查防火墙是否阻止了MHA Manager与Master/Slave之间的通信。
  • 检查MySQL的权限配置是否正确，MHA Manager需要拥有足够的权限才能访问MySQL。

• MHA Manager无法检测到Master失效：

  • 检查ping_type配置是否正确，选择合适的ping类型可以提高检测的准确性和效率。
  • 检查secondary_check_script配置是否正确，二次检测可以更准确的判断Master是否真的失效。

• 故障切换失败：

  • 检查candidate_master配置是否正确，选择合适的候选Master选择策略。
  • 检查自定义脚本是否执行成功，如果脚本执行失败，可能会导致故障切换失败。
  • 检查MySQL的配置是否正确，比如log_bin是否启用，server_id是否唯一等等。

• 数据丢失：

  • 确保所有Slave都启用了log_slave_updates，以便记录Slave上的更新。
  • 在故障切换之前，尽量减少Master上的写入操作，以减少数据丢失的风险。
  • 在故障切换之后，进行数据一致性检查，确保所有Slave都拥有相同的数据。

第六部分：总结：MHA，你的数据库守护神

MHA是一个强大的数据库高可用解决方案，通过高级配置和脚本定制，我们可以将MHA打造成一个真正适合自己的数据库守护神。

记住，没有一劳永逸的配置，只有不断学习和改进，才能让我们的数据库服务更加健壮、智能、高效！

希望今天的分享对大家有所帮助，祝大家在使用MHA的过程中，一切顺利，Bug少少，快乐多多！ 谢谢大家！ 🎉