Mysql学习笔记---MySQL集群架构之双主模式

Mysql学习笔记—MySQL集群架构之双主模式缺实战

1. 双主模式简介

  1. 很多企业刚开始都是使用MySQL主从模式一主多从读写分离等。
  2. 但是单主如果发生单点故障,从库切换成主库还需要作改动。因此,如果是双主或者多主,就会增加MySQL入口,提升了主库的可用性。
  3. 因此随着业务的发展,数据库架构可以由主从模式演变为双主模式。双主模式是指两台服务器互为主从,任何一台服务器数据变更,都会通过复制应用到另外一方的数据库中。
  4. 当一个主库坏掉了,那么还自动切换到另一个主库中去
  5. 两个主库互为主从关系
  6. 主从复制是通过binlog日志文件进行的,两台主库不会无休止向对方发送binlog日志的,因为是日志信息中还会带有server_id的信息,在日志发送的时候会检测一下发送的server_id是不是我们刚接收过来的server_id,如果是的话就不发送了,从而避免了这样反复循环复制

2. 双主模式下采用哪种写法模式: 使用双主双写还是双主单写?

建议大家使用双主单写,因为双主双写存在以下问题:
  1. ID冲突
    1. 在A主库写入,当A数据未同步到B主库时,对B主库写入,如果采用自动递增容易发生ID主键的冲突。
    2. 可以采用MySQL自身的自动增长步长来解决例如: A的主键为1,3,5,7…,B的主键为2,4,6,8… ,但是对数据库运维、扩展都不友好,如果数据库运维的时候把步长改掉了,那么就很难受了。
  2. 更新丢失
    1. 同一条记录在两个主库中进行更新,会发生前面覆盖后面的更新丢失。
  3. 高可用架构如下图所示,其中一个Master提供线上服务,另一个Master作为备胎供高可用切换,Master下游挂载Slave承担读请求。
  4. 随着业务发展,架构会从主从模式演变为双主模式建议用双主单写,再引入高可用组件,例如KeepalivedMMM等工具,实现主库故障自动切换。
    Mysql学习笔记---MySQL集群架构之双主模式_第1张图片

3. 实战: 虽然有两台主库,但是并不是两台主库同时运行,是一台作为主要的,一台作为备用的

  1. 设置配置,红框里面是追加的,如下所示,修改完后记得重启mysql服务:
    Mysql学习笔记---MySQL集群架构之双主模式_第2张图片
  2. 配置另一台master2的内容,如下所示,还是记得重启一下mysql的服务:
    Mysql学习笔记---MySQL集群架构之双主模式_第3张图片
  3. 给master2中授权,查看状态
    Mysql学习笔记---MySQL集群架构之双主模式_第4张图片
  4. 指定master1复制master2的命令,并且启动start slave,如下图所示:
    在这里插入图片描述
  5. 查看master1作为从库的状态:
    Mysql学习笔记---MySQL集群架构之双主模式_第5张图片
  6. 指定master2复制master1的命令,并且启动start slave,让master2和master1互为主从,如下图所示:
    在这里插入图片描述
  7. 查看master2作为从库的状态:
    Mysql学习笔记---MySQL集群架构之双主模式_第6张图片
  8. 以上的操作是将双主的配置做完了,做双柱双写的时候要注意两台master的主键id和id的增长区间

4. MMM高可用架构方案: 也是一套比较成熟的双主模式的架构

  1. MMM(Master-Master Replication Manager for MySQL,主主复制管理)是一套用来管理和监控双主复制,支持双主故障切换的第三方软件。
  2. MMM使用Perl语言开发,虽然是双主架构,但是业务上同一时间只允许一个节点进行写入操作。
  3. 下图是基于MMM实现的主高可用架构
  4. VIP是虚拟IP的意思
    Mysql学习笔记---MySQL集群架构之双主模式_第7张图片

5. MMM故障处理机制

  1. MMM包含writerreader两类角色,分别对应写节点读节点
    1. 当 writer节点出现故障,程序会自动移除该节点上的VIP
    2. 写操作切换到 Master2,并将Master2设置为writer
    3. 将所有Slave节点会指向Master2
  2. 除了管理双主节点,MMM 也会管理 Slave 节点,在出现宕机、复制延迟或复制错误,MMM会移除该节点的 VIP,直到节点恢复正常。

6. MMM监控机制

  1. MMM 包含monitor和agent两类程序,功能如下:
    1. monitor:监控集群内数据库的状态,在出现异常时发布切换命令,一般和数据库分开部署。
    2. agent:运行在每个 MySQL 服务器上的代理进程,monitor 命令的执行者,完成监控的探针工作和具体服务设置,例如设置 VIP(虚拟IP)、指向新同步节点,将节点信息返回给monitor。

