Mysql中MHA的原理是什么

67次阅读
没有评论

共计 2864 个字符,预计需要花费 8 分钟才能阅读完成。

本篇内容介绍了“Mysql 中 MHA 的原理是什么”的有关知识,在实际案例的操作过程中,不少人都会遇到这样的困境,接下来就让丸趣 TV 小编带领大家学习一下如何处理这些情况吧!希望大家仔细阅读,能够学有所成!

MHA 简介

MHA 是由日本人 yoshinorim(原就职于 DeNA 现就职于 FaceBook)开发的比较成熟的 MySQL 高可用方案。MHA 能够在 30 秒内实现故障切换,并能在故障切换中,最大可能的保证数据一致性。目前淘宝也正在开发相似产品 TMHA,目前已支持一主一从。
 

MHA 架构

MHA 由 MHA Manager 和 MHA Node 组成, 如下图所示:

MHA Manager:
运行一些工具,比如 masterha_manager 工具实现自动监控 MySQL Master 和实现 master 故障切换,其它工具实现手动实现 master 故障切换、在线 mater 转移、连接检查等等。一个 Manager 可以管理多个 master-slave 集群
 
MHA Node:
部署在所有运行 MySQL 的服务器上,无论是 master 还是 slave。主要作用有三个。
    Ⅰ、保存二进制日志
            如果能够访问故障 master,会拷贝 master 的二进制日志
     II、应用差异中继日志
          从拥有最新数据的 slave 上生成差异中继日志,然后应用差异日志。
     III、清除中继日志
          在不停止 SQL 线程的情况下删除中继日志
 
MHA 工作原理

当 master 出现故障时,通过对比 slave 之间 I / O 线程读取 masterbinlog 的位置,选取最接近的 slave 做为 latestslave。其它 slave 通过与 latest slave 对比生成差异中继日志。在 latest slave 上应用从 master 保存的 binlog,同时将 latest slave 提升为 master。最后在其它 slave 上应用相应的差异中继日志并开始从新的 master 开始复制。
在 MHA 实现 Master 故障切换过程中,MHA Node 会试图访问故障的 master(通过 SSH),如果可以访问(不是硬件故障,比如 InnoDB 数据文件损坏等),会保存二进制文件,以最大程度保证数据不丢失。MHA 和半同步复制一起使用会大大降低数据丢失的危险。
 
当前高可用方案
Heartbeat+DRBD:
开销:需要额外添加处于被动状态的 master server(并不处理应用流量)
性能:为了实现 DRBD 复制环境的高可用,innodb-flush-log-at-trx-commit 和 sync-binlog 必须设置为 1,这样会导致写性能下降。
一致性:在 master 上必要的 binlog 时间可能会丢失,这样 slave 就无法进行复制,导致产生数据一致性问题

MySQL Cluster:
MySQL Cluster 真正实现了高可用,但是使用的是 NDB 存储引擎,并且 SQL 节点有单点故障问

半同步复制 (5.5+)
半同步复制大大减少了“binlog events 只存在故障 master 上”的问题。
在提交时,保证至少一个 slave(并不是所有的)接收到 binlog,因此一些 slave 可能没有接收到 binlog。

全局事务 ID
在二进制文件中添加全局事务 ID(global transaction id)需要更改 binlog 格式,在 5.1/5.5 版本中不支持。
在应用方面有很多方法可以直线全局事务 ID,但是仍避免不了复杂度、性能、数据丢失或者一致性的问题。
PXC:
PXC 实现了服务高可用,数据同步时是并发复制。但是仅支持 InnoDB 引擎,所有的表都要有主键。锁冲突、死锁问题相对较多等等问题。

MHA 的优势
1、故障切换快
在主从复制集群中,只要从库在复制上没有延迟,MHA 通常可以在数秒内实现故障切换。9-10 秒内检查到 master 故障,可以选择在 7 -10 秒关闭 master 以避免出现裂脑,几秒钟内,将差异中继日志(relay log)应用到新的 master 上,因此总的宕机时间通常为 10-30 秒。恢复新的 master 后,MHA 并行的恢复其余的 slave。即使在有数万台 slave,也不会影响 master 的恢复时间。
DeNA 在超过 150 个 MySQL(主要 5.0/5.1 版本)主从环境下使用了 MHA。当 mater 故障后,MHA 在 4 秒内就完成了故障切换。在传统的主动 / 被动集群解决方案中,4 秒内完成故障切换是不可能的。
 
2、master 故障不会导致数据不一致
当目前的 master 出现故障是,MHA 自动识别 slave 之间中继日志(relay log)的不同,并应用到所有的 slave 中。这样所有的 salve 能够保持同步,只要所有的 slave 处于存活状态。和 Semi-Synchronous Replication 一起使用,(几乎)可以保证没有数据丢失。

3、无需修改当前的 MySQL 设置
MHA 的设计的重要原则之一就是尽可能地简单易用。MHA 工作在传统的 MySQL 版本 5.0 和之后版本的主从复制环境中。和其它高可用解决方法比,MHA 并不需要改变 MySQL 的部署环境。MHA 适用于异步和半同步的主从复制。
启动 / 停止 / 升级 / 降级 / 安装 / 卸载 MHA 不需要改变(包扩启动 / 停止)MySQL 复制。当需要升级 MHA 到新的版本,不需要停止 MySQL,仅仅替换到新版本的 MHA,然后重启 MHA Manager 就好了。
MHA 运行在 MySQL 5.0 开始的原生版本上。一些其它的 MySQL 高可用解决方案需要特定的版本(比如 MySQL 集群、带全局事务 ID 的 MySQL 等等),但并不仅仅为了 master 的高可用才迁移应用的。在大多数情况下,已经部署了比较旧 MySQL 应用,并且不想仅仅为了实现 Master 的高可用,花太多的时间迁移到不同的存储引擎或更新的前沿发行版。MHA 工作的包括 5.0/5.1/5.5 的原生版本的 MySQL 上,所以并不需要迁移。

4、无需增加大量的服务器
MHA 由 MHA Manager 和 MHA Node 组成。MHA Node 运行在需要故障切换 / 恢复的 MySQL 服务器上,因此并不需要额外增加服务器。MHA Manager 运行在特定的服务器上,因此需要增加一台(实现高可用需要 2 台),但是 MHA Manager 可以监控大量(甚至上百台)单独的 master,因此,并不需要增加大量的服务器。即使在一台 slave 上运行 MHA Manager 也是可以的。综上,实现 MHA 并没用额外增加大量的服务。

5、无性能下降
MHA 适用与异步或半同步的 MySQL 复制。监控 master 时,MHA 仅仅是每隔几秒(默认是 3 秒)发送一个 ping 包,并不发送重查询。可以得到像原生 MySQL 复制一样快的性能。

6、适用于任何存储引擎
MHA 可以运行在只要 MySQL 复制运行的存储引擎上,并不仅限制于 InnoDB,即使在不易迁移的传统的 MyISAM 引擎环境,一样可以使用 MHA。

“Mysql 中 MHA 的原理是什么”的内容就介绍到这里了,感谢大家的阅读。如果想了解更多行业相关的知识可以关注丸趣 TV 网站,丸趣 TV 小编将为大家输出更多高质量的实用文章!

正文完
 
丸趣
版权声明:本站原创文章,由 丸趣 2023-08-03发表,共计2864字。
转载说明:除特殊说明外本站除技术相关以外文章皆由网络搜集发布,转载请注明出处。
评论(没有评论)