要修复复制源数据库中的损坏问题，您可以恢复备份，注意不要将不必要的 SQL 操作传播到副本服务器：
关闭源数据库，然后使用，例如
copy-back-and-apply-log命令，恢复它的备份并准备数据。编辑源
my.cnf文件并注释掉log-bin，这样副本就不会收到恢复源所需的二进制日志的两倍。在将二进制日志通过管道传输到源时，必须暂时停止副本中的复制。在副本中，执行：
mysql> STOP SLAVE;在恢复的备份上 启动源mysqld ：
$ mysqld … InnoDB: Doing recovery: scanned up to log sequence number 0 64300044 InnoDB: Last MySQL binlog file position 0 5585832, file name ./omnibook-bin.000002 …InnoDB 打印二进制日志文件（在本例中）和它能够恢复到
./omnibook-bin.000002的位置（在本例中）。5585832将剩余的二进制日志文件通过管道传输到还原的服务器。剩余二进制日志文件的数量取决于上次备份与您希望将数据库更新到最新时间之间的时间跨度的长度。时间跨度越长，剩余的二进制日志文件可能越多。成功还原需要包含该时间跨度内所有连续二进制日志位置的所有二进制日志文件。
您还需要提供二进制日志中事件管道开始的起始位置。
meta/backup_variables.txt从您在上面的步骤 1 中刚刚恢复的备份中 的文件中推断出该信息 （backup_variables.txt例如，访问您在恢复期间指定的临时备份目录 ，并 在该文件夹--backup-dir下找到该meta文件）：查找条目 ，并 使用选项提供给mysqlbinlog 。binlog_position=valuemeta/backup_variables.txtvalue--start-position笔记虽然恢复后的最后一个二进制日志位置也由 InnoDB 显示（参见上面的第 4 步），但对于推断mysqlbinlog使用的起始位置来说，这不是一个可靠的数字，因为可能存在 DDL 事件和非 InnoDB 更改在显示位置反映的时间之后发生。
例如，如果还有两个二进制日志文件，
omnibook-bin.000003并且omnibook-bin.000004之后出现omnibook-bin.000002并且上面第 4 步中的恢复已5585834根据backup_variables.txt文件结束，则使用以下命令将二进制日志通过单个连接传输到服务器：$ mysqlbinlog --start-position=5585834 /mysqldatadir/omnibook-bin.000002 \ /mysqldatadir/omnibook-bin.000003 /mysqldatadir/omnibook-bin.000004 | mysql有关使用mysqlbinlog的更多说明， 请参阅使用二进制日志的时间点（增量）恢复。
源数据库现已恢复。关闭源并编辑
my.cnf以取消注释log-bin。再次启动源。
再次在副本中开始复制：
mysql> START SLAVE;