7. MHA架构介绍:

  1. MHA(Master High Availability)是一套比较成熟的 MySQL 高可用方案,也是一款优秀的故障切换和主从提升的高可用软件。

  2. MySQL故障切换过程中,MHA能做到在30秒之内自动完成数据库的故障切换操作,并且在进行故障切换的过程中,MHA能在最大程度上保证数据的一致性,以达到真正意义上的高可用。

  3. MHA还支持在线快速将Master切换到其他主机,通常只需0.5-2秒。

  4. 目前MHA主要支持一主多从的架构,要搭建MHA,要求一个复制集群中必须最少有三台数据库服务器(一主二从,内部实现主从复制)

  5. MHA可以同时监控这几个主从复制的集群,同时也看出来MHA可以同时监控多个集群。
    Mysql学习笔记---MySQL集群架构之双主模式_第8张图片

  6. MHA由两部分组成:MHA Manager(管理节点)和MHA Node(数据节点)。

    1. MHA Manager可以单独部署在一台独立的机器上管理多个master-slave集群,也可以部署在一台slave节点上。负责检测master是否宕机、控制故障转移、检查MySQL复制状况等。
    2. MHA Node运行在每台MySQL服务器上,不管是Master角色,还是Slave角色,都称为Node,是被监控管理的对象节点,负责保存和复制master的二进制日志、识别差异的中继日志事件并将其差异的事件应用于其他的slave、清除中继日志。
  7. MHA Manager会定时探测集群中的master节点,当master出现故障时,它可以自动将最新数据的slave提升为新的master,然后将所有其他的slave重新指向新的master,整个故障转移过程对应用程序完全透明。

8.MHA故障处理机制

  1. 把宕机master的binlog保存下来
  2. 根据binlog位置点找到最新的slave
  3. 用最新slave的relay log修复其它slave
  4. 将保存下来的binlog在最新的slave上恢复
  5. 将最新的slave提升为master
  6. 将其它slave重新指向新提升的master,并开启主从复制

9.MHA优点

  1. 自动故障转移快
  2. 主库崩溃不存在数据一致性问题,现有的一致性,目前还是可以保证的
  3. 性能优秀,支持半同步复制和异步复制
  4. 一个Manager监控节点可以监控多个集群

10. 主备切换简介: 是指将备库变为主库,主库变为备库,有可靠性优先可用性优先两种策略。

  1. 主备延迟问题:主备延迟是由主从数据同步延迟导致的,与数据同步有关的时间点主要包括以下三个
    1. 主库 A 执行完成一个事务,写入 binlog,我们把这个时刻记为 T1;
    2. 之后将binlog传给备库 B,我们把备库 B 接收完 binlog 的时刻记为 T2;
    3. 备库 B 执行完成这个binlog复制,我们把这个时刻记为 T3。
  2. 所谓主备延迟,就是同一个事务,在备库执行完成的时间和主库执行完成的时间之间的差值,也就是T3-T1
  3. 在备库上执行show slave status命令,它可以返回结果信息,seconds_behind_master表示当前备库延迟了多少秒。
  4. 同步延迟主要原因如下
    1. 备库机器性能问题:机器性能差,甚至一台机器充当多个主库的备库。
    2. 分工问题:备库提供了读操作,或者执行一些后台分析处理的操作,消耗大量的CPU资源。
    3. 大事务操作:大事务耗费的时间比较长,导致主备复制时间长。比如一些大量数据的delete或大表DDL操作都可能会引发大事务。

11.主备切换之可靠性优先

  1. 主备切换过程一般由专门的HA高可用组件完成,但是切换过程中会存在短时间不可用,因为在切换过程中某一时刻主库A和从库B都处于只读状态。
    Mysql学习笔记---MySQL集群架构之双主模式_第9张图片

  2. 主库由A切换到B,切换的具体流程如下:

    1. 判断从库B的Seconds_Behind_Master(主备的延迟时间)值,当小于某个约定值才继续下一步
    2. 把主库A改为只读状态(readonly=true)
    3. 等待从库B的Seconds_Behind_Master值降为 0
    4. 把从库B改为可读写状态(readonly=false)
    5. 把业务请求切换至从库B

11.主备切换之可用性优先

  1. 不等主从同步完成, 直接把业务请求切换至从库B ,并且让从库B可读写 ,这样几乎不存在不可用时间,但可能会数据不一致。
    Mysql学习笔记---MySQL集群架构之双主模式_第10张图片
  2. 如上图所示,在A切换到B过程中,执行两个INSERT操作,过程如下:
    1. 主库A执行完 INSERT c=4 ,得到 (4,4) ,然后开始执行 主从切换
    2. 主从之间有5S的同步延迟,从库B会先执行 INSERT c=5 ,得到 (4,5)
    3. 从库B执行主库A传过来的binlog日志 INSERT c=4 ,得到 (5,4)
    4. 主库A执行从库B传过来的binlog日志 INSERT c=5 ,得到 (5,5)
    5. 此时主库A和从库B会有两行不一致的数据
  3. 通过上面介绍了解到,主备切换采用可用性优先策略,由于可能会导致数据不一致,所以大多数情况下,优先选择可靠性优先策略。
  4. 在满足数据可靠性的前提下,MySQL的可用性依赖于同步延时的大小,同步延时越小,可用性就越高。

你可能感兴趣的:(Mysql)