mysql主从数据一致性问题及MHA和MGR的架构及底层原理

MySQL的传统主从复制机制
MySQL传统的高可用解决方案是通过binlog复制来搭建主从或一主多从的数据库集群。主从之间的复制模式支持异步模式(async replication)和半同步模式(semi-sync replication)。无论哪种模式下，都是主库master提供读写事务的能力，而slave只能提供只读事务的能力。在master上执行的更新事务通过binlog复制的方式传送给slave，slave收到后将事务先写入relay log，然后重放事务，即在slave上重新执行一次事务，从而达到主从机事务一致的效果。
异步复制(Async replication)：在master将事务写入binlog后，将新写入的binlog事务日志传送给slave节点，但并不等待传送的结果，就会在存储引擎中提交事务。
数据丢失的原因：当master将事务写入binlog，然后复制给slave后并不等待slave返回结果即进行提交，若slave因网络延迟或其它问题尚未收到binlog日志，而此时master故障，应用切换到slave时，本来在master上已经提交的事务就会丢失，因其尚未传送到slave，从而导致主从之间事务不一致。

半同步复制(Semi-sync replication)：在master将事务写入binlog后，将新写入的binlog事务日志传送给slave节点，但需要等待slave返回传送的结果；slave收到binlog事务后，将其写入relay log中，然后向master返回传送成功ACK；master收到ACK后，再在存储引擎中提交事务。 MySQL基于两种复制模式都可以搭建高可用数据库集群，也能满足大部分高可用系统的要求，但在对事务一致性要求很高的系统中，还是存在一些不足，主要的不足就是主从之间的事务不能保证时刻完全一致。

数据丢失的原因：当master将事务写入binlog，尚未传送给slave时master故障，此时应用切换到slave，虽然此时slave的事务与master故障前是一致的，但当主机恢复后，因最后的事务已经写入到binlog，所以在master上会恢复成已提交状态，从而导致主从之间的事务不一致。

MHA工作组件
MHA(Master High Availability)是一种MySQL高可用解决方案，主要用于在故障切换和主从提升时进行快速切换，并最大程度保证数据一致性。
MHA主要由两部分组成：
1、MHA Manager(管理节点)，可以单独部署在一台独立的机器上管理多个master-slave集群，也可以部署在一台slave节点上。
MHA Manager会定时探测集群中的node节点，当发现master出现故障的时候，它可以自动将具有最新数据的slave提升为新的master，然后将所有其它的slave导向新的master上，整个故障转移过程对应用程序是透明的。
2、MHA Node(数据节点)，数据节点部署在每个集群节点上，负责在主从切换时对比和应用差异日志。
MHA主要特性
MHA切换不依赖实例使用存储引擎和BINLOG格式；
MHA不会增加MySQL服务器性能开销，除MHA管理节点外无需增加额外服务器；
在MySQL服务器上部署MHA数据节点不会影响当前实例运行；
MHA实现自动故障切换，也可以手动触发在线切换；
MHA可以实现秒级的故障切换；
MHA可以将任意slave提升master，也可以在切换时指定master候选节点；
MHA提供扩展接口，允许在MHA切换过程中的特定时间点执行用户自定义脚本。

MHA可扩展性：
A)seconary_check_script
当检测到master节点连接失败时调用，从多个网络路径判断master是否发生宕机。
B)shutdown_script
在故障转移前调用，可以通过SSH登录到master节点进行数据库关闭和服务器关机等操作。
C)master_ip_failover_script
在故障转移前和转移到新master节点后调用，用于切换群集使用的VIP或域名或其他操作。
D)report_script
在故障切换完成后被调用，用于通知故障切换的执行结果。

MHA支持与限制
1、只支持BINLOG V4版本，要求MySQL 5.0或更高版本。
2、候选master节点必须开启log-bin参数，如果所有从节点都为开启，则不进行故障转移。
3、在MHA 0.52版本前不支持多master模式
4、MHA默认不支持多级主从复制，通过修改配置文件和设置multi_tier_slave参数
（参考文章：https://www.cnblogs.com/gaogao67/p/11105996.html）

在MHA自动故障切换过程中，MHA试图从宕机的主服务器上保存二进制日志，最大程度的保证数据的不丢失，但这并不总是可行的。
例如，如果主服务器硬件故障或无法通过ssh访问，MHA没法保存二进制日志，只进行故障转移而丢失了最新的数据。

