MySQL高可用架构特点对比

一、MHA

MHA特点

  • 监控主数据库服务器是否可用
  • 当主DB不可用时,从多个从服务器中选举出新的主数据库服务器
  • 提供了主从切换和故障转移功能

MHA优点

  • MHA在进行故障转移时更不易产生数据丢失,可以将最新的二进制日志应用于所有节点
  • 同一个监控节点能够监控多个集群

MHA缺点

  • 须要编写脚本或利用第三方工具来实现Vip的配置
  • MHA只能进行一次故障切换
  • MHA启动后只会对主数据库进行监控
  • 须要基于SSH免认证配置,存在必定的安全隐患
  • 没有提供从库的读负载均衡功能

二、PXC

PXC特点

  • 同步复制,事务要么所有节点提交或不提交,保证每个节点的一致性
  • 多主复制,可在任意节点写
  • 真正意义的基于行的并行复制
  • 自动的节点添加

PXC优点

  • 完全兼容已有的系统
  • 便于迁移
  • 快速的回退版本

PXC缺点

  • 只支持Innodb存储引擎,表必须有主键
  • 多节点并发写时,锁冲突问题,不允许大事务的产生
  • 写性能取决于最差的节点(尽量保持节点配置一致)
  • 不能解决热点更新问题
  • 自动添加新节点可能引起很大的抖动

三、MGR

MGR特点

高一致性,高容错性,高拓展性,高灵活性

可设置单主模式、多主模式

  • MGR 是基于 Paxos 协议和原生复制的分布式集群,大多数节点同意即可以通过议题的模式,数据一致性高。
  • 具备高可用、自动故障检测功能,可自动切换。
  • 可弹性扩展,集群自动的新增和移除节点
  • 有单主和多主模式。支持多节点写入,具备冲突检测机制,可以适应多种应用场景需求。

MGR局限性

  • 存储引擎必须为Innodb,即仅支持InnoDB表,并且每张表一定要有一个主键,用于做write set的冲突检测;
  • 需设置binglog_checknum=none
  • 不支持间隙锁,隔离级别需设置为read_commited
  • 不支持对表进行加锁操作(lock,unlock),此命令不会发送到其他节点,影响mysqldump进行全表备份这样的操作
  • DDL不支持原子性,不能检测冲突,执行后需自行校验是否一致。多主模式不支持在不同节点上对同一个数据库对象并发执行DDL(在不同节点上对同一行并发进行RW事务,后发起的事务会失败);
  • 只支持ipv4,网络需求较高;
  • 必须打开GTID特性,二进制日志格式必须设置为ROW,用于选主与write set;
  • COMMIT可能会导致失败,类似于快照事务隔离级别的失败场景;
  • 目前一个MGR集群组最多支持9个节点;
  • 多主模式不支持外键于save point特性,无法做全局间的约束检测与部分部分回滚;
  • 二进制日志binlog不支持Replication event checksums;
  • 多主模式不支持SERIALIZABLE事务隔离级别;

四、MMM

MMM的特点

监控和管理mysql的主主复制拓扑,并在当前的主服务器失效时,进行主和主备服务器之间的主从切换和故障转移等工作

  • MMM监控主从复制健康情况
  • 在主库出现宕机时进行故障转移并自动配置其他从服务器对新主服务器的复制
    • 如何找到从库对应的新的主库日志中的同步点
    • 如果存在多个从库出现数据不一致的情况,如何处理
  • 提供了主,写 虚拟IP,在主从服务器 出现问题时,可以自动迁移虚拟IP

MMM的优点

  1. 提供了读写虚拟IP,使服务器角色的变更对前端应用透明
  2. 在从服务器出现大量主从延迟,主从链路中断时,可以把这台服务器上的读的虚拟IP,漂移到集群中其他正常的服务器上
  3. MMM提供了从服务器的延迟监控
  4. MMM提供了主数据库故障转移后,从服务器对新主服务器的重新同步功能
  5. 很容易对发生故障的主数据库重新上线

MMM的缺点

  1. 发布时间比较早,不支持MYSQL新的复制功能(只支持是基于日志点的复制)
    1. 注:基于gtid的复制可以保证日志不会重复在slave服务器上被执行
    2. 对于mysql5.6后所提供的多线程复制技术也不支持
  2. 在进行主从切换时,容易造成数据丢失
  3. MMM监控服务存在单点故障

你可能感兴趣的:(MySQL,mysql,架构)