Mysql学习笔记—MySQL集群架构之双主模式缺实战
1. 双主模式简介
- 很多企业刚开始都是使用MySQL
主从模式，一主多从、读写分离等。 - 但是
单主如果发生单点故障，从库切换成主库还需要作改动。因此，如果是双主或者多主，就会增加MySQL入口，提升了主库的可用性。 - 因此随着业务的发展，数据库架构可以由
主从模式演变为双主模式。双主模式是指两台服务器互为主从，任何一台服务器数据变更，都会通过复制应用到另外一方的数据库中。 - 当一个主库坏掉了，那么还自动切换到另一个主库中去
- 两个主库
互为主从关系 - 主从复制是通过
binlog日志文件进行的,两台主库不会无休止向对方发送binlog日志的，因为是日志信息中还会带有server_id的信息,在日志发送的时候会检测一下发送的server_id是不是我们刚接收过来的server_id,如果是的话就不发送了，从而避免了这样反复循环复制
2. 双主模式下采用哪种写法模式： 使用双主双写还是双主单写？
建议大家使用双主单写，因为双主双写存在以下问题：
ID冲突- 在A主库写入，当A数据未同步到B主库时，对B主库写入，如果采用自动递增容易发生ID主键的冲突。
可以采用MySQL自身的自动增长步长来解决，例如: A的主键为1,3,5,7…，B的主键为2,4,6,8… ，但是对数据库运维、扩展都不友好,如果数据库运维的时候把步长改掉了，那么就很难受了。
更新丢失- 同一条记录在两个主库中进行更新，会发生前面覆盖后面的更新丢失。
- 高可用架构如下图所示，其中一个Master提供线上服务，另一个Master作为备胎供高可用切换，Master下游挂载Slave承担读请求。
- 随着业务发展，架构会从
主从模式演变为双主模式，建议用双主单写，再引入高可用组件，例如：Keepalived和MMM等工具，实现主库故障自动切换。
3. 实战： 虽然有两台主库，但是并不是两台主库同时运行，是一台作为主要的，一台作为备用的
- 设置配置，红框里面是追加的，如下所示，修改完后记得重启mysql服务：
- 配置另一台master2的内容，如下所示，还是记得重启一下mysql的服务：
- 给master2中授权，查看状态
- 指定master1复制master2的命令，并且启动
start slave，如下图所示：
- 查看master1作为从库的状态：
- 指定master2复制master1的命令，并且启动
start slave，让master2和master1互为主从，如下图所示：
- 查看master2作为从库的状态：
- 以上的操作是将双主的配置做完了，做双柱双写的时候要注意两台master的主键id和id的增长区间
4. MMM高可用架构方案： 也是一套比较成熟的双主模式的架构
MMM（Master-Master Replication Manager for MySQL，主主复制管理）是一套用来管理和监控双主复制，支持双主故障切换的第三方软件。MMM使用Perl语言开发，虽然是双主架构，但是业务上同一时间只允许一个节点进行写入操作。- 下图是基于
MMM实现的主高可用架构。 - VIP是虚拟IP的意思
5. MMM故障处理机制
MMM包含writer和reader两类角色，分别对应写节点和读节点。- 当 writer节点出现故障，程序会自动移除该节点上的VIP
- 写操作切换到 Master2，并将Master2设置为writer
- 将所有Slave节点会指向Master2
除了管理双主节点，MMM 也会管理 Slave 节点，在出现宕机、复制延迟或复制错误，MMM会移除该节点的 VIP，直到节点恢复正常。
6. MMM监控机制
- MMM 包含monitor和agent两类程序，功能如下：
monitor：监控集群内数据库的状态，在出现异常时发布切换命令，一般和数据库分开部署。agent：运行在每个 MySQL 服务器上的代理进程，monitor 命令的执行者，完成监控的探针工作和具体服务设置，例如设置 VIP（虚拟IP）、指向新同步节点，将节点信息返回给monitor。
7. MHA架构介绍：
-
MHA（Master High Availability）是一套比较成熟的 MySQL 高可用方案，也是一款优秀的故障切换和主从提升的高可用软件。 -
在
MySQL故障切换过程中，MHA能做到在30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。 -
MHA还支持在线快速将Master切换到其他主机，通常只需0.5－2秒。 -
目前MHA主要支持一主多从的架构，要搭建MHA，要求一个复制集群中必须最少有三台数据库服务器(一主二从，内部实现主从复制)。 -
MHA可以同时监控这几个主从复制的集群,同时也看出来MHA可以同时监控多个集群。
-
MHA由两部分组成：MHA Manager（管理节点）和MHA Node（数据节点）。MHA Manager可以单独部署在一台独立的机器上管理多个master-slave集群，也可以部署在一台slave节点上。负责检测master是否宕机、控制故障转移、检查MySQL复制状况等。MHA Node运行在每台MySQL服务器上，不管是Master角色，还是Slave角色，都称为Node，是被监控管理的对象节点，负责保存和复制master的二进制日志、识别差异的中继日志事件并将其差异的事件应用于其他的slave、清除中继日志。
-
MHA Manager会定时探测集群中的master节点，当master出现故障时，它可以自动将最新数据的slave提升为新的master，然后将所有其他的slave重新指向新的master，整个故障转移过程对应用程序完全透明。
8.MHA故障处理机制
- 把宕机master的binlog保存下来
- 根据binlog位置点找到最新的slave
- 用最新slave的relay log修复其它slave
- 将保存下来的binlog在最新的slave上恢复
- 将最新的slave提升为master
- 将其它slave重新指向新提升的master，并开启主从复制
9.MHA优点
- 自动故障转移快
- 主库崩溃不存在数据一致性问题,现有的一致性，目前还是可以保证的
- 性能优秀，支持半同步复制和异步复制
- 一个Manager监控节点可以监控多个集群
10. 主备切换简介： 是指将备库变为主库，主库变为备库，有可靠性优先和可用性优先两种策略。
主备延迟问题：主备延迟是由主从数据同步延迟导致的，与数据同步有关的时间点主要包括以下三个- 主库 A 执行完成一个事务，写入 binlog，我们把这个时刻记为 T1;
- 之后将binlog传给备库 B，我们把备库 B 接收完 binlog 的时刻记为 T2;
- 备库 B 执行完成这个binlog复制，我们把这个时刻记为 T3。
- 所谓
主备延迟，就是同一个事务，在备库执行完成的时间和主库执行完成的时间之间的差值，也就是T3-T1。 - 在备库上执行show slave status命令，它可以返回结果信息，seconds_behind_master表示当前备库延迟了多少秒。
同步延迟主要原因如下：备库机器性能问题：机器性能差，甚至一台机器充当多个主库的备库。分工问题：备库提供了读操作，或者执行一些后台分析处理的操作，消耗大量的CPU资源。大事务操作：大事务耗费的时间比较长，导致主备复制时间长。比如一些大量数据的delete或大表DDL操作都可能会引发大事务。
11.主备切换之可靠性优先
-
主备切换过程一般由专门的HA高可用组件完成，但是切换过程中会存在短时间不可用，因为在切换过程中某一时刻主库A和从库B都处于只读状态。
-
主库由A切换到B，切换的具体流程如下：
- 判断从库B的Seconds_Behind_Master
（主备的延迟时间）值，当小于某个约定值才继续下一步 - 把主库A改为只读状态（readonly=true）
- 等待从库B的Seconds_Behind_Master值降为 0
- 把从库B改为可读写状态（readonly=false）
- 把业务请求切换至从库B
- 判断从库B的Seconds_Behind_Master
11.主备切换之可用性优先
- 不等主从同步完成， 直接把业务请求切换至从库B ，并且让从库B可读写 ，这样几乎不存在不可用时间，但可能会数据不一致。
- 如上图所示，在A切换到B过程中，执行两个INSERT操作，过程如下：
- 主库A执行完 INSERT c=4 ，得到 (4,4) ，然后开始执行 主从切换
- 主从之间有5S的同步延迟，从库B会先执行 INSERT c=5 ，得到 (4,5)
- 从库B执行主库A传过来的binlog日志 INSERT c=4 ，得到 (5,4)
- 主库A执行从库B传过来的binlog日志 INSERT c=5 ，得到 (5,5)
- 此时主库A和从库B会有两行不一致的数据
- 通过上面介绍了解到，主备切换采用可用性优先策略，由于可能会导致数据不一致，所以大多数情况下，优先选择可靠性优先策略。
- 在满足数据可靠性的前提下，MySQL的可用性依赖于同步延时的大小，同步延时越小，可用性就越高。
扫一扫
485
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