如果master宕机，如何保证主从库的一致？
使用MySQL 5.5或者以后的版本的半同步复制，可以大大降低数据丢失的风险。MHA可以与半同步复制结合起来。
如果只有一个slave已经收到了最新的二进制日志，MHA可以将最新的二进制日志应用于其他所有的slave服务器上，因此可以保证所有节点的数据一致性。

具体的工作原理如下:
相较于其它HA软件，MHA的目的在于维持MySQL Replication中Master库的高可用性，其最大特点是可以修复多个Slave之间的差异日志，最终使所有Slave保持数据一致，然后从中选择一个充当新的Master，并将其它Slave指向它。
MHA插件负责监控mysql主节点的健康情况。在主节点宕机后，MHA把binlog通过ssh传到从节点进行重做补齐。并提升其中一个从节点为主节点。如：A>B ,A>C 。A宕机后。B，C补齐日志。并将故障转移后的架构变为B>C。
工作流程主要如下：
1、从出现故障的主节点A拉取binlog日志到B、C节点。
2、识别有最近Relay_Master_Log_File,Exec_Master_Log_Pos 更新的slave节点。假设是B
3、应用差异的中继日志（relay log）到其他slave节点。如C
4、提升slave （B）为新的主节点。
5、其他的节点（C）连接到新的主节点。
MHA 切换完了之后并没有其他的操作了。如服务发现，重新注册。但是MHA提供了脚本接口。可以手动指定切换完了MHA执行指定的脚本。如注册虚拟ip到新的主节点。或者调用接口注册新的服务域名。发告警邮件等。

mha的架构如下：

当master出现故障时，通过对比slave之间I/O线程读取master binlog的位置，选取最接近的slave做为latest slave。其它slave通过与latest slave对比生成差异中继日志。
在latest slave上应用从master保存的binlog，同时将latest slave提升为master。最后在其它slave上应用相应的差异中继日志并开始从新的master开始复制。
在MHA实现Master故障切换过程中，MHA Node会试图访问故障的master（通过SSH），如果可以访问（不是硬件故障，比如InnoDB数据文件损坏等），会保存二进制文件，以最大程度保证数据不丢失。
MHA和半同步复制一起使用会大大降低数据丢失的危险。

优势
1）故障切换快
在主从复制集群中，只要从库在复制上没有延迟，MHA通常可以在数秒内实现故障切换。9-10秒内检查到master故障，可以选择在7-10秒关闭master以避免出现裂脑，几秒钟内，将差异中继日志（relay log）应用到新的master上，因此总的宕机时间通常为10-30秒。恢复新的master后，MHA并行的恢复其余的slave。即使在有数万台slave，也不会影响master的恢复时间。
DeNA在超过150个MySQL（主要5.0/5.1版本）主从环境下使用了MHA。当mater故障后，MHA在4秒内就完成了故障切换。在传统的主动/被动集群解决方案中，4秒内完成故障切换是不可能的。
2）master故障不会导致数据不一致
当目前的master出现故障时，MHA自动识别slave之间中继日志（relay log）的不同，并应用到所有的slave中。这样所有的salve能够保持同步，只要所有的slave处于存活状态。和半同步复制一起使用，（几乎）可以保证没有数据丢失。
3）无需修改当前的MySQL设置
MHA并不需要改变MySQL的部署环境，MHA适用于异步和半同步的主从复制。
启动/停止/升级/降级/安装/卸载MHA不需要改变（包扩启动/停止）MySQL复制。当需要升级MHA到新的版本，不需要停止MySQL，仅仅替换到新版本的MHA，然后重启MHA　Manager就好了。
4）无需增加大量的服务器
MHA由MHA Manager和MHA Node组成。MHA Node运行在需要故障切换/恢复的MySQL服务器上，因此并不需要额外增加服务器。MHA Manager运行在特定的服务器上，因此需要增加一台（实现高可用需要2台），但是MHA Manager可以监控大量（甚至上百台）单独的master，因此，并不需要增加大量的服务器。即使在一台slave上运行MHA Manager也是可以的。
5）无性能下降
MHA适用与异步或半同步的MySQL复制。监控master时，MHA仅仅是每隔几秒（默认是3秒）发送一个ping包，并不发送重查询。可以得到像原生MySQL复制一样快的性能。
6）适用于任何存储引擎
MHA可以运行在只要MySQL复制运行的存储引擎上，并不仅限制于InnoDB，即使在不易迁移的传统的MyISAM引擎环境，一样可以使用MHA。

