【MHA】MySQL高可用MHA介绍7-常见问题

常见问题解答

支持哪些 MySQL 版本？

支持哪些操作系统？

MHA 可靠吗？

是否提供 MHA 的商业支持？

是否支持基于行的二进制日志格式？

在云环境中是否工作？

是否有其他解决方案可以完成与 MHA 相同的事情？

是否可以提升特定服务器为新主服务器？

是否可以使用 MHA 进行手动交互式故障切换？

MHA Manager 何时不执行故障切换？

哪个主机不会被选为新主服务器？

哪个主机会被选为新主服务器？

如何使 MHA Manager 节点自身高度可用？

当我们添加或删除 MySQL 服务器时，应该执行什么操作？

我不想在配置文件中写入明文密码。

如何在配置文件中设置主机？

如果在执行故障切换时，必要的中继日志被 purge_relay_logs 清除怎么办？

常见问题解答

支持哪些 MySQL 版本？

MHA 支持 MySQL 5.0 及更高版本。不支持 MySQL 4.1 或更低版本。

MHA 还透明地支持 5.6+ 系统表复制信息（在系统表中管理中继日志位置）。

支持哪些操作系统？

MHA 支持所有 Linux 发行版。MHA 应该也可以在其他 UNIX 平台上运行，但尚未进行测试。不支持 Windows。

MHA 可靠吗？

是的，只要您使用两层（常规主从）复制。在两层复制中，主服务器的二进制日志文件和位置被写入从服务器的中继日志中（详见幻灯片 p.17-）。因此，它的作用类似全局事务标识符。只要从服务器存活，MHA 就可以通过解析中继日志确定确切的起始位置。默认情况下，除非所有从服务器都存活，否则 MHA 不会开始故障切换，因此当 MHA 运行时应该是可靠的。

是否提供 MHA 的商业支持？

是的，SkySQL 提供 MHA 的商业支持。

是否支持基于行的二进制日志格式？

是的。任何二进制日志格式，包括基于语句的和基于行的（以及混合）都受支持。已知的一个问题是，在基于语句的二进制日志记录执行大型 LOAD DATA 后，如果主服务器失败，恢复可能会失败。在 MySQL 中使用基于语句的二进制日志记录执行 LOAD DATA 已被弃用，请不要使用。

在云环境中是否工作？

如果您拥有 root 账户，是的，您可以使用。MHA 需要在 MySQL 服务器上的操作系统账户以便读取二进制日志或中继日志，并生成工作文件。通常读取二进制/中继日志需要 mysql 或 root 操作系统用户账户。如果您的云服务不提供操作系统账户，则无法在那里使用 MHA。MHA 不依赖于虚拟 IP 地址。因此，即使云供应商不提供许多虚拟 IP 地址，您也可以使用 MHA。

是否有其他解决方案可以完成与 MHA 相同的事情？

据我所知，没有。如果您只有一个主服务器和一个从服务器，“一些从服务器落后于最新的从服务器”情况就永远不会发生，因此自动故障切换变得更加容易。在云环境中，Amazon RDS 的 MultiAZ 提供了这样的功能。但请记住，使用一个从服务器会引起许多潜在问题。

是否可以提升特定服务器为新主服务器？

（我不想提升一些服务器，因为它们不太稳定。）

是的。请检查 candidate_master 和 no_master 参数。

是否可以使用 MHA 进行手动交互式故障切换？

是的。请检查 masterha_master_switch 命令。

MHA Manager 何时不执行故障切换？

当一个或多个从服务器未存活，或者在稍后描述的某些情况下，MHA 不会开始故障切换。

“未存活”意味着以下情况。

无法通过 MySQL 连接
SQL 线程无法启动并出现错误
无法通过 SSH 连接（仅在需要应用差异中继日志事件时）

例如，如果其中一个从服务器停止并出现重复键错误，MHA 不会开始故障切换。这是因为此类 SQL 错误无法自动解决，需要由 DBA 手动修复。由于 MySQL/操作系统/硬件故障引起的主服务器故障不会导致 SQL 线程停止（除非您使用旧版有缺陷的 MySQL 版本），因此不应发生此类情况。

如果在配置文件的每个主机上设置了 ignore_fail 参数，即使主机未存活，MHA 也会开始故障切换。

MHA 还在以下情况下不会开始故障切换。

当从服务器的二进制日志或中继日志过滤规则（binlog-do-db、replicate-do-db 等）不同时
上次故障切换失败时。在这种情况下，故障切换错误文件会在工作目录下创建。删除它并重新启动手动故障切换。
上次故障切换太近（默认为 8 小时，可以通过设置 --last_failover_minute=(minute) 更改）。在这种情况下，MHA Manager 不会执行故障切换，因为很可能只通过故障切换无法解决问题。

哪个主机不会被选为新主服务器？

以下主机不会被选为新主服务器。

配置文件中设置了 no_master=1
MySQL 中未启用日志记录
主要 MySQL 版本（5.0/5.1/..）不是所有从服务器中最旧的
SQL 线程延迟显著。如果目标从服务器上的 Relay_Master_Log_File 落后于最新从服务器上的 Master_Log_File，或者 Exec_Master_Log_Pos 相对于最新从服务器上的 Read_Master_Log_Pos 超过 100,000,000，则 MHA 会认为目标从服务器延迟显著。

哪个主机会被选为新主服务器？

如果主机符合上述条件，则新主服务器的确定基于以下规则。

如果您在某些主机上设置了 candidate_master=1，则它们将被优先选择。
如果它们中有一些是最新的（接收到最新二进制日志事件的从服务器），则该主机将被选择为新主服务器。
如果有多个主机是最新的，则将根据“配置文件中的部分名称排序”来确定主机。例如，如果您有 server1、server2 和 server3 部分，并且 server1 和 server3 都是 candidate_master 并且最新的，则将选择 server1 作为新主服务器。
如果没有服务器设置 candidate_master=1，则最新的从服务器将成为新主服务器。如果有多个最新的从服务器，则将应用“按部分名称排序”规则。
如果没有最新的从服务器可以成为新主服务器，则将从非最新的从服务器中选择一个作为新主服务器。此处也将应用“按部分名称排序”规则。
如果将 latest_priority 参数设置为 0，则“从服务器是否最新”将不影响决定新主服务器。如果您希望完全控制新主服务器的优先级（可以在配置文件中定义规则：按部分名称排序），使用此参数可能有所帮助。

如何使 MHA Manager 节点自身高度可用？

目前，不支持从多个 MHA Manager 监控相同的主服务器。因此，如果 MHA Manager 出现故障，无法启动自动主故障切换。MHA Manager 故障不会导致主服务器故障，因此这就不太严重了，但是您可能希望尽可能地使 MHA Manager 高度可用。当前推荐的 MHA Manager 高可用解决方案是使用常见的主备解决方案，如 Pacemaker。