Chinaunix首页 | 论坛 | 博客
  • 博客访问: 647663
  • 博文数量: 137
  • 博客积分: 6189
  • 博客等级: 准将
  • 技术积分: 1559
  • 用 户 组: 普通用户
  • 注册时间: 2010-03-15 16:39
文章分类

全部博文(137)

文章存档

2010年(3)

2009年(1)

2008年(49)

2007年(56)

2006年(28)

分类: LINUX

2009-09-15 10:57:42

网络上看到的文档,记录下。  
The second step was to restore the data from the time of the backup (which was about 10 hours ago) up to the point of the crash. The binary log was already spread across two files at that time. So I had to extract all the data manipulating statements for the database holding the crashed table from those two binlog files to a text file.

mysqlbinlog --database=db_name --start-position=102655866 mysql1-bin.000312 > restore.sql
mysqlbinlog --database=db_name mysql1-bin.000313 >> restore.sql
    The start-position is of course the position of the binlog at the time of the backup. Now I could do a search for all statements affecting the crashed table and feed them to mysql again.
    grep -B3 table_name restore.sql | egrep -v '^--$' > restore_table.sql
    emacs restore_table.sql
    mysql db_name < restore_table.sql
    As I knew that all those statements didn't contain any newlines I used a simple approach with grep (the -B3 giving me the lines with the meta information just before the actual statement), quickly checked the resulting file in a text editor (where I deleted the ALTER TABLE statement, too, to not have the crash happen again) and ran the queries.
    That's it. The table was now in exactly the same state as it was before the crash.
阅读(3124) | 评论(7) | 转发(0) |
给主人留下些什么吧!~~

clx_vio2015-08-21 14:45:14

版主好,想请问要怎么能联系到姜版主?有几个innodb的问题想请教他

枫影谁用了2009-09-22 10:37:46

YES,你说得很对。

枫影谁用了2009-09-22 10:37:46

YES,你说得很对。

枫影谁用了2009-09-22 10:37:46

YES,你说得很对。

gladness2009-09-18 11:36:50

这样的恢复似乎不太严格,不能保证数据一致。 比如这张表的数据依赖了其他的表,比如: insert ... select ... 这样的语句,别的表的数据变化会影响到执行结果。