最近碰到几次主从延时的问题,也有同行在抱怨这个,稍微整理一下 出现问题的两个场景: 场景1.主库进行alter操作,花费大约10min,从库复现这个alter的时候,也花费了约10min的时间,期间延时不断在增加; 场景2.主库上对一张MyISAM的表有大量的增删改操作,从库的业务语句在操作这张表经常会遇到表锁,导致从库延时; 场景问题分析: 场景1:其实这个场景很简单,这种需要花费很多时间的alter语句,在主库花费这么久,在从库复现必然也是要花费很多时间的,自然会阻塞之后的同步; 场景2: 首先要确认MyISAM的特性,MyISAM的表是表级别的锁,读写互斥, 当同步的SQL线程在增删改数据的时候,如果有select语句在操作这个表,是会产生表级锁,阻塞同步的SQL线程, 简单模拟以下表级锁阻塞从库SQL线程的情况 MyISAM的表遇到这种情况其实和情景1是一种类型的,那就是主库上的操作在从库复现的时候很慢/被阻塞,出现问题的地方都是复现的SQL本身, 这种类型的问题,基本只能把这些“问题SQL”放在空闲时段去操作,属于DBA的操作规范一类了, 如果是正常时间段出现了这种情况,可以考虑单独分离某一台延时的从库,屏蔽业务请求,等延时消除以后,再添加回去,再替换另外有延时的从库,依次去追主库了; 主从延时还存在一种类型,就是从库的同步卡在写binlog这一部分,典型的表现就是从库的系统IO等待很高,这种情况,视业务类型去修改事务组和日志刷新策略的值,或者更换存储,提高硬件能力~(责任编辑:好模板) |