赞
踩
如果有备库和新主库的位置不相同,则需要找到该备库最后一条执行的时间在新主库的二进制日志中相应的位置,然后再执行CHANGE MASTER TO.可以通过mysqlbinlog工具来找到备库执行的最后一条查询,然后在主库上找到同样的查询,进行简单的计算即可得到。
为了便于描述,假设每个日志时间有一个自增的数字ID,最新的备库,也就是新主库,在旧主库崩溃时获得了编号为100的事件,假设有另外两台备库:replica2和replica3。replica2已经获取了99号事件,replica3获取了98号事件。如果把两台备库都指向新主库的同一个二进制日志位置,它们将从101号事件开始复制,从而导致数据不同步。但只要新主库的二进制日志已经通过log_slave_updates打开,就可以在新主库的二进制日志中找到99号和100号日志,从而将备库恢复到一致的状态。由于服务器重启,不同的配置,日志轮转或者FLUSH LOGS命令,同一个事件在不同的服务器上可能有不同的偏移量。找到这些事件可能会耗时很长并且枯燥,但是通常没有难度。通过mysqlbinlog从二进制日志或中继日志中解析出每台备库上执行的最后一个事件,并同样使用该命令解析新主库上的二进制日志,找到相同的查询,mysqlbinlog会打印出该事件的偏移量,在CHANGE MASTER TO命令中使用这个值。(pt-heartbeat的心跳记录能够很好地帮助你好到正在查找的事件的大约位置)
更快的方法是把新主库和停止的备库上的字节偏移量相减,它显示了字节位置的差异。然后把这个值和新主库当前二进制日志的位置相减,就可以得到期望的查询的位置。只需要验证一下就可以据此启动备库。
假设server1是server2和server3的主库,其中服务器server1已经崩溃。根据SHOW SLAVE STATUS获得Master_Log_File/Read_Master_Log_Pos的值,server2已经执行完了server1上所有的二进制日志,但server3还不是最新的数据,如图显示了这个场景(日志事件和偏移量仅仅是为了举例).正如图所示。我们可以肯定server2已经执行完主库上的所有二进制日志,因为Master_Log_File和Read_Master_Log_Pos值和server1上最后的日志位置是相吻合的,因此我们可以将server2提升为新主库,并将server3设置为server2的备库。应该在server3上为需要执行的CHANGE MASTER TO语句赋予什么样样的参数呢?这里需要做一点点计算和调整。server3在偏移量1493停止,比server2执行的最后一条语句的偏移量1582小89字节。server2正在向偏移量为8167的二进制日志写入,8167-89=8078,因此理论上我们应该将server3指向server2的日志的偏移量为8078的位置。最好去确认下这个位置附近的日志事件,以确定在该位置上是否是正确的日志事件,因为可能有别的例外,例如有些更新可能只发生在server2上。假设我们光查到的事件是一样的,下面这条命令会将server3切换为server2的备库。
server2>CHANGE MASTER TO MASTER_HOST="server2",MASTER_LOG_FILE="mysql-bin.000009", MASTER_LOG_POS=8078;
如果服务器在它崩溃时已经执行完成并记录了超过一个事件,会怎样呢?因为server2仅仅读取并执行到了偏移量1582,你可能永远地失去了一个事件。但是如果老主库的磁盘没有损坏,仍然可以通过mysqlbinlog或者从日志服务器的二进制日志中找到丢失的事件。
如果需要从老朱库上恢复丢失的事件,建议在提升新主库之后且在允许客户端连接之前做这件事情,这样就无须再每台备库上都执行丢失的事件,只需要使用复制来完成。但如果崩溃的老主库完全不可用,就不得不等待,稍后再做这项工作。
上述流程中一个可调整的地方是使用可靠的方式来存储二进制日志,如SAN或分布式复制数据库设备(DRBD).即使主库完全失效,依然能够获得它的二进制日志。也可以设置一个日志服务器,把备库指向它,然后让所有备库赶上主库失效的点。这使得提升一个备库为新的主库没那么中国要。本质上这和计划中的提升是相同的。(当提升一台备库为主库时,千万不要将它鞥多服务器ID修改成源主库的服务器ID,否则将不能使用日志服务器从一个旧主库来重放日志事件。这也是确保服务器ID最好保持不变的原因之一)
主-主复制拓扑结构的一个好处就是可以很容易地切换主动和被动的角色,因为其配置是对称的。当在主-主配置下切换角色时,必须确保任何时候只有一个服务器可以写入。如果两台服务器交叉写入,可能会导致写入冲突。换句话说,在切换角色后,原被动服务器不应该接收到主动服务器的任何二进制日志。可以通过确保原被动服务器的复制SQL线程在该服务器可写之前已经赶上主动服务器来避免。通过以下步骤切换服务器角色,可以避免更新冲突的危险:
可能还需要做一些额外的工作,包括更改两台服务器的IP地址,这取决于应用的配置
中断MySQL的复制并不是件难事,因为实现简单,配置相当容易,但也意味着有很多的方式导致复制停止,现如混乱并中断。
由于各种各样的原因,MySQL的复制并不能很好地从服务器崩溃、掉电、磁盘损坏、内存或网络错误中恢复。遇到这些问题时几乎可以肯定都需要从某个点开始重启复制。大部分由于非正常关机后导致的复制问题都是由于没有把数据及时地刷到磁盘。下面是意外关闭服务器时可能会碰到的情况.
除了由于MySQL非正常关闭导致的数据丢失外,磁盘上的二进制日志或终极日志文件损坏并不罕见,下面是一些更普遍的场景:
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。