openstack数据库误删除可以恢复吗

1、环境说明
openstack集群中有两个节点
一个controller和一个compute
主机名分别是con和com

2、需求
现在计算节点所在的物理机重装系统了
故需要在控制节点的数据库中把计算节点删除

3、操作
mysql> delete from compute_nodes where id=1；

这里属于误操作，con和com的id分别是1和2

删除的第二个步骤没有做
也就是mysql> delete from services where host='con';

4、现在想要把删除的数据恢复，应该怎样做

这个挺多的，mysql误删除，网上有很多资料
应该有操作日志，到/app/mysql/log，会有相关内容。
可以自己搜索mysql误删除恢复，也可以参考下面内容

#################################


有备份的话很简单，只需要生成一个最近备份的数据 然后用mysqlbinlog找回备份时间点之后的数据 再恢复到现网即可。

要是没有备份 可能就会比较麻烦，找回数据的成本也是非常之高的.

下面介绍下 mysqlbinlog找回备份时间点之后的数据的办法：

做个简单的实验，将mysql的表数据删除之后，然后用mysqlbinlog 找回刚才删除的表的数据。

app表的创建时间和数据的插入： 2013-02-04 10:00:00

原理： mysqlbinlog

前提： mysql开启了bin log日志

测试删除之前：

[mw_shl_code=sql,true]mysql> show tables;[/mw_shl_code]
[mw_shl_code=bash,true]+-----------------------+
| Tables_in_report_sina |
+-----------------------+
| app                   |
| test                  |
+-----------------------+[/mw_shl_code]

[mw_shl_code=bash,true]mysql> select now();[/mw_shl_code]
[mw_shl_code=bash,true]+---------------------+
| now()               |
+---------------------+
| 2013-02-04 11:45:44 |
+---------------------+
1 row in set (0.01 sec)[/mw_shl_code]


[mw_shl_code=bash,true]mysql> select count(1) from app;[/mw_shl_code]
[mw_shl_code=bash,true]+----------+
| count(1) |
+----------+
|       10 |
+----------+
1 row in set (0.01 sec)[/mw_shl_code]



开始删除数据：

[mw_shl_code=bash,true]mysql> delete from app where id =1;[/mw_shl_code]
Query OK, 1 row affected (0.00 sec)

[mw_shl_code=bash,true]mysql>
mysql> delete from  app where id <6;[/mw_shl_code]
Query OK, 4 rows affected (0.01 sec)
mysql> select count(1) from app;
+----------+
| count(1) |
+----------+
|        5 |
+----------+
1 row in set (0.00 sec)



[mw_shl_code=bash,true]mysql> select now();[/mw_shl_code]
+---------------------+
| now()               |
+---------------------+
| 2013-02-04 12:08:45 |
+---------------------+



开始找回数据：

1.找到bin log的位置：

[mw_shl_code=bash,true]/app/mysql/log[/mw_shl_code]

[mw_shl_code=bash,true]-rw-rw---- 1 mysql mysql  17K Feb  4 11:43 alert.log
-rw-rw---- 1 mysql mysql 1.0K Nov  1 14:52 master-bin.000001
-rw-rw---- 1 mysql mysql  126 Dec 25 14:00 master-bin.000002
-rw-rw---- 1 mysql mysql  126 Dec 25 14:02 master-bin.000003
-rw-rw---- 1 mysql mysql  126 Dec 25 14:02 master-bin.000004
-rw-rw---- 1 mysql mysql  107 Dec 25 14:02 master-bin.000005
-rw-rw---- 1 mysql mysql  13K Feb  4 12:02 master-bin.000006[/mw_shl_code]

可以看到 最近被修改的bin log 只有  master-bin.000006

（要是误删除跨越了好几个bin log 找回数据的时候就必须一个个的bin log日志去找回了）

将这一段时间所有执行的sql语句存入到 待恢复的 sql文件中。

[mw_shl_code=sql,true]mysqlbinlog --start-date='2013-02-04 10:00:00' --stop-date='2013-02-04 12:08:45' /app/mysql/log/master-bin.000006 >/app/mysql/mysql_restore_20130204.sql[/mw_shl_code]

当然在现网环境下 ，这个时间可能没那么的准确，并且还有其他事务sql语句的干扰。



创建临时数据库

create database for_bak;

导出当前数据库中被误删的表 app

[mw_shl_code=sql,true]mysqldump -uroot -ppwd my_db app > /app/mysql/app.sql[/mw_shl_code]



将现在的数据导入到临时表：

[mw_shl_code=sql,true]mysql -root -ppwd for_bak < /app/mysql/app.sql[/mw_shl_code]



我们再来看下 /app/mysql/mysql_restore_20130204.sql的部分内容： （可以看到罪恶的delete 语句）

SET TIMESTAMP=1359949544/*!*/;
BEGIN
/*!*/;
# at 12878
#130204 11:45:44 server id 1  end_log_pos 12975  Query thread_id=5 exec_time=974 error_code=0
SET TIMESTAMP=1359949544/*!*/;
delete from app where id =1
/*!*/;
# at 12975
#130204 11:45:44 server id 1  end_log_pos 13002  Xid = 106
COMMIT/*!*/;
# at 13002
#130204 11:45:44 server id 1  end_log_pos 13077  Query thread_id=5 exec_time=1013 error_code=0
SET TIMESTAMP=1359949544/*!*/;
BEGIN
/*!*/;
# at 13077
#130204 11:45:44 server id 1  end_log_pos 13175  Query thread_id=5 exec_time=1013 error_code=0
SET TIMESTAMP=1359949544/*!*/;
delete from  app where id <6
/*!*/;
# at 13175
#130204 11:45:44 server id 1  end_log_pos 13202  Xid = 107
COMMIT/*!*/;
DELIMITER ;
# End of log file



可以看到 数据是什么时间点删除的 。  具体的时间也可以用 select from_unixtime(1359949544); 来查询

令人欣慰的是 create table app 语句和 insert 的语句也在这个文件之中。 在手工去掉 delete 语句之后 在临时库里面进行 source mysqlbinlog找回来的sql文件

就将app恢复到被删除之前的状态了。 然后将临时库的数据导入到现网数据（这个不是这篇文章的重点了）。



要是没有备份，要找回所有app表相关的数据 那可能就非常的麻烦了 尤其是 binlog文件非常多 而且每个都比较的大。

那样的话也只有从app的建立到现在 用mysqlbinlog来逐个的找回与app表相关dml操作的sql记录,然后整合恢复数据。

我想这种情况一般比较的少。虽然麻烦，但是也不是不能恢复。