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. 随着业务发展，架构会从主从模式演变为双主模式，建议用双主单写，再引入高可用组件，例如：Keepalived和MMM等工具，实现主库故障自动切换。
   

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

1. 设置配置，红框里面是追加的，如下所示，修改完后记得重启mysql服务：
   
2. 配置另一台master2的内容，如下所示，还是记得重启一下mysql的服务：
   
3. 给master2中授权，查看状态
   
4. 指定master1复制master2的命令，并且启动start slave，如下图所示：
   
5. 查看master1作为从库的状态：
   
6. 指定master2复制master1的命令，并且启动start slave，让master2和master1互为主从，如下图所示：
   
7. 查看master2作为从库的状态：
   
8. 以上的操作是将双主的配置做完了，做双柱双写的时候要注意两台master的主键id和id的增长区间

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

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

5. MMM故障处理机制

1. MMM包含writer和reader两类角色，分别对应写节点和读节点。
   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可以同时监控多个集群。
   

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都处于只读状态。
   

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可读写 ，这样几乎不存在不可用时间，但可能会数据不一致。
   
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的可用性依赖于同步延时的大小，同步延时越小，可用性就越高。