Mysql 完全恢复、基于时间点恢复、基于位置恢复

webtet

（注意根据实际环境调整）

1.刷新binlog （取得最后1份有价值的2进制日志），或执行一次增量备份的脚本。

#mysqladmin -u**** -p**** flush-logs

2.全备当前要操作的数据库，防止2次破坏。(如 lsws)

# mysqldump lsws > lsws.sql

3.恢复时间最近的全备数据。(db121019为最近的全备数据库)

#mysql lsws < db121019

4.恢复从db121019数据库后所有的binlog，到出问题的日志为止（这里假设1-20为正常，21为错误的日志。）

#ls -t -r -l /data/dbbak/daily/mysql-bin.* | xargs mysqlbinlog | mysql   

(此操作ls -t -r -l /data/dbbak/daily/mysql-bin.* ，确保显示的日志顺序是按正常排序。如果顺序不对则用下一条命令，或者手动按顺序依次恢复,注意不要包含了错的日志)

#mysqlbinlog mysql-bin.000001  (省略mysql-bin.00002-19 ......)  mysql-bin.000020 | mysql

5.恢复有错误的binlog，为不完全恢复（假设为mysql-bin.000021）

⑴基于时间点的恢复。（首先找到出错的时间，如：2012-10-19 17:25:44 45 46 秒的操作都是错误的，然后跳过故障时间点，进行恢复。）

#mysqlbinlog --stop-date="2012-10-19 17:25:44" mysql-bin.000021 | mysql

#mysqlbinlog --start-date="2012-10-19 17:25:47" mysql-bin.000021 | mysql

⑵基于位置的恢复。（首先找到出错的位置，然后跳过故障位置点，进行恢复。）

我们发现故障前后的位置号是分别是413到517。就是end_log_pos后边显示的。

#mysqlbinlog --stop-position="413" mysql-bin-3306.000021 | mysql

#mysqlbinlog --start-position="517" mysql-bin-3306.000021 | mysql

注：可能是本机采用innodb的原因。采用上面操作，会出现类似这种的错误ERROR 1062 (23000) at line 32: Duplicate entry '27' for key 'PRIMARY'

实际中恢复中，找到正确操作的那条语句，找准原先操作语句的位置点end_log_pos，再执行一次就行了。

比如正确操作的位置点为"175"到"398"

下面这条语句，就实现了恢复

mysqlbinlog --start-position="175" --stop-position="398" mysql-bin-3306.000021 | mysql -uroot -proot

sdtf08

路过，学习下

2004

床上运动也可以减肥的，你们都不知道吗？

sakko51150

帮帮顶顶！！

旃麒雅

生活***好玩，因为生活老***玩我!

搜索泥称

男人在结婚前觉得适合自己的女人很少，结婚后觉得适合自己的女人很多。

lzf79

微机原理闹危机，随机过程随机过，实变函数学十遍，汇编语言不会编！