寻找修复“无法解析中继日志事件条目.”的有效方法。错误

Question

我在MySQL 5.0中有一个损坏的中继日志，并查找修复复制的步骤，而不必再次从主服务器重新处理所有二进制日志。

如果您好奇的话，下面是完整的错误消息：

无法解析中继日志事件项。可能的原因是:主程序的二进制日志已损坏(您可以通过在二进制日志上运行“mysqlbinlog”来检查这一点)，从服务器的中继日志已经损坏(您可以通过在中继日志上运行“mysqlbinlog”来检查这一点)，网络问题，或者主或从的MySQL代码中的错误。如果您想检查主程序的二进制日志或从服务器的中继日志，您将能够通过在该奴隶上发出“显示从状态”来知道它们的名称。

正常的修复非常容易，您只需从“显示从状态”获得正确的二进制日志名称和位置，然后运行“更改主命令”。但这不是我想做的。

我只想从主服务器重新处理一个或几个二进制日志来恢复损坏的中继日志，然后继续使用已经创建的中继日志。我正在寻找的人谁有过去的经验这样做，因为有一个潜在的失败，采取这种方式的复苏。

从概念上讲，我认为可能需要采取以下步骤(也许其中一些是可选的)：

1. 停止从服务器上的复制。
2. 关机从实例。
3. 将中继日志移动到安全位置。
4. 查看中继日志信息或master.info文件是否需要手动更新。
5. 启动从实例。
6. 运行“更改主命令”并从失败位置重新处理二进制日志。
7. 等待下一个中继日志的创建。
8. 停止从服务器上的复制。
9. 关机从实例。
10. 找出如何将第二个中继日志文件替换为位于安全位置的中继日志文件，并将它们移动到。
11. 查看中继日志信息或master.info文件是否需要手动更新。
12. 启动从实例。
13. 希望是最好的。

我正在考虑一种替代的方法，这似乎要简单得多：

1. 停止从服务器上的复制。
2. 关机从实例。
3. 将中继日志移动到安全位置。
4. 启动从实例。
5. 运行“更改主命令”并从失败位置重新处理二进制日志。
6. 等待下一个中继日志的创建。
7. 停止从服务器上的复制。
8. 使用mysqlbinlog通过管道连接到mysql客户端来处理位于安全位置的中继日志。确定要开始的文件和位置。(可能出现问题，除非在第一次错误时中止处理)。
9. 在读取主日志文件/位置设置从母版复制的从服务器。

Answer 1

为了解决主服务器上二进制日志的低磁盘空间问题，我将二进制日志移动到另一个磁盘挂载，然后创建指向它们的符号链接，以便master知道在哪里找到它们。符号链接可以用"ln -s“或"cp -s”创建。

示例：

cd /disk1/mysql/binlogs/
ls /disk2/binlogs | xargs -l1 -i cp -s /disk2/binlogs/{} ./

在从服务器上，为了防止网络资源的浪费，我使用了Rolando建议的设置- relay_log_space_limit。这是有用的，因为中继日志在主服务器上的大量事务最终捕获之前多次被破坏。

我用了一种不同的方法来解决这个问题，然后我开始探索。我正在探索的解决方案似乎很复杂，而且有丢失数据的风险。不过，后来我确实发现，使用CHANGE命令读取服务器自己的中继或二进制日志支持我试图实现的一些步骤。但这只是拼图的一部分。由于MySQL 5.5具有复制校验和以及其他功能，如果升级到5.5，可能就不需要计算了。

MySQL手册在http://dev.mysql.com/doc/refman/5.0/en/change-master-to.html上说：

下一个示例显示了使用频率较低的操作。当从站有中继日志文件时，您希望它出于某种原因再次执行时，就会使用它。要做到这一点，主人不需要联系到。您只需要使用变更母版来启动SQL线程(启动从SQL_THREAD)：将主服务器更改为中继_LOG_FILE=‘从中继-bin.006’， RELAY_LOG_POS=4025；您甚至可以在非复制设置中使用第二个操作，在崩溃后使用独立的非从服务器进行恢复。假设您的服务器已经崩溃，并且已经从备份中还原了它。您希望重播服务器自己的二进制日志文件(不是中继日志文件，而是常规二进制日志文件)，名为myhost-bin.*。首先，在一些安全的地方备份这些二进制日志文件，以防您不完全遵循下面的步骤，并且不小心让服务器清除二进制日志。使用SET全局relay_log_purge=0以提高安全性。然后在没有-- log -bin选项的情况下启动服务器，相反，使用--复制-相同的服务器-id，-中继- log =myhost-bin(使服务器相信这些常规的二进制日志文件是中继日志文件)和-跳-从-启动选项。服务器启动后，发出以下语句:将主服务器更改为中继_ log _FILE=‘myhost-bin.153’， RELAY_LOG_POS=410，MASTER _HOST=‘some_dummy_SQL_THREAD’；启动从SQL_THREAD；服务器读取并执行自己的二进制日志文件，从而实现崩溃恢复。恢复完成后，运行停止从服务器，关闭服务器，删除master.info和中继-log.info文件，并使用其原始选项重新启动服务器。需要指定MASTER_HOST选项(即使使用虚拟值)，才能使服务器认为它是从服务器。

以下方法在理论上应该有效，主要问题是正确地从新创建的中继日志(S)的哪个位置停止处理，以及从保存的中继日志开始处理的位置。另一个问题是，如果有更多损坏的中继日志，则从主服务器识别要使用的日志/位置。

1. 停止从服务器上的复制。
2. 记录Master_Log_File / Read_Master_Log_Pos。
3. 关机从实例。
4. 将中继日志移动到安全位置。
5. 启动从实例。
6. 运行“更改主命令”并从失败位置重新处理二进制日志。
7. 等待到下一个或一些中继日志被创建。
8. 停止从服务器上的复制。
9. 使用“更改母版”命令处理位于安全位置的中继日志。确定要开始的文件和位置。
10. 在步骤2中记录的读取主日志文件/位置上设置从主目录复制的从服务器。