主从同步原理见附件图


replication，基于binary log，以事件方式，记录主库变更，实现主库变更在从库的回放。

  1. 主库操作包括DML,DDI,DCL

  2. 从库获得授权后，从库的io线程链接到主库的binlogdump线程，从主库读取二进制日志，记录到从库的relay log中。

  3. 从库的sql线程执行relay log中的sql语句，一一执行到从库中。


    （同步到从库可能是串行完成的）


    主从同步条件

  1. 开启二进制日志

  2. 主从库设置全局唯一server id

  3. 配置同步账号

  4. 基准数据及同步点


2.常见的主从延迟原因

2.1 DDL语句造成延迟

以修改表结构为例，alter table会对加LOCK_open全局锁。进行sql查询时，也会首先加LOCK_open锁，已保证表结构不会被更改。如果alter table持有锁时间过长，会导致所有Query线程都处于Opening table(等待获取LOCK_open锁)状态。

解决办法:
选择业务流量较低的时候进行
大于200M(数据+索引)的表考虑使用OSC工具

2.2 主库io波动造成的延迟

DBA主库排查日志、清理日志造成io波动，主从延迟增大

2.3 操作数据集较大的sql


优化索引的使用
更细粒度的分批操作


3. OSC工具使用

 

OSC(Online Schema Changing),在线表结构变更，DDL期间不影响表写入和查询，同时也消除因常规DDL操作造成的同步延迟，做到schema变更对业务透明，实现无缝切换。

OSC需要一台不提供服务从库辅助完成，通过从库进行表数据快照，然后导入主库新表作为基准数据，其次从库通过trigger记录增量数据并完成数据回放，最后通过rename操作实现原表与新表改名进而完成整个过程