MHA如何保持数据的一致性呢？
主要通过MHA node的以下几个工具实现，但是这些工具由MHA manager触发：
save_binary_logs ：如果master的二进制日志可以存取的话，保存复制master的二进制日志，最大程度保证数据不丢失。
apply_diff_relay_logs：相对于最新的slave，生成差异的中继日志并将所有差异事件应用到其他所有的slave。

对比的是relay log，relay log越新就越接近于master，才能保证数据是最新的。
purge_relay_logs：删除中继日志而不阻塞sql线程

MGR架构原理简介：（全称：MySQL Group Replication），Mysql组复制
1.状态机复制
MGR本质上一个状态机复制的集群。在状态机复制的架构中，数据库被当做一个状态机。每一次写操作都会导致数据库的状态变化。为了创建一个高可用的数据库集群，有一个组件，即事务分发器，将这些操作按照同样的顺序发送到多个初始状态一致的数据库上，让这些数据库执行同样的操作。因为初始状态相同，每次执行的操作也相同，所以每次状态变化后各个数据库上的数据保持一致。
2.分布式的状态机复制
事务分发器是一个单点，为了避免单点故障，可以采用分布式的状态机复制。在分布式的状态机复制中，有多个事务分发器，它们彼此互相通信。事务分发器可以同时接收事务请求，就像单个事务分发器同时接收事务请求一样。从应用层来说，并发的事务发到同一个事务分发器和发到不同的事务分发器上效果是一样的。事务分发器之间会互相通信，把所有的事务汇总、排序。最终，每个事务分发器上都有一份完整的排好序的事务请求。每个事务分发器只连接到一个数据库上，并负责把事务请求依次发送到相连的数据库上去执行，其就是一个分布式状态机复制的模型了。
3.分布式的高可用数据库
将分布式的事务分发模块集成到数据库系统中，就变成了一个分布式的高可用数据库系统。用户通过数据库的用户接口执行事务。数据库收到事务请求后，首先交由事务分发模块处理。事务分发模块将事务汇总排序，然后依次交由数据处理模块去执行这些事务。
用户——>请求数据库用户接口——>数据库——>事务分发器——>将事务汇总排序——>执行

Group Replication的实现原理
Group Replication由至少3个或更多个节点共同组成一个数据库集群，事务的提交必须经过半数以上节点同意方可提交，在集群中每个节点上都维护一个数据库状态机，保证节点间事务的一致性。Group Replication基于分布式一致性算法Paxos实现，允许部分节点故障，只要保证半数以上节点存活，就不影响对外提供数据库服务，是一个真正可用的高可用数据库集群技术。 Group Replication支持两种模式，单主模式和多主模式。在同一个group内，不允许两种模式同时存在，并且若要切换到不同模式，必须修改配置后重新启动集群。在单主模式下，只有一个节点可以对外提供读写事务的服务，而其它所有节点只能提供只读事务的服务。
MySQL Group Replication是建立在已有MySQL复制框架的基础之上，通过新增Group Replication Protocol协议及Paxos协议的实现，形成的整体高可用解决方案。与原有复制方式相比，主要增加了certify的概念，如下图所示：

certify模块主要负责检查事务是否允许提交，是否与其它事务存在冲突，如两个事务可能修改同一行数据。在单机系统中，两个事务的冲突可以通过封锁来避免，但在多主模式下，不同节点间没有分布式锁，所以无法使用封锁来避免。为提高性能，Group Replication乐观地来对待不同事务间的冲突，乐观的认为多数事务在执行时是没有并发冲突的。事务分别在不同节点上执行，直到准备提交时才去判断事务之间是否存在冲突。

核心组件XCOM的特性
MySQL Group Replication是建立在基于Paxos的XCom之上的，正因为有了XCom基础设施，保证数据库状态机在节点间的事务一致性，才能在理论和实践中保证数据库系统在不同节点间的事务一致性。 Group Replication在通讯层曾经历过一次比较大的变动，早期通讯层采用是的Corosync，而后来才改为XCom。

xcom特性：
闭环(closed group)：只有组内成员才能给组成员发送消息，不接受组外成员的消息。
消息全局有序(total order)：所有XCOM传递的消息是全局有序(在多主集群中或是偏序)，这是构建MySQL 一致性状态机的基础。
消息的安全送达(Safe Delivery)：发送的消息必须传送给所有非故障节点，必须在多数节点确认收到后方可通知上层应用。
视图同步(View Synchrony)：在成员视图变化之前，每个节点都以相同的顺序传递消息，这保证在节点恢复时有一个同步点。实际上，组复制并不强制要求消息传递必须在同一个节点视图中。
（参考文章：https://blog.csdn.net/weixin_32175667/article/details/113330358）

