小编dab*_*st1的帖子

如果在发布者为 SQL 2008 Enterprise（支持数据压缩）且订阅者为 SQL 2008 Standard（不支持数据压缩）的复制表（合并复制）上启用数据压缩（行级或页级），会发生什么情况. 压缩属性会被礼貌地删除而订阅者继续愉快地未压缩还是会导致复制出错并停止？

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

如果您好奇，这里是完整的错误消息：
无法解析中继日志事件条目。可能的原因有：master的二进制日志损坏（可以通过运行'mysqlbinlog'查看二进制日志），slave的relay log损坏（可以通过运行'mysqlbinlog'查看relay log），a网络问题，或者 master 或 slave 的 MySQL 代码中的错误。如果您想检查主站的二进制日志或从站的中继日志，您将能够通过在此从站上发出“显示从站状态”来知道它们的名称。

正常的修复非常简单，您只需从 show slave status 中获取正确的二进制日志名称和位置并运行 change master 命令。但这不是我想做的。

我只想重新处理来自 master 的一个或几个二进制日志以恢复损坏的中继日志，然后继续使用已经创建的中继日志。我正在寻找过去有这样做经验的人，因为以这种方式进行恢复可能会失败。

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

1. 停止从服务器上的复制。
2. 关闭从属实例。
3. 将中继日志移动到安全位置。
4. 查看是否需要手动更新relay-log.info 或master.info 文件。
5. 启动从属实例。
6. 运行 change master 命令并从失败的位置重新处理二进制日志。
7. 等待直到创建下一个中继日志。
8. 停止从服务器上的复制。
9. 关闭从属实例。
10. 弄清楚如何用位于安全位置的中继日志文件替换第二个中继日志文件并将它们移入。
11. 查看是否需要手动更新relay-log.info 或master.info 文件。
12. 启动从属实例。
13. 希望最好的。

我正在考虑另一种方法来做到这一点，这似乎更简单：

1. 停止从服务器上的复制。
2. 关闭从属实例。
3. 将中继日志移动到安全位置。
4. 启动从属实例。
5. 运行 change master 命令并从失败的位置重新处理二进制日志。
6. 等待直到创建下一个中继日志。
7. 停止从服务器上的复制。
8. 使用 mysqlbinlog 通过管道传输到 mysql 客户端来处理位于安全位置的中继日志。确定从哪个文件和位置开始。（潜在的问题，除非在第一次错误时中止处理）。
9. 将从服务器设置为在读取的主日志文件/位置从主服务器复制。