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.恢复完毕