10bet网址
MySQL企业备份3.11用户指南
相关的文档10bet官方网站 下载本手册
PDF(美国Ltr)- 1.0 mb
PDF (A4)- 1.0 mb


6.3恢复主数据库

要修复复制主数据库中的损坏问题,可以恢复备份,注意不要将不必要的SQL操作传播到从服务器:

  1. 使用主数据库的备份,执行运用原木操作,关闭数据库,然后执行复制回去操作。

  2. 编辑主文件my.cnf存档并注释掉log-bin,以便从服务器不会收到恢复主服务器所需的两倍的二进制日志。

  3. 在将二进制日志传输到主服务器时,必须暂时停止从服务器中的复制。在奴隶中,做:

    mysql STOP SLAVE;
  4. 启动mastermysqld在恢复的备份上:

    InnoDB: Last MySQL binlog file position 0 5585832,文件名./omnibook-bin. / mysqld:正在恢复:scanning up to log sequence number 0 64300044000002年……

    InnoDB打印二进制日志文件(。/ omnibook-bin.000002在本例中)和位置(5585832在这种情况下)它能够恢复到。

  5. 通过管道将剩余的二进制日志文件传输到恢复的服务器。剩余二进制日志文件的数量取决于从上次备份到将数据库更新到最新的时间间隔的长度。时间跨度越长,剩余的二进制日志文件可能就越多。成功恢复需要所有二进制日志文件(包含该时间跨度中所有连续的二进制日志位置)。

    您还需要提供二进制日志中的起始位置,事件的管道应该从该位置开始。从元/ 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

  6. 主数据库现在已经恢复。关闭主程序并进行编辑my.cnf要取消log-bin

  7. 再次启动master。

  8. 重新启动从端复制:

    mysql>启动SLAVE;