中交路桥建设有限公司网站重庆丰都建设局网站

当前位置： 首页 > news >正文

中交路桥建设有限公司网站,重庆丰都建设局网站,想学会网站建设要会什么,上传网站怎么安装【MySQL】深入浅出主从复制数据同步原理 参考资料#xff1a; 全解MySQL之主从篇#xff1a;死磕主从复制中数据同步原理与优化 MySQL 日志#xff1a;undo log、redo log、binlog 有什么用#xff1f; 文章目录【MySQL】深入浅出主从复制数据同步原理一、主从复制架构概述…【MySQL】深入浅出主从复制数据同步原理 参考资料 全解MySQL之主从篇死磕主从复制中数据同步原理与优化 MySQL 日志undo log、redo log、binlog 有什么用 文章目录【MySQL】深入浅出主从复制数据同步原理一、主从复制架构概述二、MySQL中的主从复制技术MySQL数据同步的原理从节点拉取的数据到底是什么格式三、基于主从模型的不同架构一主一从/多从架构双主/多主架构多主一从架构主从架构小结四、主从数据一致性的解决方案改变业务逻辑更改复制方式调整数据库架构引入第三方中间件一、主从复制架构概述 不论任何技术栈但凡一提高可用、高性能、高稳定这些词汇必然会牵扯到集群、主从架构的概念如MQ、Redis、ES、MongoDB、Zookeeper…..任何技术栈中都会有而MySQL中同样不例外官方也提供了主从架构的支持通过调整多个MySQL节点的配置信息即可将一个节点的数据同步给另一个或多个节点但这种方式同步的是所有数据 主从架构中必须有一个主节点以及一个或多个从节点所有的数据都会先写入到主接着其他从节点会复制主节点上的增量数据从而保证数据的最终一致性使用主从复制方案可以进一步提升数据库的可用性和性能 ①在主节点宕机或故障的情况下从节点能自动切换成主节点的身份从而继续对外提供服务。②提供数据备份的功能当主节点的数据发生损坏时从节点中依旧保存着完整数据。③可以基于主从实现读写分离主节点负责处理写请求从节点处理读请求进一步提升性能。 但无论任何技术栈的主从架构都会存在致命硬伤同时也会存在些许问题需要解决 ①硬伤木桶效应一个主从集群中所有节点的容量受限于存储容量最低的哪台服务器。②数据一致性问题由于同步复制数据的过程是基于网络传输完成的所以存储延迟性。③脑裂问题从节点会通过心跳机制发送网络包来判断主机是否存活网络故障情况下会产生多主。 上述提到的三个问题中第一个问题只能靠加大服务器的硬件配置解决第二个问题相对来说已经有了很好的解决方案后续讲解第三个问题则是部署方式决定的如果将所有节点都部署在同一网段基本上不会出现集群脑裂问题。 上面简单了解了主从复制架构的一些基本概念后接着来聊一聊MySQL中的主从复制。 二、MySQL中的主从复制技术 MySQL数据同步的原理 MySQL是基于它自身的Bin-log日志来完成数据的异步复制因为Bin-log日志中会记录所有对数据库产生变更的语句包括DML数据变更和DDL结构变更语句数据的同步过程如下 上述即是主从同步数据的原理图但在讲解之前先来了解一下两种数据同步的方式 主节点推送当主节点出现数据变更时主动向自身注册的所有从节点推送新数据写入。从节点拉取从节点定期去询问一次主节点是否有数据更新有则拉取新数据写入。 那MySQL究竟采用的是什么方式呢其实是「从拉」的方案但对其稍微做了一些优化传统的「从拉」方案是需要从节点一直与主节点保持长连接从节点定时或持续性的对主节点做轮询查看主机的数据是否发生了变更而MySQL的数据同步原理如下 ①客户端将写入数据的需求交给主节点主节点先向自身写入数据。②数据写入完成后紧接着会再去记录一份Bin-log二进制日志。③配置主从架构后主节点上会创建一条专门监听Bin-log日志的log dump线程。④当log dump线程监听到日志发生变更时会通知从节点来拉取数据。⑤从节点会有专门的I/O线程用于等待主节点的通知当收到通知时会去请求一定范围的数据。⑥当从节点在主节点上请求到一定数据后接着会将得到的数据写入到relay-log中继日志。⑦从节点上也会有专门负责监听relay-log变更的SQL线程当日志出现变更时会开始工作。⑧中继日志出现变更后接着会从中读取日志记录然后解析日志并将数据写入到自身磁盘中。 阅读上述流程后相信大家能感受出MySQL主从复制时做的优化在主从数据同步的过程中从节点并不会无限制的询问主机这样实在太影响效率了在MySQL中引入了惰性的思想只有当主节点真正出现数据变更时才会通知从节点拉取数据 从节点拉取的数据到底是什么格式 前面从整体角度出发简单讲述了主从同步数据的过程但从节点复制的数据到底是什么格式的呢这里要根据主节点的Bin-log日志格式来决定它会有三种格式如下 Statment记录每一条会对数据库产生变更操作的SQL语句默认格式。Row记录具体出现变更的数据也会包含数据所在的分区以及所位于的数据页。MxedStatment、Row的结合版可复制的记录SQL语句不可复制的记录具体数据。 一般在搭建主从架构时最好将Bin-log日志调整为Mixed格式因为这种方式绝对不会出现数据不一致性毕竟默认的Statment格式会导致主从节点间的数据出现不一致例如 insert into zz_users values(11,blblccc,男,3333,now());当主节点插入数据时使用了sysdate()、now()….这类函数时主节点会取自身的系统时间插入数据而当从节点拉取SQL执行时则会获取从节点的系统时间插入数据因为主/从节点执行SQL语句绝对不可能发生在同一时间因此就会导致主/从节点中同一条数据的时间不一致。 有一个数据库表t1表中有如下两条记录 CREATE TABLE t1 (a int(11) DEFAULT NULL,b int(11) DEFAULT NULL,KEY a (a) ) ENGINEInnoDB DEFAULT CHARSETlatin1; insert into t1 values(10,2),(20,1);接着开始执行两个事务的写操作 以上两个事务执行之后数据库里面的记录会变成112和202这个发上在主库的数据变更大家都能理解。 假如事务的隔离级别是read committed所以事务1在更新时只会对b2这行加上行级锁不会影响到事务2对b1这行的写操作。 以上两个事务执行之后会在bin log中记录两条记录因为事务2先提交所以UPDATE t1 SET b2 where b1;会被优先记录然后再记录UPDATE t1 SET a11 where b2;再次提醒statement格式的bin log记录的是SQL语句的原文 这样bin log同步到备库之后SQL语句回放时会先执行UPDATE t1 SET b2 where b1;再执行UPDATE t1 SET a11 where b2;。 这时候数据库中的数据就会变成112和112。这就导致主库和备库的数据不一致了
而将Bin-log日志调整为Mixed格式后就不会再出现这样的问题因为对于这种不可复制的记录会直接选择记录具体变更过的数据到日志中当从节点读取数据写入时则可以直接将数据放到磁盘对应的位置中即可。 那为什么不选择Row格式来作为数据同步时的格式呢 这种方式同步数据不需要经过SQL解析过程只需直接将数据放到磁盘的具体位置即可但这种方式会让主节点的I/O负载直线拉高在传输时也会大量占用网络带宽因此一般都不会选择Row作为同步复制时的格式。 三、基于主从模型的不同架构 前面将最基本的主从复制原理和细节讲清楚了虽然MySQL官方只提供了最基本的主从复制技术的支持但这并不妨碍咱们将其玩出花来目前业内可以基于主从机制实现一主一从/多从、双主/多主、多主一从、级联复制四种架构下面详细聊一聊每种架构。 一主一从/多从架构 一主一从或一主多从这是传统的主从复制模型也就是多个主从节点组成的集群中只有一个主节点剩余的所有节点都为其附属关系大致如下 这种架构中从节点的所有数据都源自于主节点如上图所示为了充分的利用好这种架构一般都会基于它实现读写分离也就是将客户端的写请求发给主节点处理将客户端的读请求发给从节点处理。这种模式下相较于单机节点而言能够在性能上进一步提升因为读写请求都被分发到了不同的节点处理所以吞吐量至少会提升50%以上。 双主/多主架构 上述的一主一从/多从架构更加适用于一些读大于写的场景因为这类项目中读请求的数量远超出写请求因此将读操作分发到从库上能够大大降低主库的访问压力但如若你的项目中读写请求的比例对半开同时整体的并发量也不算低至少超出了单库的承载阈值这时就可以选用双主/多主架构如下 上图是一个典型的双主架构这里有两个MySQL节点它们都是主库也都属于对方的从库也就是两者之间会相互同步数据这时为了防止主键出现冲突一般都会通过设置数据库自增步长的方式来防重通常会将两个节点的自增步长设为2然后为两个节点分配自增初始值1、2最终会出现如下效果 DB11、3、5、7、9、11、13、15、17…….DB22、4、6、8、10、12、14、16、18…… 在两个库上插入数据时各自会以上述序列进行主键的递增接着两个节点会各自同步对方的数据这也就意味着双方都具备完整的数据因此无论是简单读、简单写、批量写、多表查…等任何类型的操作都可以随便分发到任意节点上处理。 多主一从架构 除开上述两种主从架构的基本玩法外面对于不同场景时也会有一些新奇玩法比如面对于一些写大于读的场景不管是一主多从、还是多主的方式似乎都无法很好的解决这个问题因此要处理这类问题时可以选用多主一从架构啥意思呢如下图 因为这种架构要解决写大于读造成的性能瓶颈所以这里会采用多主来承载客户端的写请求同时为了做好主键防重也需要设置数据库自增步长和初始值这里有三个主节点因此自增步长为三初始值分别为1、2、3最终三个主节点中的数据如下 DB11、4、7、10、13、16…..DB22、5、8、11、14、17…..DB33、6、9、12、15、18….. 而这三个主节点都会具备一个相同的从节点也就是只有一个从库它会负责同步所有主库的数据这也就意味着从库中会具备三个主库的完整数据这样做有什么好处呢通过多个主节点解决了写请求导致压力过大的问题同时从库中还有完整数据因此也不会由于拆分了主库而影响读操作。 主从架构小结 下面做个简单的小总结 一主多从架构适用于读大于写的场景采用多个从库来分担数据库系统的读压力。多主架构适用于读写参半的场景采用多个主库来承载数据库系统整体的读写压力。多主一从架构适用于写大于读的场景采用多个主库分担写压力单个从库承载读压力。 四、主从数据一致性的解决方案 到这里为止对于主从复制架构中绝大多数知识点和细节技术都已经做了全面概述最后再来重点叙说一个点则是主从节点之间的数据一致性问题。通常情况下对MySQL搭建了主从集群往往从节点不会只充当备库的角色为了充分利用已有的资源都会在主从热备的基础上采用读写分离方案将写请求分发给主库、读请求分发给从库处理。 这样的确能够充分发挥从库所在机器的性能但随之而来的还有一些问题由于从库需要处理读取数据的请求但主从节点之间的数据绝对会有一定延时那对于一些关键性的数据在主库上修改之后再去从库上读取这时就很有可能读取到的是旧数据即修改前的原数据。 但这种情况对于用户而言显然是无法接受的比如一个用户将个人信息修改后然后再次查看时发现个人信息依旧是修改之前的原数据这时用户就有可能再次修改经过反反复复多次修改后用户发现依旧未生效大多数情况下都会心里骂一句“去你*的乐色系统” 想要解决上述这种读写分离导致的数据不一致性主要有四种解决方案 业务逻辑做改变复制方式做更改数据库架构做调整引入第三方中间件 改变业务逻辑 改变业务逻辑的潜在含义是对业务做一定更改比如当用户立即修改数据后因为在从库读不到数据所以先显示一个审核状态这样能够给出用户的反馈从而避免用户再次重复操作如 上述是掘金的个人资料当用户手动更改后会先显示一个「审核中」的状态这种方式属于和数据不一致妥协的方案接受一定的数据延迟不过这种方式并不适用于一些对数据实时性要求较高的场景。 更改复制方式 在之前曾聊过MySQL四种数据同步复制的方式即全同步、异步、半同步与无损复制MySQL默认会是异步复制模式即主节点写入数据后会立即返回成功的状态给客户端这样能够确保性能达到最佳但如果对实时性要求较高可以将其改为全同步或半同步模式。 改成全同步的模式能够确保数据100%不会存在延迟但性能会因此严重下降因此半同步是个不错的选择但如果数据库仅仅是一主一从的架构那么半同步模式和全同步模式没有任何区别因为半同步是至少要求一个从库返回ACK才向客户端返回写入成功而一主一从架构中只有一个从节点~ 不过就算是半同步无损复制模式对比异步复制而言依旧会导致性能下降较为严重。 调整数据库架构 如果无法接受主从架构带来的短期数据不一致那可以升级服务器硬件并将架构恢复成单库架构所有读写操作都走单库完成这就自然不会出现数据不一致问题。但如果升级硬件配置后无法承载客户端的访问压力时可将整体架构升级到分库分表架构制定好合适的分片策略和路由键每次读写数据都根据业务不同操作不同的库。 引入第三方中间件 前面聊到的三种方案多多少少都存在一些局限性因为要么接受数据不一致、要么损失性能、要么使用更高规模的架构处理但这些方案似乎都存在令人不能接受的后患那有没有一种万全之策来解决这个问题呢答案是有的就是引入Canal中间件来监控主节点的Bin-log日志。 在之前讲主从同步数据原理时曾讲到过主节点上存在一个log dump线程会监听Bin-log日志当日志出现变更时会通知从节点来拉取数据而Canal的思想也是一样的会监控主节点的Bin-log日志当发生变更时就直接去拉取数据然后直接推送给从节点写入。 Canal在主从集群的身份就类似于一个中间商对于主节点而言它是一个从库因为Canal会去主库上拉取新增数据。而对于集群中真正的从节点而言它是一个主库因为Canal会给其他真正的从节点推送数据。但这种方式也无法做到真正的数据实时性毕竟Canal监听变更、拉取数据、推送数据都需要时间这部分的时间开销必然存在只是它会比从库去主库上拉取速度会更快一些罢了。 一般企业内部都会引入Canal来解决数据不一致问题因为它不仅仅只能解决主从延迟问题还能解决MySQL-ES、MySQL-Redis…..等多种数据不一致的场景Canal是由阿里巴巴开源的一项技术也包括在阿里内部应用也较为广泛。 当然也可以制定某些敏感数据走主库查询这样能够确保数据的实时性但容易模糊读写分离的界限不过因为不需要引入额外的技术所以在某些情况下也是个不错的方案。