区别 | MHA | PXC |
特点 | 可在0~30s内完成数据可自动故障切 换 故障切换过程中最大限度保证数据库 的一致性 | 数据强—致性,无同步延迟 没有主从切换操作,无需使用虚拟IP 支持InnoDB存储引擎 部署使用简单 支持节点自动加入,无需手动拷贝数据 |
组成 | 1个MHA Manger(管理节点) 多个MHA Node(数据节点) | 最少三台 |
工作过程 | Manger定时探测集群中的master节 点 当master故障时,Manger自动将拥 有最近数据的slave提升为master | 任意节点收到sql请求,对于代码更新操作失 误,在提交之前,有Wsrep API调用galera库进 行集群内部广播,验证当前事务是否能在所有 节点中执行,验证通过后该事务真正提交到— 群所有节点执行,泛指roll back回滚。次验证 机制是为了确保所有节点的数据—致性。 |
配置过程 | 配置MYSQL集群服务器,配置一主 多从,半同步复制,配置一台独立的 管理服务器,安装MHA软件包,指 定MYSQL服务器集群,穿件故障切 换脚本,测试ssh和主从同步成功 后,启动管理服务。 | 在几台(最少三台)没有安装数据库服务器的 主机上直接安装pxc相关软件,包括在线热备 和集群服务等,修改配置文件,,指定集群ip 等,初始化启动,其他服务器正常启动会自动 完成与第—胎初始化启动的服务器同步数据。 |
区别 | MHA | PXC |
优点 | 成熟稳定、对MySQL侵入小、宕机 后保证数据—致 | 实现了MySQL集群的高可用性和数据的强一致 性 ; 完成了真正的多节点读写的集群方案; 改善了主从复制延迟的问题,基本上达到了实 时同步 ; 新加入的节点可以自动同步数据,无需提前手 动备份,维护方便; 由于是多节点写入,所以数据库故障切换很容 易 |
缺点 | 需要编写脚本或利用第三方工具来实 现VIP的配置; MHA启动后只会对主数据库进行监 控 ; 需要基于SSH免认证配置,存在一定 的安全隐患; 没有提供从服务器的读负载均衡功 能 ; | ●加入新节点时开销大,因为添加新节点时, 必须从现有节点之一复制完整的数据集,如果 现有的数据库中数据为100GB,则复制 100GB; ●任何更新的事务都需要全局验证通过,才会 在其他节点上执行,集群性能受限于最差的节 点,也就是所谓的短板效应(木桶定律); ●因为需要保证数据的一致性,PXC采用的实 时基于存储引擎层来实现同步复制,所以在多 节点并发写入时,锁冲突问题比较严重; ●存在写扩大的问题,所有节点上都会发生写 操作,对于写负载较大的场景,不推荐使用 PXC; ●仅支持Inno db存储引擎; |
MHA工作原理:
配置一主服从结构和半同步复制,当客户端访问虚拟IP(vip)登录主服务器存储数据时,从服务器自动同步主服务器数据,并且等待至少一台从服务器完成同步后,主服务器才将结果返回客户端,MHA管理主机定时监控集群中的master主机,发现主机宕机后,邹东江拥有最新数据的从服务器提升为主服务器。(半同步复制的作用,当出现网络延迟或物理故障导致无法将数据返回给客户端,半同步复制会在系统设置的一定时间内主动返回数据给客户端)
MHA部署过程:
配置MYSQL集群服务器,配置一主多从,半同步复制,配置一台独立的管理服务器,安装MHA软件包, 指定MYSQL服务器集群,穿件故障切换脚本,测试ssh和主从同步成功后,启动管理服务。
PXC工作原理:
任意节点收到sql请求,对于代码更新操作失误,在提交之前,有wsrep API调用galera库进行集群内部广播, 验证当前事务是否能在所有节点中执行,验证通过后该事务真正提交到一群所有节点执行,泛指roll back回滚。次验证机制是为了确保所有节点的数据一致性。
PXC部署过程:
在几台(最少三台)没有安装数据库服务器的主机上直接安装pxc相关软件, 包括在线热备和集群服务等,修改配置文件,,指定集群ip等,初始化启动,其他服务器正常启动会自动完成与第一胎初始化启动的服务器同步数据。