MGR 适用的场景包括：
弹性复制：复制架构下，服务器的数量动态增加或缩减时，使影响降到最低。
分片的高可用：用户可以利用MGR实现单一分片的高可用，每个分片都具有一个复制组。
主从复制的替代选择：可以使用单主模式避免发生冲突检测，以替代传统的主从复制。

MGR使用上的限制
尽量使用单主模式，表必须有主键，必须启用GTID，必须使用InnoDB引擎，在多主模式下DML和DDL对同一个表的操作，必须在同一个节点进行，否则会导致集群会crash。使用奇数个节点:3,5,7,9 最多9个成员。
网络稳定，延迟低，尽量避免WAN部署；禁止使用外键；不支持GAP LOCK ，MGR工作在RC模式；不支持serializable事务模式；MGR成员间不支持复制过滤规则。
BINLOG_FORMAT=ROW。
在多主模式使用select for update可能会导致整个集群死锁。
如果配合mysqlshell使用MySQL版本需要8.0.20及以上。

从MySQL 5.6.5 开始新增了一种基于 GTID 的复制方式。通过 GTID 保证了每个在主库上提交的事务在集群中有一个唯一的ID。这种方式强化了数据库的主备一致性，故障恢复以及容错能力。GTID (Global Transaction ID)是全局事务ID,当在主库上提交事务或者被从库应用时，可以定位和追踪每一个事务。
从架构设计的角度，GTID是一种很好的分布式ID实践方式，通常来说，分布式ID有两个基本要求：
1）全局唯一性
2）趋势递增
这个ID因为是全局唯一，所以在分布式环境中很容易识别，因为趋势递增，所以ID是具有相应的趋势规律，在必要的时候方便进行顺序提取，行业内适用较多的是基于Twitter的ID生成算法snowflake,所以换一个角度来理解GTID，其实是一种优雅的分布式设计。

分布式ID使用背景：
业务数据量不大的时候，单库单表完全可以支撑现有业务，数据再大一点搞个MySQL主从同步读写分离也能对付。
但随着数据日渐增长，主从同步也扛不住了，就需要对数据库进行分库分表，但分库分表后需要有一个唯一ID来标识一条数据，数据库的自增ID显然不能满足需求；特别一点的如订单、优惠券也都需要有唯一ID做标识。此时一个能够生成全局唯一ID的系统是非常必要的。那么这个全局唯一ID就叫分布式ID。

项目中一个表中的数据主键id都是自增的，解决分布式id的方案有哪些？
1、数据库自增ID
可以在某个库中专门维护一张表，然后每次无论哪个表需要自增id的时候都去查这个表的记录，然后用for update锁表，然后取到的值加一，然后返回以后把再把值记录到表中，但是这个方法适合并发量比较小的项目，因此每次都得锁表。
优点：实现简单，ID单调自增，数值类型查询速度快
缺点：DB单点存在宕机风险，无法扛住高并发场景
2、基于数据库集群模式
单点数据库方式不可取，换成主从模式集群。害怕一个主节点挂掉没法用，那就做双主模式集群，也就是两个Mysql实例都能单独的生产自增ID。两个MySQL实例的自增ID都从1开始，会生成重复的ID怎么办？设置起始值和自增步长
优点：解决数据库单点问题
缺点：不利于后续扩容，而且实际上单个数据库自身压力还是大，依旧无法满足高并发场景。
3、基于数据库的号段模式
号段模式是当下分布式ID生成器的主流实现方式之一，号段模式可以理解为**从数据库批量的获取自增ID，每次从数据库取出一个号段范围，**例如 (1,1000] 代表1000个ID，具体的业务服务将本号段，生成1~1000的自增ID并加载到内存。等这批号段ID用完，再次向数据库申请新号段，由于多业务端可能同时操作，所以采用版本号version乐观锁方式更新，这种分布式ID生成方式不强依赖于数据库，不会频繁的访问数据库，对数据库的压力小很多。
4、redis
因为redis是单线程的，可以在redis中维护一个键值对，然后哪个表需要直接去redis中取值然后加一，但是这个跟上面一样由于单线程都是对高并发的支持不高，只适合并发量小的项目。
用redis实现需要注意一点，要考虑到redis持久化的问题。redis有两种持久化方式RDB和AOF。RDB会定时打一个快照进行持久化，假如连续自增但redis没及时持久化，而这会Redis挂掉了，重启Redis后会出现ID重复的情况。AOF会对每条写命令进行持久化，即使Redis挂掉了也不会出现ID重复的情况，但由于incr命令的特殊性，会导致Redis重启恢复的数据时间过长。
5、uuid
可以使用uuid作为不重复主键id，但是uuid有个问题就是其是无序的字符串，如果使用uuid当做主键，那么主键索引就会失效。
优点：生成足够简单，本地生成无网络消耗，具有唯一性
缺点：
无序的字符串，不具备趋势自增特性；没有具体的业务含义；存储以及查询对MySQL的性能消耗较大，作为数据库主键 UUID 的无序性会导致数据位置频繁变动，严重影响性能。
6、雪花算法
雪花算法是解决分布式id的一个高效的方案，大部分互联网公司都在使用雪花算法，当然还有公司自己实现其他的方案，比如百度（uid-generator）、美团（Leaf）、滴滴（Tinyid）
雪花算法的原理：
雪花算法就是使用64位long类型的数据存储id，最高位一位存储0或者1,0代表整数，1代表负数，一般都是0，所以最高位不变，41位存储毫秒级时间戳，10位存储机器码（包括5位datacenterId和5位workerId），12存储序列号。这样最大2的10次方的机器，也就是1024台机器，最多每毫秒每台机器产生2的12次方也就是4096个id。

