生活常识高性能MySQL-发送复制事件到其他备库

杨柳657

__选项可以让备库变成其他服务器的主库。在设置该选项后，MSQL会将其执行过的事件记录到他自己的二进制日志中。这样它的备库就可以从其日志中检索并执行事件。[url=https://www.simcentric.com/sc/]新天域互联[/url]的相关资讯可以到我们网站了解一下，从专业角度出发为您解答相关问题，给您优质的服务！https://www.simcentric.com/sc/[align=center]http://www.bignethk.com/upload/2019-10/07/thumb_4.png[/align]






        在这种场景下，主库将数据更新事件写人二进制日志，第一个备库提取并执行这个事件。这时候一个事件的生命周期应该已经结束了，但由于设置了_ , 备库会将这个事件写到它自己的二进制日志中。这样第二个备库就可以将事件提取到它的中继日志中并执行。这意味着作为源服务器的主库可以将其数据变化传递给没有与其直接相连的备库上。默认情况下这个选项是被打开的，这样在连接到备库时就不需要重启服务器。




         

当第一个备库将从主库获得的事件写人到其二进制日志中时，这个事件在备库二进制日志中的位置与其在主库二进制日志中的位置几乎肯定是不相同的，可能在不同的日志文件或文件内不同的位置。这意味着你不能假定所有拥有同一逻辑复制点的服务器拥有相同的日志坐标。稍后我们会提到，这种情况会使某些任务更加复杂，例如，修改一个备库的主库或将备库提升为主库。






        除非你已经注意到要给每个服务器分配一个唯一的服务器ID,否则按照这种方式配置备库会导致一些奇怪的错误，甚至还会导致复制停止。一个更常见的问题是:为什么要指定服务器ID，难道MSQL在不知道复制命令来源的情况下不能执行吗?为什么MSQL要在意服务器ID是全局唯一的。问题的答案在于MSQL在复制过程中如何防止无限循环。当复制SQL线程读中继日志时，会丢弃事件中记录的服务器ID和该服务器本身ID相同的事件，从而打破了复制过程中的无限循环。在某些复制拓扑结构下打破无限循环非常重要，例如主复制结构住。






        如果在设置复制的时候碰到问题，服务器ID应该是需要检查的因素之一。当然只检查@@ _是不够的，它有一个默认值，除非在文件或通过SET命令明确指定它的值，复制才会工作。如果使用SET命令，确保同时也更新了配置文件，否则SET命令的设定可能在服务器重启后丢失。