☰

主从 Mysql 复制的自动故障转移策略--为什么它不起作用？

tag-icon • tag-icon mysql replication master-slave
主从 Mysql 复制的自动故障转移策略--为什么它不起作用？

我想要一些关于我为集群指定的几个 MySQL 服务器的故障转移策略的反馈，并且我想检查是否存在我没​​有遗漏的明显的东西。

一个应用服务器在日常操作中连接到 mysql 主服务器，并且将 mysql 服务器设置为从服务器，以实现主从复制目的。

如果 mysql 服务器出现故障，我希望 Web 应用程序尝试连接到主服务器，然后在n尝试失败后执行以下操作：

  • 假设 master 将不再可用
  • 向从属服务器发送信号停止复制
  • 向从服务器发送信号，告诉它充当新的 mysql 主服务器
  • 再次开始连接到服务器，并从现在开始将其视为主服务器

一旦应用程序再次启动并为用户提供服务，我希望能够在后台启动一个新的从属服务器，一旦它准备好处理请求，就再次设置主从复制以提供与以前相同的故障转移支持。

我很确定以前有人这样做过，但我没有看到任何关于此的指南，所以我认为一定有一些显而易见的原因让你不愿意尝试，而我还没有想到。

采用这种方法为 MySQL 提供自动故障转移有什么缺陷？

顺便说一句，我知道主-主复制，但是 a) 我见过它出现严重问题，并且 b) 看起来过于复杂，令人担忧。

谢谢

答案1

自动故障转移不利的原因与复制滞后有关。如果从服务器恰好落后并且发生故障转移，则您可能正在使用尚不存在的键写入更新，因为主服务器的插入尚未写入。复制滞后越多，这个问题就越严重。在我的公司，我们使用 DRBD 进行自动故障转移，因为您故障转移到的 DRBD 服务器是原始主服务器的精确磁盘级副本。作为一项政策，我们手动进行主/从服务器和主/主设置的故障转移。

答案2

您想要的是一个高可用性集群，我认为您建议的方法似乎有点奇怪。

实现此目的的一个好方法是创建一个 Linux HA 集群并使用文件系统级别的 DRDB 同步来同步您的 MySQL。

在这样的设置中，你有 3 件事：

  1. 集群消息层（Linux-HA 或 CoroSync）
  2. 集群资源管理器 (Pacemaker)
  3. 磁盘同步（DRDB）

您无需在应用程序中编写大量代码，只需使用虚拟 IP 地址，然后将其移动到当前活动节点即可。此外，您还使用 STONITH（Shoot The Other Node In The Head（我没有编造））确保第一个节点在尝试接管资源之前确实已死。

这些链接上有一些很棒的材料可供阅读： http://www.linux-ha.org/wiki/Main_Page http://www.clusterlabs.org/wiki/DRBD_MySQL_HowTo http://theclusterguy.clusterlabs.org/

答案3

我不会排除主-主复制。事实上，你所描述的几乎就是主-主复制。

看一下MMM（MySQL的多主复制管理器）。http://mysql-mmm.org/它在 mysql 层工作，因此比基于 OS 的集群工作得更好。

相关内容