mysql主从数据一致性问题及MHA和MGR的架构及底层原理相关推荐

MySQL主从、主主、半同步节点架构的的原理及实验总结
一.原理及概念: MySQL 主从复制概念 MySQL 主从复制是指数据可以从一个MySQL数据库服务器主节点复制到一个或多个从节点.MySQL 默认采用异步复制方式,这样从节点不用一直访问主服务器来 ...
利用mk-table-checksum监测Mysql主从数据一致性操作记录
前面已经提到了mysql主从环境下数据一致性检查:mysql主从同步(3)-percona-toolkit工具(数据一致性监测.延迟监控)使用梳理今天这里再介绍另一种Mysql数据一致性自动检测工具 ...
检查MySQL主从数据一致性
未公布转载于:https://www.cnblogs.com/cuizhipeng/p/4646489.html
【MySQL】InnoDB行格式、数据页结构以及索引底层原理分析
目录一.MySQL架构图二.InnoDB数据页结构 2.1 局部性原理 2.2 InnoDB的数据页格式三.InnoDB的行格式 3.1 Compact行格式 3.1.1 变长字段长度列表 3. ...
MySQL 主从同步percona-toolkit工具（数据一致性监测、延迟监控）使用梳理
在mysql工作中接触最多的就是mysql replication,mysql在复制方面还是会有一些常规问题,比如主库宕机或者从库宕机有可能会导致复制中断,通常需要进行人为修复,或者很多时候需要把一个 ...
mysql主从同步(3)-percona-toolkit工具（数据一致性监测、延迟监控）使用梳理
在mysql工作中接触最多的就是mysql replication,mysql在复制方面还是会有一些常规问题,比如主库宕机或者从库宕机有可能会导致复制中断,通常需要进行人为修复,或者很多时候需要把一个 ...
MySQL主从不一致问题处理
一.背景某业务采取mysql的主从架构,但因为存储的问题,导致备库一直无法存储,数据同步一致性问题一直也未恢复,某次安全检查要求完成主备倒换演练,必须限期恢复主备,但是在恢复过程中,同步显示 ...
keepalived+MHA实现mysql主从高可用集群
本节索引原理分析实验环境准备主从复制集群安装MHA包初始化MHA 配置Keepalived 故障出现故障恢复总结一原理分析 1 MHA简介: MHA(Master High Avai ...
数据库周刊62丨央企2021年数据库成交公告，国产占90%；流数据库HStreamDB开源；MySQL主从双写导致数据丢失；Oracle 19c升级最佳实践；PG日常工作分享；MySQL MGR运维指
热门资讯 [1.中央国家机关2021年数据库成交公告:国产数据库份额占90% [摘要]据央采网3月19日发布的<中央国家机关2021年数据库软件协议供货采购项目成交公告>显示事务型数据库管 ...

mysql主从数据一致性问题及MHA和MGR的架构及底层原理

mysql主从数据一致性问题及MHA和MGR的架构及底层原理相关推荐

最新文章

热门文章