ySQL數據庫每日零點自動全備

某天上午10點，小明莫名其妙地drop了一個數據庫

我們需要通過全備的數據文件，以及增量的binlog文件進行數據恢復

利用全備的sql文件中記錄的CHANGE MASTER語句，binlog文件及其位置點信息，找出binlog文件增量的部分

用mysqlbinlog命令將上述的binlog文件導出為sql文件，并剔除其中的drop語句

通過全備文件和增量binlog文件的導出sql文件，就可以恢復到完整的數據

1. 模擬數據

CREATE TABLE `student` (

  `id` int(11) NOT NULL AUTO_INCREMENT,

  `name` char(20) NOT NULL,

  `age` tinyint(2) NOT NULL DEFAULT '0',

  PRIMARY KEY (`id`),

  KEY `index_name` (`name`)

) ENGINE=InnoDB AUTO_INCREMENT=8 DEFAULT CHARSET=utf8

mysql> insert student values(1,'zhangsan',20);

mysql> insert student values(2,'lisi',21);

mysql> insert student values(3,'wangwu',22);

2. 全備命令

# mysqldump -uroot -p -B -F -R -x --master-data=2 test|gzip >/server/backup/test_$(date +%F).sql.gz

參數說明：

-B 指定數據庫

-F 刷新日志

-R 備份存儲過程等

-x 鎖表

--master-data 在備份語句里添加CHANGE MASTER語句以及binlog文件及位置點信息

3. 繼續插入數據

mysql> insert student values(6,'xiaoming',20);

mysql> insert student values(6,'xiaohong',20);

此時誤操作，刪除了test數據庫

mysql> drop database test;

此時，全備之后到誤操作時刻之間，用戶寫入的數據在binlog中，需要恢復出來

4.查看全備之后新增的binlog文件

# cd /server/backup/

# ls

test_2016-08-02.sql.gz

# gzip -d test_2016-08-02.sql.gz

# grep CHANGE test_2016-08-02.sql

-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000003', MASTER_LOG_POS=107;

這是全備時刻的binlog文件位置，即mysql-bin.000003的107行，因此在該文件之前的binlog文件中的數據都已經包含在這個全備的sql文件中了

5. 移動binlog文件，并讀取sql，剔除其中的drop語句

# cp /data/3306/mysql-bin.000003 /server/backup/

# mysqlbinlog -d test mysql-bin.000003 >003bin.sql

# 用vim編輯文件，剔除drop語句

在恢復全備數據之前必須將該binlog文件移出，否則恢復過程中，會繼續寫入語句到binlog，最終導致增量恢復數據部分變得比較混亂

6. 恢復數據

# mysql -uroot -p <test_2016-08-02.sql

# mysql -uroot -p -e "select * from test.student;"

+----+----------+-----+

| id | name     | age |

+----+----------+-----+

|  1 | zhangsan |  20 |

|  2 | lisi     |  21 |

|  3 | wangwu   |  22 |

+----+----------+-----+

//此時恢復了全備時刻的數據

//然后使用003bin.sql文件恢復全備時刻到刪除數據庫之間，新增的數據

# mysql -uroot -p test<003bin.sql <span style="color: #3366ff;" data-mce-style="color: #3366ff;"><-需要指定恢復的數據庫

</span># mysql -uroot -p -e "select * from test.student;"

+----+----------+-----+

| id | name     | age |

+----+----------+-----+

|  1 | zhangsan |  20 |

|  2 | lisi     |  20 |

|  3 | wangwu   |  20 |

|  4 | xiaoming |  20 |

|  5 | xiaohong |  20 |

+----+----------+-----+

完成

恢復從庫t2表數據

0).關閉從庫同步

1).主庫添加讀鎖

讀鎖和寫鎖說明：

讀鎖

當前會話可以讀取t2表數據，無法寫入數據，立即返回錯誤ERROR 1099。

其他會話可以讀取t2表數據，無法寫入數據，寫入時會卡住，Waiting for table metadata lock。

寫鎖

鎖定后，當前會話仍然可以讀、寫t2表，其他會話對t2表不可讀、不可寫。

2).主庫備份

注意：

mysqldump中如果添加了--master-data=2或--flush-logs參數會導致備份時執行：

