MySQL高可用架构MMM、MHA、MGR、PXC

  • Z时代
  • 2024-01-10
  • 分类：综合

database

主从复制如何工作

  1. 在主库把数据记录到binlog（二进制日志）。

  2. 备库开IO线程把binlog复制到自己的relaylog（中继日志）。

  3. 备库读取中继日志，重放到备库上。

半同步复制

半同步复制可以确保备库拥有主库数据的拷贝，减少了数据丢失的危险。

半同步复制在提交过程中增加了一个延迟：提交事务时，在客户端接收到查询结束反馈前必须保证二进制日志已经传输到一台备库上。

  • 半同步不会阻塞主库上的事务提交，只有通知客户端被延迟了。

  • 备库在接收到事务后发送ack而不是完成事务后发送。

  • 如果备库一直没有回应，会超时转化为异步复制模式。

配置步骤

在master服务器上

开启binlog开启gtid。

建立同步所用的数据库账号。

使用master_data参数备份数据库。

把备份文件传输到slave。

在slave上操作

开启binlog开启gtid。

恢复master上的备份数据库。

使用change master配置链路。

使用start slave启动复制。

GTID和日志点

日志点复制

  • slave请求master的增量日志依赖于日志偏移量。

  • 配置链路时需要指定参数。

  • 支持MMM和MHA。

GTID复制

  • 全局事务ID唯一，GTID=source_id:transaction_id。

  • slave增量同步master的数据依赖于其未同步的事务ID。

  • 配置链路时，slave根据已经同步的事务ID继续自动同步。

  • 支持MHA。

复制方式选择

  • 兼容老版本和MMM选择日志点复制。

  • 其他选择GTID复制。

‌MMM架构和MHA架构

MMM和MHA架构的作用

  • 对主从复制集群中的master的健康监控。

  • 当master宕机后把写VIP迁移到新的master。

  • 重新配置集群中的其他slave对新的master同步。

MMM的主从复制架构

  • MMM是perl语言开发的用于管理MySQL主主同步架构的工具包。

  • 主要作用：管理MySQL的主主复制拓扑，在主服务器失效时，进行主备切换和故障转移。

  • MMM无法完全的保证数据一致性，所以适用于对数据的一致性要求不是很高的场景。（因为主备上的数据不一定是最新的，可能还没从库的新。解决方法：开启半同步）。

  • VIP是基于ARP协议，因此所有节点必须处于同一局域网。

MMM架构的故障转移步骤

  • SLAVE：

    • 已复制日志的恢复。

    • 使用Change Master命令配置新主。

  • 主备：

    • 关掉read_only。

    • 迁移写VIP到新主。

MMM架构的配置步骤

配置主主复制的集群架构。

安装centos的yum扩展包。

安装所需的perl支持包。

安装mmm工具包。

配置并启用mmm服务。

MMM优点

  • 提供了读写VIP的配置。

MMM缺点

  • 故障切换会丢事务(主备使用半同步复制解决)。

  • 不支持GTID。

  • 社区不活跃。

MHA故障转移步骤

  • 选出最新更新的slave。

  • 尝试从宕机的master保存二进制日志。

  • 应用差异的中继日志给到其他slave。

  • 应用从master保存的二进制日志。

  • 提升选举的slave为新的master。

  • 配置其他slave向新的master同步。

MHA需要的资源

1主DB。

2-N从DB。

n+2IP地址。

监控用户。

复制用户。

MHA配置步骤

配置一主多从的复制架构。

安装centos的yum扩展源和依赖包。

配置集群内各主机的ssh免认证。

各节点安装mha_node软件。

管理节点安装mha_manager。

配置并启动mha管理进程。

MHA优点

  • 基于gtid和日志点。

  • 选举最合适的slave成为master。

MHA缺点

  • 需要自行开发写vip脚本。

  • 只监控master。

适用场景

  • 使用gtid。

  • 一主多从。

  • 更少的数据丢失场景。

‌如何减小主从复制的延迟

主从复制延迟的原因

  • 执行了大事务(解决：化为多个小事务)。

解决方法

  • 多线程复制。

  • 使用MGR复制架构(类似PXC)。

MGR架构

  • MySQL Group Replication（MGR）是MySQL官方在5.7.17版本引进的一个数据库高可用解决方案，以插件形式提供。

  • MGR基于分布式Paxos协议，实现组复制，保证数据一致性。有故障检测和自动选主功能。

  • 提供单主模式与多主模式，多主模式支持多点写入。

  • 基于ROW格式的二进制日志文件和GTID特性。

实现原理

MGR由若干个节点共同组成一个复制组，一个事务的提交，必须经过组内大多数节点（N / 2 + 1）决议并通过，才能得以提交。

引入组复制，主要是为了解决传统异步复制和半同步复制可能产生数据不一致的问题。组复制依靠分布式一致性协议(Paxos协议的变体)，实现了分布式下数据的最终一致性，提供了真正的数据高可用方案（迫真）。

单主模式

MGR优缺点:

  • 组内成员基本无延迟。

  • 支持多写，读写服务高可用。

  • 数据强一致，不丢事务。

MGR缺点:

  • 单主模式很难确认下一个primary。

  • 只能gtid，日志格式必须为row。

场景

  • 主从延迟敏感。

  • 数据强一致。

  • 读写高可用。

‌如何解决读写负载大的问题

读负载大

  • 读写分离加slave。

  • 数据库中间层做负载均衡。

写负载大

  • Mycat分库分表。

扩展知识：VIP与脑裂

VIP的工作原理是，

  • 为当期主机配置一个虚拟网卡，如eth0:0，该网卡绑定了唯一的MAC地址和虚拟IP地址VIP

  • 局域网内的主机欲与该VIP通信时，先通过ARP协议取到该VIP对应的MAC地址，再将VIP与MAC地址的对应关系缓存在其主机上

  • 后续通信时，使用上一步骤取到的MAC作为报文的MAC地址

VIP切换的原理是，

  • 将旧master绑定的虚拟网卡注销掉

  • 在新的master注册新的虚拟网卡（产生了新的MAC地址）

  • 通知局域网节点更新VIP与MAC的对应关系，后续通信采用新MAC地址

脑裂的原因，在于旧master节点没有正常将VIP摘掉，这时局域网机器通过ARP获取VIP的MAC时，就可能取到旧的MAC地址，导致与旧master通信。什么情况会出现这种情况呢？旧master由于上层交换机故障，未与manager节点正常通信，此时VIP是没有摘除掉的，过了一段时间上层交换机恢复了就会导致此问题。

https://zhangjunjia.github.io/2019/03/16/mysql-mmm-mha/

https://www.pianshen.com/article/13731481649/

Re

以上是 MySQL高可用架构MMM、MHA、MGR、PXC 的全部内容， 来源链接： utcz.com/z/535987.html

回到顶部