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.恢復完畢