Club数据库基于时间点单表恢复案例

Club数据库基于时间点单表恢复案例

发现问题：

DBA于2016-05-20发现club数据库出现sql注入现象，如下图

此时数据库中数据已经被全部替换了，具体数据如下

可以看到nickname，realname都已经被修改，这是业务已经收到影响需要对数据进行恢复。

解决方案：

1、找到当天备份，并将备份文件直接启动。

启动时注意调一下配置文件中的server-id，避免与线上从库冲突

2、通过mysqlbinlog工具解析备份时间到当前时间的所有binlog日志并追加到一个临时文件中

mysqlbinlog -d club --start-datetime '2016-05-20 00:00:00' mysql-bin.000161 > /tmp/liuyaxin.sql

mysqlbinlog -d club --start-datetime '2016-05-20 00:00:00' mysql-bin.000162 >> /tmp/liuyaxin.sql

3、过滤临时文件中对该表的操作，找到导致问题的sql语句，并记录当时问题sql前一条sql的log_pos点，binlog_file信息没有记录，需要根据sql执行时间点去确认。

grep -B 2 user_doctor_new liuyaxin.sql | grep -A 5 -B 6  qwqrnore | more

导致问题sql及时间点：

该sql没有条件限制导致全表数据被恶意修改。

导致问题前一条sql及时间点：

4.在利用备份启动的实例上通过指定binlog_pos点结束位置的方式开启中从同步

start slave until MASTER_LOG_FILE='mysql-bin.000162',MASTER_LOG_POS=101655506;

等待数据同步，同步到指定pos点时 sql线程会自动断掉 

localhost.club>show slave status\G;

*************************** 1. row ***************************

Slave_IO_State: Waiting for master to send event

Master_Host: ****

Master_User: *****

Master_Port: ****

Connect_Retry: 60

Master_Log_File: mysql-bin.000164

Read_Master_Log_Pos: 107671841

Relay_Log_File: relay-bin.000004

Relay_Log_Pos: 101704628

Relay_Master_Log_File: mysql-bin.000162

Slave_IO_Running: Yes

Slave_SQL_Running: No

Replicate_Do_DB:

Replicate_Ignore_DB:

Replicate_Do_Table:

Replicate_Ignore_Table:

Replicate_Wild_Do_Table:

Replicate_Wild_Ignore_Table:

Last_Errno: 0

Last_Error:

Skip_Counter: 0

Exec_Master_Log_Pos: 101655506

Relay_Log_Space: 2255157326

Until_Condition: Master

Until_Log_File: mysql-bin.000162

Until_Log_Pos: 101655506

Master_SSL_Allowed: No

Master_SSL_CA_File:

Master_SSL_CA_Path:

Master_SSL_Cert:

Master_SSL_Cipher:

Master_SSL_Key:

Seconds_Behind_Master: NULL

Master_SSL_Verify_Server_Cert: No

Last_IO_Errno: 0

Last_IO_Error:

Last_SQL_Errno: 0

Last_SQL_Error:

1 row in set (0.00 sec)

根据标红字段可以看出数据已经同步到我们指定的位置了。

5.将同步完成后的要恢复的表dump出来，并恢复到线上库

6.校验数据

名字已经变回来了

9.恢复完毕

 

 

 

转载于:https://blog.51cto.com/jialong/1884293