mysql出现主从同步不一致的情况分析

48次阅读
没有评论

共计 1666 个字符,预计需要花费 5 分钟才能阅读完成。

本篇内容主要讲解“mysql 出现主从同步不一致的情况分析”,感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷,实用性强。下面就让丸趣 TV 小编来带大家学习“mysql 出现主从同步不一致的情况分析”吧!

1. MySQL 数据库主从同步延迟原理。

答:谈到 MySQL 数据库主从同步延迟原理,得从 mysql 的数据库主从复制原理说起,mysql 的主从复制都是单线程的操作,主库对所有 DDL 和 DML 产生 binlog,binlog 是顺序写,所以效率很高,slave 的 Slave_IO_Running 线程到主库取日志,效率很比较高,下一步,问题来了,slave 的 Slave_SQL_Running 线程将主库的 DDL 和 DML 操作在 slave 实施。DML 和 DDL 的 IO 操作是随即的,不是顺 序的,成本高很多,还可能可 slave 上的其他查询产生 lock 争用,由于 Slave_SQL_Running 也是单线程的,所以一个 DDL 卡主了,需要 执行 10 分钟,那么所有之后的 DDL 会等待这个 DDL 执行完才会继续执行,这就导致了延时。有朋友会问:“主库上那个相同的 DDL 也需要执行 10 分,为什 么 slave 会延时?”,答案是 master 可以并发,Slave_SQL_Running 线程却不可以。

2. MySQL 数据库主从同步延迟是怎么产生的。

答:当主库的 TPS 并发较高时,产生的 DDL 数量超过 slave 一个 sql 线程所能承受的范围,那么延时就产生了,当然还有就是可能与 slave 的大型 query 语句产生了锁等待。

3. MySQL 数据库主从同步延迟解决方案

答:最简单的减少 slave 同步延时的方案就是在架构上做优化,尽量让主库的 DDL 快速执行。还有就是主库是写,对数据安全性较高,比如 sync_binlog=1,innodb_flush_log_at_trx_commit = 1 之类的设置,而 slave 则不需要这么高的数据安全,完全可以讲 sync_binlog 设置为 0 或者关闭 binlog,innodb_flushlog 也 可以设置为 0 来提高 sql 的执行效率。另外就是使用比主库更好的硬件设备作为 slave。

mysql-5.6.3 已经支持了多线程的主从复制。

GTID 的概念

      普通的复制过程中,从库通过记录主库的 binlog 文件名和偏移量来记录和接收主库 binlog 的事件工作进展。下次开始复制的时候告知主库这些信息,让主库可以从正确的位置开始发送 binlog 的事件给从库。但基于 GTID 的复制就不再需要告知这些事情,在执行  CHANGE  MASTER  TO 命令,也不需要指定 MASTER_LOG_FILE 和 MASTER_LOG_POS 参数。只需要指定 MASTER_AUTO_POSTION = 1 就可以了,主库会根据从库发送过来的一个 GTID 集合信息来决定从哪里开始发送 binlog 事件。大大简化了数据库管理员在复制中的工作。

    GTID 是在数据库提交事务时创建的唯一的标示符。该标示符与事务是一一相关的。

    GTID 有两部分组成,如下所示:

    GTID = source_id:transaction_id 

    source_id 用于标识这个事务是在哪个数据库实例上执行的。用的是 uuid 作为 source_id。

    transaction_id 是一个序列号,取决于该事务在数据库上的提交顺序。该序列号初始为 1.

在 MySQL5.6 以前的版本,同步复制都是单线程的,只能一个一个执行。在 5.6 做到了多个库多线程复制。

但是需要注意的是。一个库只能由一个线程去复制。也就是说若复制的库只有 1 个,那么线程也只有一个。复制的库有 2 个。那么线程可以增加到两个。

GTID 的作用,具体归纳下来有以下两点:

   1. 根据 GTID 来确认事务最初的是在哪个实例上提交的

   2.GTID 的存在方便了 Replication 和 failover。

到此,相信大家对“mysql 出现主从同步不一致的情况分析”有了更深的了解,不妨来实际操作一番吧!这里是丸趣 TV 网站,更多相关内容可以进入相关频道进行查询,关注我们,继续学习!

正文完
 
丸趣
版权声明:本站原创文章,由 丸趣 2023-07-24发表,共计1666字。
转载说明:除特殊说明外本站除技术相关以外文章皆由网络搜集发布,转载请注明出处。
评论(没有评论)