One ThinkOne Think/
(40条消息) MySQL高可用架构对比，MMM与MHA以及MGR_藏经阁-CSDN博客
Search

(40条消息) MySQL高可用架构对比，MMM与MHA以及MGR_藏经阁-CSDN博客

类型
MySQL
URL
https://blog.csdn.net/William0318/article/details/106855431
是否整理吸收
Date
  • 对主从复制集群中的Master节点进行监控
  • 自动的对Master进行迁移，通过VIP。
  • 重新配置集群中的其它slave对新的Master进行同步

一、MMM

需要两个Master，同一时间只有一个Master对外提供服务，可以说是主备模式。
notion image
notion image
故障转移步骤：
  • Slave服务器上的操作
  • 完成原主上已经复制的日志恢复
  • 使用Change Master命令配置新主
  • 主服务器上操作
  • 设置read_only关闭
  • 迁移VIP到新主服务器
优点：
  • 提供了读写VIP的配置，试读写请求都可以达到高可用
  • 工具包相对比较完善，不需要额外的开发脚本
  • 完成故障转移之后可以对MySQL集群进行高可用监控
缺点：
  • 故障简单粗暴，容易丢失事务，建议采用半同步复制方式，减少失败的概率
  • 目前MMM社区已经缺少维护，不支持基于GTID的复制
适用场景：
  • 读写都需要高可用的
  • 基于日志点的复制方式

二、MHA

notion image
需要资源：
notion image
MHA采用的是从slave中选出Master，故障转移：
  • 从服务器：
  • 选举具有最新更新的slave
  • 尝试从宕机的master中保存二进制日志
  • 应用差异的中继日志到其它的slave
  • 应用从master保存的二进制日志
  • 提升选举的slave为master
  • 配置其它的slave向新的master同步
优点：
  • MHA除了支持日志点的复制还支持GTID的方式
  • 同MMM相比，MHA会尝试从旧的Master中恢复旧的二进制日志，只是未必每次都能成功。如果希望更少的数据丢失场景，建议使用MHA架构。
缺点：
MHA需要自行开发VIP转移脚本。
MHA只监控Master的状态，未监控Slave的状态

三、MGR

MGR是基于现有的MySQL架构实现的复制插件，可以实现多个主对数据进行修改，使用paxos协议复制，不同于异步复制的多Master复制集群。
支持多主模式，但官方推荐单主模式：
  • 多主模式下，客户端可以随机向MySQL节点写入数据
  • 单主模式下，MGR集群会选出primary节点负责写请求，primary节点与其它节点都可以进行读请求处理.
notion image
优点：
  • 基本无延迟，延迟比异步的小很多
  • 支持多写模式，但是目前还不是很成熟
  • 数据的强一致性，可以保证数据事务不丢失
缺点:
  • 仅支持innodb
  • 只能用在GTID模式下，且日志格式为row格式
适用的业务场景：
  • 对主从延迟比较敏感
  • 希望对对写服务提供高可用，又不想安装第三方软件
  • 数据强一致的场景
读写负载大问题
读负载大：
  • 增加slave
  • 加中间层(MyCat，ProxySQL，Maxscale)
  • 读写分离
关于写负载大：
  • 分库分表
  • 增加中间层
一 简介 MGR和PXC的对比
二 WriteSet 1 定义 是组件对于写节点应用事务生成binlog的再封装,用来验证其他节点的事务冲突 PXC 构成 key db_table_组件值 data binlog日志数据 MGR 构成 待补充 2 推送 对于WriteSet的推送 MGR采用的是paxos pxc采用的是gelera组件 3 过程 MGR 主->binlog->验证->commit 从->验证—>relaylog->apply->commit 从->验证—>relaylog->apply->commit PXC 主—>binlog->验证->commit 从->验证->apply->commit
成功 返回 commit ok 失败 返回 deadlock/failure
4 冲突检测
1 MGR 本身每个节点维护一个冲突检测库,记录通过检测的事务(1 库+表+主键ID做的hash值 2 全局事务GTID验证的集合),等待验证的writeset包含本身GTID的集合,会与节点的GTID集合做对比,如果大于,则验证通过,节点GTID集合+1,如果小于,验证失败,整体集合进行回滚 5 总结 PXC和MGR大体的流程是差不多 PXC和MGR对于验证冲突的内部是不一样的
转载于:https://www.cnblogs.com/danhuangpai/p/10365657.html
一 简介 MGR和PXC的对比
二 WriteSet
1 定义 是组件对于写节点应用事务生成binlog的再封装,用来验证其他节点的事务冲突
PXC
构成
key db_table_组件值
data binlog日志数据
MGR 构成
待补充
2 推送
对于WriteSet的推送 MGR采用的是paxos pxc采用的是gelera组件
3 过程
MGR 主->binlog->验证->commit
从->验证—>relaylog->apply->commit
从->验证—>relaylog->apply->commit
PXC 主—>binlog->验证->commit
从->验证->apply->commit
成功 返回 commit ok
失败 返回 deadlock/failure
4 冲突检测
1 MGR 本身每个节点维护一个冲突检测库,记录通过检测的事务(1 库+表+主键ID做的hash值 2 全局事务GTID验证的集合),等待验证的writeset包含本身GTID的集合,会与节点的GTID集合做对比,如果大于,则验证通过,节点GTID集合+1,如果小于,验证失败,整体集合进行回滚
5 总结
PXC和MGR大体的流程是差不多
PXC和MGR对于验证冲突的内部是不一样的

Loading Comments...

Copyright 2021 wanchuan