目录
如果在执行故障切换时，必要的中继日志被 purge_relay_logs 清除怎么办？
MHA 支持 MySQL 5.0 及更高版本。不支持 MySQL 4.1 或更低版本。
MHA 还透明地支持 5.6+ 系统表复制信息（在系统表中管理中继日志位置）。
MHA 支持所有 Linux 发行版。MHA 应该也可以在其他 UNIX 平台上运行，但尚未进行测试。不支持 Windows。
是的，只要您使用两层（常规主从）复制。在两层复制中，主服务器的二进制日志文件和位置被写入从服务器的中继日志中（详见幻灯片 p.17-）。因此，它的作用类似全局事务标识符。只要从服务器存活，MHA 就可以通过解析中继日志确定确切的起始位置。默认情况下，除非所有从服务器都存活，否则 MHA 不会开始故障切换，因此当 MHA 运行时应该是可靠的。
是的，SkySQL 提供 MHA 的商业支持。
是的。任何二进制日志格式，包括基于语句的和基于行的（以及混合）都受支持。已知的一个问题是，在基于语句的二进制日志记录执行大型 LOAD DATA 后，如果主服务器失败，恢复可能会失败。在 MySQL 中使用基于语句的二进制日志记录执行 LOAD DATA 已被弃用，请不要使用。
如果您拥有 root 账户，是的，您可以使用。MHA 需要在 MySQL 服务器上的操作系统账户以便读取二进制日志或中继日志，并生成工作文件。通常读取二进制/中继日志需要 mysql 或 root 操作系统用户账户。如果您的云服务不提供操作系统账户，则无法在那里使用 MHA。MHA 不依赖于虚拟 IP 地址。因此，即使云供应商不提供许多虚拟 IP 地址，您也可以使用 MHA。
据我所知，没有。如果您只有一个主服务器和一个从服务器，“一些从服务器落后于最新的从服务器”情况就永远不会发生，因此自动故障切换变得更加容易。在云环境中，Amazon RDS 的 MultiAZ 提供了这样的功能。但请记住，使用一个从服务器会引起许多潜在问题。
（我不想提升一些服务器，因为它们不太稳定。）
是的。请检查 candidate_master 和 no_master 参数。
是的。请检查 masterha_master_switch 命令。
当一个或多个从服务器未存活，或者在稍后描述的某些情况下，MHA 不会开始故障切换。
“未存活”意味着以下情况。
例如，如果其中一个从服务器停止并出现重复键错误，MHA 不会开始故障切换。这是因为此类 SQL 错误无法自动解决，需要由 DBA 手动修复。由于 MySQL/操作系统/硬件故障引起的主服务器故障不会导致 SQL 线程停止（除非您使用旧版有缺陷的 MySQL 版本），因此不应发生此类情况。
如果在配置文件的每个主机上设置了 ignore_fail 参数，即使主机未存活，MHA 也会开始故障切换。
MHA 还在以下情况下不会开始故障切换。
以下主机不会被选为新主服务器。
如果主机符合上述条件，则新主服务器的确定基于以下规则。
目前，不支持从多个 MHA Manager 监控相同的主服务器。因此，如果 MHA Manager 出现故障，无法启动自动主故障切换。MHA Manager 故障不会导致主服务器故障，因此这就不太严重了，但是您可能希望尽可能地使 MHA Manager 高度可用。当前推荐的 MHA Manager 高可用解决方案是使用常见的主备解决方案，如 Pacemaker。
当您添加或删除 MySQL 服务器时，应更新应用程序配置文件，以便添加新主机或删除旧主机。更新文件后，建议重新启动 MHA Manager。当您希望自动化此过程时，masterha_conf_host 是有用的。
检查 init_conf_load_script 参数。该参数是为此类目的而引入的。
您不需要在应用程序配置文件中设置主机。MHA Manager 会连接配置文件中的所有主机，并自动识别当前的主服务器。
这绝对不应该发生。MHA Manager 在故障切换开始时会在所有从服务器上获取咨询锁。当执行清除操作时，purge_relay_logs 客户端程序也会在目标从服务器上获取相同的咨询锁。