为什么要分离读和写呢?
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)、解决方法:
半同步复制–解决数据丢失的问题
并行复制–解决从库复制延迟的问题