Mysql主从同步延迟受到多种因素影响, 比如大事务, 从库查询压力, 网路延迟等; 这些比较常见; 但还受到主从机器系统时钟差的影响,这一点可能容易被忽视。
总结一点导致主从库出现延迟的原因有可能是:大事务、从库查询压力大、网络本身有延迟。另外一点就是主从时钟的影响。即系统时间受到了影响!
查看的参数:Seconds_Behind_Master
这个参数有两种理解
一种理解是来源于Mysql手册上的描述,大体意思是这个时间是从库SQL线程处理的最近的日志事件的时间戳减去从库IO线程处理的最近一条日志记录的时间戳得到的, 可以简单理解为从库SQL线程与IO线程所处理的最近的日志事件的时间戳差;这个计算方式给人的感觉不是在计算主从延迟,而是在计算从库上两个线程的处理的日志的时差。
另一种理解来源于《High Performace Mysql》上的的描述,大体意思这个参数反映的结果是当前系统时间减去从库IO线程所处理的最近一条日志记录的时间戳;但这个说法有一个明显的不太让人信服的地方,就是如果机器的系统时间相差比较大怎么办? 显然, 如果系统时间相差比较大的话,以这样的方式计算主从延迟毫无意义。
通过查看源码发现这个值应该是这样理解的:
这个值是通过在主库上执行SELECT UNIX_TIMESTAMP()来取得主库的系统时间, 然后去减从库的当前系统时间。
原来系统时间差还真的对主从同步延迟参数Seconds_Behind_Master有影响。
那我就有一个疑问了。如果保证我的主从库的系统时间一致的话是不是就说我们主从复制延迟不存在呢?
那这种大事务、查询、那就不会影响到它了吗?
困惑。。。。
来源:http://blog.chinaunix.net/u2/84280/showart_2320627.html
总结一点导致主从库出现延迟的原因有可能是:大事务、从库查询压力大、网络本身有延迟。另外一点就是主从时钟的影响。即系统时间受到了影响!
查看的参数:Seconds_Behind_Master
这个参数有两种理解
一种理解是来源于Mysql手册上的描述,大体意思是这个时间是从库SQL线程处理的最近的日志事件的时间戳减去从库IO线程处理的最近一条日志记录的时间戳得到的, 可以简单理解为从库SQL线程与IO线程所处理的最近的日志事件的时间戳差;这个计算方式给人的感觉不是在计算主从延迟,而是在计算从库上两个线程的处理的日志的时差。
另一种理解来源于《High Performace Mysql》上的的描述,大体意思这个参数反映的结果是当前系统时间减去从库IO线程所处理的最近一条日志记录的时间戳;但这个说法有一个明显的不太让人信服的地方,就是如果机器的系统时间相差比较大怎么办? 显然, 如果系统时间相差比较大的话,以这样的方式计算主从延迟毫无意义。
通过查看源码发现这个值应该是这样理解的:
这个值是通过在主库上执行SELECT UNIX_TIMESTAMP()来取得主库的系统时间, 然后去减从库的当前系统时间。
原来系统时间差还真的对主从同步延迟参数Seconds_Behind_Master有影响。
那我就有一个疑问了。如果保证我的主从库的系统时间一致的话是不是就说我们主从复制延迟不存在呢?
那这种大事务、查询、那就不会影响到它了吗?
困惑。。。。
来源:http://blog.chinaunix.net/u2/84280/showart_2320627.html
作者:jackxiang@向东博客 专注WEB应用 构架之美 --- 构架之美,在于尽态极妍 | 应用之美,在于药到病除
地址:https://jackxiang.com/post/3793/
版权所有。转载时必须以链接形式注明作者和原始出处及本声明!
评论列表