标签：主库 binlog 笔记 主备 MySQL 从库 主从

主从同步

主从同步的过程如下图所示，核心就是，当从库连接上主库之后，主库为为这个从库创建一个dump线程，用于传输binlog。从库有一个IO线程来接收binlog并写入它的中转日志relay log,同时有一个SQL线程读取relay log进行执行。主从同步保证的是数据的最终一致性。主从同步的方式包括：

• 异步复制，主库事务完成就立刻返回客户端，不关心是否复制到从库上 （默认采取异步复制）
• 同步复制，主库事务完成后要等待所有从库都复制了这个事务，才返回成功给客户端
• 半同步复制，主库事务完成后，至少一个从库接收并写到relay log才返回成功给客户端

主从同步什么时候pull,什么时候push?答案是都有。当slave连上master,会告知master它目前的binlog fileName和同步位点pos, master收到后，会找到该文件并把剩下的binlog发给slave，这其实就是pull。当连接进行时，master侧有新的binlog产生时，主线程会广播dump thread有新binlog产生，然后再发给slave，也就是push。

主备延迟

主备延迟的定义：同一个事务，在主库执行完成到从库执行完成的这个时间差。根据主从同步的过程，我们可以把过程切割成3个时间点：

• 主库写入binlog的时间点t1
• 从库接收到binlog的时间点t2
• 从库写入数据更新的时间点t3

t1其实就是事务完成的时间（算主备延迟的起始时间点）;t2-t1主要就是网络开销，正常情况下是很小的。所以主备延迟主要是来自于t3-t2即从库执行relay log的时间/消费中转日志的时间。

导致t3-t2时间较大的原因，有以下几点：

• 从库的规格/机器性能比主库差
• 从库的压力比较大。例如，放了很多运营查询/分析的语句到从库执行。这种情况解决的办法有：一主多从，或者将binlog输出到外部系统如hadoop，来提供统计查询等能力，核心就是分担从库压力
• 大事务。假设一个事务在主库执行5分钟，那么在从库也会延迟5分钟。

主备一致

那么在主从同步的过程会不会出现主备数据不一致的问题呢？其实是有可能的。在日志模块，我们提到，binlog_format其实根本上有两种，一种是statement（SQL语句本身）,一种是row(影响修改的行信息和事件)。

例如日志模块提到的这个栗子

标签：主库,binlog,笔记,主备,MySQL,从库,主从
来源： https://www.cnblogs.com/rachel-aoao/p/master_slave.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。