为什么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。

参考网址：

https://www.cnblogs.com/cnmenglang/p/6393769.html
https://blog.csdn.net/ghost_leader/article/details/60960065

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/29802484/viewspace-2155586/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/29802484/viewspace-2155586/