如何办理主从数据库同步延迟问题？

何办理主从数据库同步延迟问题？
媒介
最近，系统上频仍出现主从延迟的问题，因此针对主从架构、主从同步以及主从延迟问题进行了一次学习。
主从架构浅析
在了解主从延迟之前，我们有必要对主从架构有一些简单的认识。在如今的互联网架构中，单点数据库架构往往不能满意一样寻常的访问请求。为了增大系统的吞吐量、实现高可用架构，系统数据库往往会采用集群搭建。而集群架构中，最常见的就是主从架构。
常见主从架构介绍
主从架构作为最常见的集群搭建模式，通过将读写分离，来避免全部的请求都请求到同一个数据库上，从而减少单个数据库的压力。其次，通过对从库进行水平的扩展，也会使得系统的伸缩性及负载能力得到提升。常见的主从架构重要有以下几种：

• 一主一从式
  
• 一主一从为最常见的主从架构模式，由一个主节点+一个从节点组合而成，当主节点宕机时，从节点可以快速接替主节点的工作。
  
• 
  
  
• 一主多从式
  
• 该架构有一个主节点+多个从节点组成，适合读较多的场景，可以将读命令分摊到多个从节点
  
• 
  
  
• 多主一从
  
• 在一些必要汇总数据进行分析，或写入压力较大的情况，会采用多主一从的架构模式。该架构由多个主节点+一个从节点组成。
  
• 
  
  
• 主主互 备式
  
• 主主互备的架构模式，重要由两个或多个的主节点构成，每个主节点的更新操作都必要向别的的主节点进行同步。长处是读写的压力均可以通过负载平衡进行分摊，提升系统的吞吐量，且其中一个节点宕机，也不会影响整个系统，实现高可用。
  
• 
  
  主从同步
  聊完了常见的主从架构，那么这些架构，都是如何实现的主从数据库数据的同步的呢？以下就以mysql数据库为例子进行学习、了解。在mysql中，实现主从同步有两个比较重要的日记文件：binLog和relayLog。
  binlog
  binlog，又称为二进制日记文件。扼要来说，binLog重要记载当前数据库发生了什么。其重要日记格式有三种：statement、row 和 mixed，
  statement：statement又被称为基于SQL语句的复制。在该格式下，binlog内会记载执行的SQL原文。但在一些非常的情况下，可能会因为主从数据库的配置、索引等，同一句SQL可能执行出来的效果是不一致的。
  row：row又被称为基于行的复制，故名思义，row模式下记载的不是SQL的原文，而是记载的SQL语句影响的数据。比方哪一行数据被删除了、哪一行数据从a更新成了b等等。这样可以避免因为执行SQL的环境差别导致的数据不一致，但是缺陷就是会产生大量的日记文件。
  mixed：从5.1.8版本开始，MySQL提供了Mixed格式，现实上就是statement与row的结合。在该模式下，一般的语句修改利用statement保存binlog，但是一些函数statement无法完成主从复制，那么此时就会利用row格式进行保存。
  详细的，我们可以利用语句show binary logs来查看当前数据库的binlog。
  
• relayLog
  
• relayLog，又被称为中继日记。简单来说，relayLog中重要保存了从主节点中查询出来的binlog数据，供从节点在同步的过程中利用。
  

在了解了binLog及relayLog之后，我们就可以开始了解mysql是如何进行数据同步的了。如图所示，mysql的同步过程重要有以下几个步调：
主节点产生数据变更，此时会将变更内容写入binLog，同时会开启binlog dump线程将更新的数据信息同步给从库。
从节点的I/O线程读取到变更的数据后，会将数据写入relayLog。
从节点的SQL线程检测到relayLog中添加了数据后，会将新增的数据写入到从库中，从而实现主从数据的同步
主从延迟
了解了主从同步的原理，我们就来了解下什么是主从延迟。主从延迟简单来说，是因为在肯定时间内，主节点此时已经完成了数据的写入，但是此时从库还没有将主库的数据同步更新完成。
结合上述的主从同步原理，不难推断造成主从延迟重要是源于以下几个方面之一：
binLog数据未及时同步主节点
从节点I/O线程未及时将数据写入RelayLog
从节点SQL线程未及时将RelayLog写入数据库
针对这三个方面，我们逐一分析可能导致主从延迟的缘故原由。
主从延迟的缘故原由
主节点binLog数据未及时同步
针对主库binLog数据没及时同步造成主从延迟的情况，可能性重要有如下几个：
主库存在高并发，某一时刻，大量的写请求到主库上，意味着binLog必要进行频仍的写入及同步，此时就可能导致主节点binlog dump线程、从节点I/O线程没法及时同步，从而造成主从延迟。
网络IO存在问题，某一时刻假如网络IO挂掉了，数据没法发送到从库，那么此时也会导致从库的数据无法更新，造成主从延迟。
主节点 log dump 线程

