【MySQL】MMM和MHA高可用架构

  • 用途

  1. 对MySQL主从复制集群的Master的健康监控。
  2. 当Master宕机后把写VIP迁移到新Master。
  3. 重新配置集群中的其他Slave从新Master同步

 

  • MMM架构

【MySQL】MMM和MHA高可用架构_第1张图片

  主服务器发生故障时,

    1.主备服务器切换为新的主服务器

      (1)主备服务器设置read_only=off。

      (2)主备服务器迁移写VIP到自己。

    2.从服务器切换指向新的主服务器

      (1)完成原主服务器上已复制日志的恢复。

      (2)使用Change Master to命令连接指向新的主服务器。

 

  • MMM架构优点

  1. 提供了读写VIP的配置,使得读写请求都可以做到高可用

  2. 工具包相对完善,不需要额外开发脚本。
  3. 完成故障转移后,可以继续对MySQL集群进行高可用监控。

 

  • MMM架构缺点

  1. 故障切换简单粗暴易丢事务。解决方案:使用MySQL5.7及之后的半同步复制。

  2. 原生不支持GTID的复制方式。解决方案:自行修改perl脚本实现。
  3. 社区不活跃,很久未更新版本了。
  4. 需要的机器和IP地址资源较多。

 

  • MHA架构

【MySQL】MMM和MHA高可用架构_第2张图片

  主服务器发生故障时,

    1.选举具有最新更新的Slave从节点。

    2.尝试从宕机的Master主节点保存bin_log。

    3.应用差异的中继relay_log到其他Slave从节点。

    4.应用从Master主节点保存的bin_log。

    5.提升选举出的Slave从节点为新的Master主节点。

    6.配置其他Slave从节点从新的Master主节点主从同步。

 

  • MHA架构优点

  1. 既支持日志点的主从同步,也支持GTID的主从同步

  2. 可从多个Slave中选举出最合适的新Master,无需单独准备一个Master备机
  3. 尝试从老Master尽可能多的保存和获取未同步日志。

 

  • MHA架构缺点

  1. 未必能获取到老Master未同步日志。解决方案:使用MySQL5.7及之后的半同步复制。

  2. 需要自行开发写VIP转移脚本。
  3. 只保证了Master高可用,未保证Slave高可用

你可能感兴趣的:(【MySQL】MMM和MHA高可用架构)