由于主庫已經將t2表改只讀狀態，導致mysqldump時FLUSH TABLES操作卡住，無法正常備份表。

所以備份時需要去掉--master-data=2和--flush-logs參數。

備份

傳到備庫

3).導入到從庫

從庫

恢復

4).忽略過濾

從庫檢查表數據

忽略過濾

注意：無單引號

檢查同步：

5).從庫：啟動同步

6).主、從：驗證數據量是否一致  

7).主庫：解鎖表

適用于：

測試環境：

創建測試數據

先看一下mysqldump備份選項：

執行數據庫全備

全庫備份

指定數據庫備份

指定表備份

只備份表結構

只備份表數據

其中：

--single-transaction 參數會添加下面額外執行：

--master-data=2和--flush-logs都會添加下面額外操作，注意鎖表：

繼續插入數據

查看數據

場景二：MySQL恢復指定表結構

通常定時備份是備份所有數據庫--all-databases，如何通過備份文件恢復所需的數據？

例如：cjc庫t2表

全備備份文件

恢復表結構

方式1：全備數據量很小時，直接通過vi進行查找

方式2：通過sed方式查找中備份文件中備份t2表結構部分

示例如下：

場景三：MySQL恢復指定表數據

例如：cjc庫t1表

方式1：全備數據量很小時，直接通過vi進行查找

方式2：通過grep方式查找中備份文件中備份t1表數據

示例如下：

場景四：MySQL恢復指定庫

通過--all-databases方式備份文件恢復指定數據庫數據。

例如:cjc庫數據

方式1：使用參數--one-database

還原：

通過general_log可以看到，只還原了cjc庫。

方式2：sed

查看文件

示例如下：

場景五：MySQL恢復所有庫數據

還原--all-databases備份的所有數據。

由于恢復了mysql庫，還原完數據庫后需要執行flush privileges;操作，或在備份是指定--flush-privileges。

參數說明如下：

場景六：MySQL恢復指定表到指定時間點

生成測試數據

備份表

繼續插入數據庫

更新數據

查看當前數據

刪除數據，模擬誤刪除

如何將數據恢復到刪除前時刻，恢復誤刪除的數據？

主庫查看信息

查看binlog信息

查看event信息

解析binlog數據

信息如下：

或者

備份數據還原

查詢數據

已將t1表還原到備份時間點數據。

需要通過binlog將數據推進到誤刪除數據前一時刻。

查看備份文件位置信息

查詢delete位置信息

前面查到的

或者

誤刪除開始位置  1312

這個位置應該在delete的上一個事務COMMIT下面的位置，也就是delete前面SET @@SESSION.GTID_NEXT對應的位置信息。

生成還原語句

先生成可讀的文件，通過vi等校驗是否有問題

在去掉-vvv --base64-output=decode-rows參數，生成最終恢復文件

注意：

這里必須選擇上一條語句commit之后的position，不能是刪除語句開始的position 1439，否則會有這個警告。

警告：打印的事件范圍以未設置STMT_END_F標志的行事件或表映射事件結束。這可能是因為最后一條語句沒有完全寫入日志，或者是因為您使用了--stop-position或--stop-datetime來引用語句中間的事件。分部語句中的事件尚未寫入輸出。

使用 --skip-gtids=true 參數

如果要恢復數據到源數據庫或者和源數據庫有相同 GTID 信息的實例，那么就要使用該參數，否則無法恢復成功的。

因為相同的GTID事務已經在源數據庫執行過了，根據 GTID 特性，一個 GTID 信息在一個數據庫只能執行一次，所以默認不會恢復成功。

查看日志內容

刷新binlog

還原誤刪除的數據：

通常會先將數據還原到測試庫里，確保沒問題以后，在導出導入到生產庫。

查看數據

已恢復到誤刪除前的數據

適合人為SQL語句造成的誤操作或者沒有主從復制等的熱備情況宕機時的修復

恢復條件要全備和增量的所有數據

恢復時建議對外停止更新，即禁止更新數據庫

先恢復全量，然后把全備時刻點以后的增量日志，按順序恢復成SQL文件，然后把文件中有問題的SQL語句刪除（也可通過時間和位置點），再恢復到數據庫