当从节点毗连主节点时，主节点会为其创建一个 bin log dump 线程，用于发送和读取 Binlog 的内容。在读取 Binlog 中的操作时，bin log dump 线程会对主节点上的 Binlog 加锁；当读取完成发送给从节点之前，锁会被释放。 主节点会为本身的每一个从节点创建一个 log dump 线程 。
从节点I/O线程

当从节点上执行 start slave 命令之后，从节点会创建一个 I/O 线程用来毗连主节点，请求主库中更新的Binlog。I/O 线程接收到主节点的 log dump 进程发来的更新之后，保存在本地 relay-log（中继日记）中。
relay log

这里又引申出一个新的日记概念。MySQL 进行主主复制或主从复制的时间会在要复制的服务器下面产生相应的 relay log。
relay log 是怎么产生的呢？
从服务器 I/O 线程将主服务器的 Binlog 日记读取过来，解析到各类 Events 之后记载到从服务器本地文件，这个文件就被称为 relay log。然后 SQL 线程会读取 relay log 日记的内容并应用到从服务器，从而使从服务器和主服务器的数据保持一致。中继日记充当缓冲区，这样 master 就不必等候 slave 执行完成才发送下一个变乱。
执行大事务，一旦执行大事务，主库必须比及事务执行完成之后才气写入binLog，进而也会影响后续的binLog的同步及写入，造成主从延迟。
I/O线程未及时写RelayLog

• 针对从节点I/O线程未及时写入RelayLog情况，其重要的可能性是
  
• 存在高并发，I/O线程未能及时将数据刷入到relayLog中。但I/O线程通常为磁盘读写，服从较快，一般不会成为重要的问题。
  
• 机器性能较差，导致relayLog同步速度较慢。
  
• SQL线程未及时写数据库
  针对这最后一种情况，产生主从延迟的缘故原由可能更多一些：
  relayLog随机重放。在主库中写binlog及从库中写relayLog都是次序进行的磁盘读写，服从较高。但是SQL数据对relayLog进行数据重放的时间是随机写盘的，执行服从相对较慢，从而出现主从延迟。
  锁等候，从库除了同步以外还会必要支持正常的业务查询操作，而假如当前必要修改的数据被访问了，那么此时SQL线程就会先辈行等候，直到锁被释放以后，再获取锁进行修改。而这一段时间，就有可能导致主从延迟。
  高并发，高并发情况下产生的DML数量超过了SQL Thread所能处置处罚的速度时，那么此时就会产生主从延迟。
  出现慢SQL，慢SQL会导致relayLog较久才气写入到数据库中，进而造成主从延迟。
  

如何办理主从延迟

• 了解了出现主从延迟的缘故原由，那么如何对主从延迟进行办理呢？可行的方案我这里简单总结了三个：
  

• 强一致性方案
  
• 最简单粗暴的方案，其实就是针对一些实时性要求比较高的操作，通过代码指定的方式，强行让查询语句走主库进行查询。这样可以保证数据的绝对准确，带来的问题是会加大主库的并发数量，增加宕机的风险。
  
• 并行复制
  这种方案重要针对高并发情况下从库SQL单线程出现瓶颈的时间利用，将SQL线程转化成多个线程来进行重放，加速对DML数据的处置处罚速度，从而减缓主从延迟。mySql自5.7版本后就已经支持并行复制了。可以在从服务上设置 slave_parallel_workers为一个大于0的数，然后把slave_parallel_type参数设置为LOGICAL_CLOCK即可。
  
• 支持一个 schema(库) 下， slave_parallel_workers 个 worker 线程并发执行 relay log 中主库提交的事务。
  降低并发
  
• 针对过高的并发，其实会导致同步过程的三个阶段都会出现问题，为此，在接口设计时，要充实考虑接口的请求量，并适当采用如令牌桶、漏桶算法等进行限流。或采用分布式锁等对关键数据进行加锁，控制并发量，减少主从延迟对业务的影响
  
• 增加NOSQL层
  
• 通过在从库前增加NOSQL层来缓解，主库写入SQL的时间，按照肯定计谋将关键数据放入到缓存中，查询时优先查询缓存中的数据。可以在肯定程度上减少主从延迟所带来的问题。
  
• 归根结底来说，在主从架构下，主从延迟其实是不可避免的（只是延迟的时间长短）。但是通对主从延迟缘故原由的合理分析以及的合适方案选择，可以最大程度上缩短主从同步时间，最大程度减少主从延迟给系统、服务带来的影响的。
  
• 半同步模式(semi-sync)
  
  介于异步复制和全同步复制之间，主库在执行完客户端提交的事务后不是立即返回给客户端，而是等候至少一个从库接收到并写到 relay log 中才返回成功信息给客户端（只能保证主库的 Binlog 至少传输到了一个从节点上），否则必要等候直到超时时间然后切换成异步模式再提交。
  
• 全同步模式
  
  指当主库执行完一个事务，然后全部的从库都复制了该事务并成功执行完才返回成功信息给客户端。因为必要等候全部从库执行完该事务才气返回成功信息，所以全同步复制的性能肯定会收到严肃的影响。
  
• 
  
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。