模擬資料恢復的案例

一、update未加where條件，誤操作修改資料

在生產環境中，我們搭建了mysql主從，備份操作都是在從備份資料庫上

前提：有最近一天或者最近的全備

          或者最近一天相關資料庫的備份

          最重要的是，二進位制日誌必須完整

全備命令： mysqldump -uroot -p123456  --single-transaction --set-gtid-purged=OFF --master-data=2 -A > all_database.sql

                   mysqldump -uroot -p123456  --single-transaction --set-gtid-purged=OFF --master-data=2  xcrm  > xcrm.sql

模擬災難現場

kubectl get all -o wide

kubectl exec -it mysql-master-659958ff4f-l4sgt bash

mysql -uroot -p123456

mysql> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| performance_schema |
| sys |
| xcrm |
+--------------------+
5 rows in set (0.00 sec)

mysql> use xcrm

mysql> create table edai_test like ding_cun;

mysql> insert into edai_test select * from  ding_cun;

比如凌晨全備是做到這裡的

 命令：mysqldump -uroot -p123456  --single-transaction --set-gtid-purged=OFF --master-data=2 -A > all_database.sql

早上九點的時候，又有新的資料進來

mysql> insert into edai_test(nper,money) select nper,money from ding_cun;

110 rows in set (0.00 sec)

悲劇來了，上線中的sql，沒有檢查，where條件沒加，直接執行

mysql> update edai_test set money=0;
Query OK, 110 rows affected (0.07 sec)
Rows matched: 110 Changed: 110 Warnings: 0

糟糕，一不小心金額被我修改為0了，偶my嘎，

趕緊恢復，找出binlog點，根據之前的全備+binlog恢復

恢復步驟：

1.找出時間段

[email protected]:~/backu1.p# cat all_database.sql |grep -i 'CHANGE MASTER TO MASTER_LOG_FILE'|head -n1

-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=154;

mysql -uroot -p123456 -e "show binlog events in 'mysql-bin.000001'"|tail -n1000

找到了對應pos點

4326

2.mysql匯入昨天晚上的備份資料，並且檢視pos節點

mysql -uroot -p123456 < all_databases.sql

3.拷貝二進位制日誌檔案到其他地方和二進位制恢復

cp /var/lib/mysql/mysql-bin.000001 .

[email protected]:~/backup#  mysqlbinlog  --start-position=154 --stop-position=4326 -d xcrm mysql-bin.000001|mysql -uroot -p123456 xcrm

好了，資料恢復

二、刪庫

其實刪除資料庫都是一樣的道理

比如我們的備份是昨天晚上的，但是今天早上清理資料，刪除無效的資料庫，誤刪了  

恢復步驟和原理都是差不多的，我就不演示了，簡單講解下

mysql> create table customers(

-> id int not null auto_increment,
-> name char(20) not null,
-> age int not null,
-> primary key(id)
-> )engine=InnoDB;
Query OK, 0 rows affected (0.35 sec)

mysql> insert into customers values(1,"wangbo","24");
Query OK, 1 row affected (0.07 sec)

mysql> insert into customers values(2,"guohui","22");
Query OK, 1 row affected (0.12 sec)

mysql> insert into customers values(3,"zhangheng","27");
Query OK, 1 row affected (0.06 sec)

mysql> select * from customers;
+----+-----------+-----+
| id | name | age |
+----+-----------+-----+
| 1 | wangbo | 24 |
| 2 | guohui | 22 |
| 3 | zhangheng | 27 |
+----+-----------+-----+
3 rows in set (0.00 sec)

 mysql> drop database xcrm;

Query OK, 5 rows affected (0.40 sec)

[email protected]:~/backup# mysql -uroot -p123456 -e "show binlog events in 'mysql-bin.000001'"|grep -i 'DROP DATABASE'

mysql: [Warning] Using a password on the command line interface can be insecure.
mysql-bin.000001 15035 Query 22 15127 drop database xcrm

[email protected]:~/backup# cat all_database.sql |grep -i 'CHANGE MASTER TO MASTER_LOG_FILE'|head -n1
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=13871;

先將今天凌晨備份的導進去

 mysql -uroot -p123456 < all_database.sql 

    13871   15035  

mysql> use xcrm
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> show tables;
+------------------------+
| Tables_in_xcrm |
+------------------------+
| customers |
| ding_cun |
| edai_a_novice_vouchers |
| edai_app_version |
| test |
+------------------------+
5 rows in set (0.00 sec)

mysql> select * from customers;
+----+-----------+-----+
| id | name | age |
+----+-----------+-----+
| 1 | wangbo | 24 |
| 2 | guohui | 22 |
| 3 | zhangheng | 27 |
+----+-----------+-----+
3 rows in set (0.00 sec)

好了，drop資料庫也可以恢復啦

大家有沒有什麼疑問？

要是在生產環境，恢復也是這麼簡單嘛，不需要考慮其他東西嗎

 肯定需要的：

1.恢復某個表的時候，要確保這個表不讀寫，只能讀

2.如果是遇到刪庫的動作，就需要設定為全域性鎖庫

另外呢，假如在生產環境誤操作了，比如delete，update等表的操作

我們可以用python開發的一個工具：binlog2sql    (mysql閃回工具)