MySql数据库主从库同步的延迟问题

为什么要分离读和写呢？
MySQL写的操作涉及到锁的问题，不管是行锁还是表锁还是页锁，都是比较降低系统执行的效率；把写的操作集中在一个节点上，而读的操作其他的N个节点上进行，T提高读的效率保证系统的高可用性

为什么会产生这样的问题？
1：mysql在进行主从同步，主库针对写的操作，顺序的写入binlog，从库单线程的去主库顺序的读取 主库写入的binlog，从库取到主库的binlog在本地执行，来保证主从数据的一致性，mysql的主从复制都是单线程操作的，由于slave_sql_running也是单线程的，所以一旦DDL卡住了，那么所有以后要执行的DDL都会等待这个DDL执行完才会继续执行，这样会导致延迟的问题。
2：当主库的tps并发较高，产生的DDL数量超过salve一个SQL线程所能承受的范围，那么久会产生延迟。还有就是可能与slave的大型query语句产生了锁等待过程，数据库在业务上读写压力太大，CPU负荷大，网卡符合大，硬盘随机IO太高；
3：读写binlog带看来的性能影响，网络传输延迟

如何解决主从同步延迟的问题？
1：架构问题
（1）业务的持久化层采用分库的架构，MySQL服务可平行扩展，分散压力。
（2）主从库部署在不同的服务器上，一主多从，这样从库的压力比主库的压力大，从而保护主库
（3）服务的基础架构在月无上和mysql之间增加memcache和redis的cache层。降低MySQL的读压力
（4）不同业务的MySQL物理上放在不同的机器上，分散压力
2)、硬件方面

1.采用好服务器，比如4u比2u性能明显好，2u比1u性能明显好。2.存储用ssd或者盘阵或者san，提升随机写的性能。

3.主从间保证处在同一个交换机下面，并且是万兆环境。

总结，硬件强劲，延迟自然会变小。一句话，缩小延迟的解决方案就是花钱和花时间。

3)、mysql主从同步加速

1、sync_binlog在slave端设置为0

2、logs-slave-updates 从服务器从主服务器接收到的更新不记入它的二进制日志。

3、直接禁用slave端的binlog

4、slave端，如果使用的存储引擎是innodb，设置innodb_flush_log_at_trx_commit =2

4)、磁盘IO上操作

从文件系统本身属性角度优化master端修改linux、Unix文件系统中文件的etime属性， 由于每当读文件时OS都会将读取操作发生的时间回写到磁盘上，对于读操作频繁的数据库文件来说这是没必要的，只会增加磁盘系统的负担影响I/O性能。

主从同步的延迟的解决数据一致性方案：
1)、主从复制存在的问题：
主库宕机，数据丢失
从库只有一个SQL thread 主库写压力大，复制可能延时
2)、解决方法：
半同步复制–解决数据丢失的问题
并行复制–解决从库复制延迟的问题