跟踪从属滞后
我有主-主设置，我注意到活动主设备一次可以处理多个并发查询，而从设备一次读取一个查询，并且需要很多时间才能赶上。
1）这个问题有什么解决办法吗？
2) 为什么从机显示0秒为“seconds_behind_maser”。有时它会显示落后的正确秒数。但就我而言，它显示 0 秒，同时仍在读取日志。
3）为什么mmm_control显示两个Master都在线，而我期望一个Master处于“等待恢复”状态。
I have master-master setup and I noticed that the active master can handle several simultaneous queries at a time while the slave reads one query at a time and takes a lot of time to catch up.
1) Is there any solution to this?
2) Why does the slave shows 0 seconds as "seconds_behind_maser". There are times when it shows the correct number of seconds that it is behind. But in my case, it is showing 0 seconds while still reading from the log.
3) Why does mmm_control shows that both Masters are online while I expected one master to be in "awaiting recovery" state.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
回复：1）虽然主Master上可以同时执行多条语句，但是复制执行过程是单线程的，以保证服务器之间的数据一致性。
我从未使用过它，但您可能想研究一下 Maatkit mk-slave-prefetch 来预热您的从属设备，以加快您的更新速度。
回复：2）如果尚未从获取线程执行任何操作，则从机将显示落后于主机 0 秒。这通常会发生在网络延迟较高（相对于执行线程）的环境中。
Re: 1) Although multiple statements can be executing on the active master at once, the replication execution process is single-thread to ensure data consistency between servers.
I've never used it, but you might want to investigate Maatkit's mk-slave-prefetch to warm up your slave in hopes of speeding up your updates.
Re: 2) The slave will show 0 seconds behind master if doesn't have anything to execute from the fetching thread yet. This can often happen in environments with high network latency (relative to the execution thread).
对于主机来说，同时更新/回滚/超时等发生的顺序并不重要。因为它为解决冲突所做的一切都是正确的，并且客户得到了正确的反馈。
然而，从属设备必须以与主设备完全相同的顺序执行更新，实现这一点的唯一方法是按照主设备提交更新的顺序顺序运行更新。所以它不仅必须是单线程，而且只有在master提交后才能开始工作。通常这意味着提交日志记录被刷新到磁盘，因此需要等待实际的物理 IO。
For the master it doesnt matter what order simultanious updates/rollbacks/timeouts etc take place. As whatever it did to resolve a conflict is right and the clients are given the correct feedback.
The slave however must execute the updates in exactly the same order as the master, the only way to acheive this is to run the updates sequentially in the order the master commited them. So not only must it single thread, it can only start work after the master has commited. Usually this means when the commit log record is flushed to disk, so there is actual physical IO to wait for.