要修复复制源数据库中的损坏问题,可以恢复备份,注意不要将不必要的SQL操作传播到复制服务器:
关闭源数据库,然后使用
copy-back-and-apply-log
命令,以恢复它的备份并准备数据。编辑源代码的
my.cnf
存档并注释掉log-bin
,以便副本不会收到恢复源所需的两倍二进制日志。在将二进制日志传输到源时,副本中的复制必须暂时停止。在副本中,做:
mysql STOP SLAVE;
启动源代码mysqld在恢复的备份上:
InnoDB: Last MySQL binlog file position 0 5585832,文件名./omnibook-bin. / mysqld:正在恢复:scanning up to log sequence number 0 64300044000002年……
InnoDB打印二进制日志文件(
。/ omnibook-bin.000002
在本例中)和位置(5585832
在这种情况下)它能够恢复到。通过管道将剩余的二进制日志文件传输到恢复的服务器。剩余二进制日志文件的数量取决于从上次备份到将数据库更新到最新的时间间隔的长度。时间跨度越长,剩余的二进制日志文件可能就越多。成功恢复需要所有二进制日志文件(包含该时间跨度中所有连续的二进制日志位置)。
您还需要提供二进制日志中的起始位置,事件的管道应该从该位置开始。从
元/ backup_variables.txt
您刚刚在上面的第1步中恢复的备份中的文件(访问backup_variables.txt
例如,通过转到您指定的临时备份目录——backup-dir
在恢复过程中,找到文件元
文件夹):查找条目binlog_position =
在价值
元/ backup_variables.txt
,及供应价值
来mysqlbinlog与——起始位置
选择。请注意虽然恢复后的最后一个二进制日志位置也会被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. 000002 \ /mysqldatadir/omnibook-bin。000003 / mysqldatadir / omnibook-bin。000004 | mysql
看到时间点(增量)恢复更多使用说明mysqlbinlog.
源数据库现在已经恢复。关闭源代码并进行编辑
my.cnf
要取消log-bin
.再次启动源代码。
重新在副本中启动复制:
mysql>启动SLAVE;