http://xiaorenwutest.blog.51cto.commysql
MySQL數據庫的災難恢復與備份sql
數據庫對於公司來講是重中之重;記錄着公司的龐大數據,關係到公司的財產,以及客戶的資料,若是一旦丟失將會爲公司形成沒法估量的損失。數據庫
可是若是作好備份工做能夠避免這種狀況的發生;因此說做爲一名合格的DBA人員來講掌握數據庫的備份和回覆是必不可少的技能。另外在工做當中公司也會進行一些計劃:好比說數據庫的災難與恢復的測試。今天爲你們帶來的就是關於MySQL的備份與恢復。服務器
一:咱們在這裏採用的是mysqldump工具進行備份:ide
mysqldump備份結合binlog日誌恢復工具
這裏咱們須要知道的是mysql備份通常採用的是全庫備份加日誌備份的方式,好比說每週執行一次全庫備份,天天執行一次二進制備份,這樣當MySQL發生故障的時候能夠還原到故障以前的任意位置和時間。post
1)binlog日誌:學習
相信你們都知道binlog日誌是用來記錄數據庫發生了改變的日誌;好比增、改、刪等sql語句,另外在主從複製的時候也須要開啓此日誌。測試
開啓binlog日誌的方式:大數據
/etc/my.cnf主配置文件當中開啓:
以後保存文件,重啓MySQL服務
讓咱們看一下,是否已經開啓了binlog服務呢?
其中;filename參數指定二級制文件的文件名,其形式爲filename.number,number的形式爲000001、000002等。每次重啓mysql服務或運行mysql> flush logs;都會生成一個新的二進制日誌文件,這些日誌文件的number會不斷地遞增。除了生成上述的文件外還會生成一個名爲filename.index的文件。這個文件中存儲全部二進制日誌文件的清單又稱爲二進制文件的索引
讓咱們看一下:
在這裏咱們對binlog日誌進行個總結:
1:記錄數據庫發生改變的sql語句
2:能夠主從複製
3:最主要的是能夠恢復丟失的數據
bin-log由於是二進制文件,不能經過文件內容查看命令直接打開查看,mysql提供兩種方式查看方式,在介紹以前,咱們先對數據庫進行一下增刪改的操做,不然log裏邊數據有點空。
#mysql -uroot -p -e "reset master"=========>刪除全部的二進制文件,重新生成一個新的二進制文件
#mysql -uroot -p -e "create database test"=============>建立一個test的數據庫
#mysql -uroot -p -e "use test;create table tb1(id int primary key auto_increment,name varchar(20))"==========>在test數據庫當中新建表tb1;ID爲自動增加和name
#mysql -uroot -p -e "insert into test.tb1(name) values('lisi')"==========>在tb1表中插入用戶lisi
#mysql -uroot -p -e "insert into test.tb1(name) values('zhangsan')"==========>再次插入用戶zhangsan
讓咱們看一下上面的操做是否成功
接下來咱們從新在生成一個binlog的日誌文件:而後將以前的用戶ID爲2(zhangsan)的用戶刪掉,以後在建立一個用戶爲Tom的人員。
#mysql -uroot -p -e "flush logs"
#mysql -uroot -p -e "delete from test.tb1 where id=2"
#mysql -uroot -p -e "insert into test.tb1(name) values('tom')"
# mysql -uroot -p -e "select * from test.tb1"
如今讓咱們看一下數據庫當中還有誰存在:
接下來讓咱們看一下咱們的二進制日誌文件當中的內容;以及如何進行恢復:
能夠看到如今咱們只有兩個二進制日誌文件:
接下來咱們查看下二進制日誌文件當中的信息
mysql> show binlog events;
默認顯示可找到的第一個二進制日誌文件中的事件,包含了日誌文件名、事件的開始位置、事件類型、結束位置、信息等內容
Format_desc | //此事件爲格式描述事件
Query //爲查詢事件
Table_map //爲表映射事件
Write_rows //爲咱們執行的insert事件
Xid //Xid時間是自動提交事務的動做
Rotate //爲日誌輪換事件,是咱們執行flush logs開啓新日誌文件引發的。
剛纔查看的是默認的二進制文件爲000001;接下來咱們查看下第二個二進制文件
mysql> show binlog events in 'mysql-bin.000002';
另外換能夠經過show binlog events in 'mysql-bin.000002' from 219 limit 1,3;語句查看從219到301的數據,這裏不在演示,在文章的後面我會爲你們介紹幾條sql的語句
接下來咱們開始進行數據的恢復{恢復以前刪掉的ID=2的用戶}
不管是本地二進制日誌文件仍是遠程服務器上的二進制日誌文件,不管是行模式、語句模式仍是混合模式的二進制日誌文件,被mysqlbinlog工具解析後均可直接應用與MySQL Server進行基於時間點、位置或數據庫的恢復。
恢復步驟:
首先查看binlog文件:從中找到delete from test.tb1 where id=2這條語句
# cd /usr/local/mysql/data/
# mysqlbinlog -v mysql-bin.000002
從中能夠看出delete事件發生position是287,事件結束position是416
恢復流程:直接用bin-log日誌將數據庫恢復到刪除位置287前,而後跳過故障點,再進行恢復下面全部的操做,命令以下
因爲以前沒有作過全庫備份,因此要使用全部binlog日誌恢復,因此生產環境中須要很長時間恢復,導出相關binlog文件
#mysqlbinlog /usr/local/mysql/data/mysql-bin.000001 > /opt/mysql-bin.000001.sql
#mysqlbinlog --stop-position=287 /usr/local/mysql/data/mysql-bin.000002 > /opt/287.sql
#mysqlbinlog --start-position=416 /usr/local/mysql/data/mysql-bin.000002 > /opt/416.sql
接下來是見證奇蹟的時候到了;接下來往下看
刪除test數據庫
mysql>drop database test;
利用binlog恢復數據
#mysql -uroot -p< /opt/mysql-bin.000001.sql
#mysql -uroot -p< /opt/287.sql
# 恢復完成後,咱們檢查下表的數據是否完整
zhangsan用戶已經成功的恢復了,說明此次備份成功了,在這裏爲你們介紹幾個命令讓你們參考一下
mysqlbinlog 選項示例
常見的選項有如下幾個:
--start-datetime
從二進制日誌中讀取指定時間戳或者本地計算機時間以後的日誌事件。
--stop-datetime
從二進制日誌中讀取指定時間戳或者本地計算機時間以前的日誌事件。
--start-position
從二進制日誌中讀取指定position 事件位置做爲開始。
--stop-position
從二進制日誌中讀取指定position 事件位置做爲事件截至
剛纔咱們使用的mysqlbinlog記下來爲你們接單的介紹下;
語法格式: mysqlbinlog [options] log_file ...
輸出內容會因日誌文件的格式以及mysqlbinlog工具使用的選項不一樣而略不一樣。
mysqlbinlog的可用選項可參考man手冊。
二進制日誌文件的格式包含行模式、語句模式和混合模式(也即有服務器決定在什麼狀況下記錄什麼類型的日誌),基於語句的日誌中事件信息包含執行的語句等,基於行的日誌中事件信息包含的是行的變化信息等。混合模式的日誌中兩種類型的事件信息都會記錄。
爲了便於查看記錄了行變化信息的事件在當時具體執行了什麼樣的SQL語句可使用mysqlbinlog工具的-v(--verbose)選項,該選項會將行事件重構成被註釋掉的僞SQL語句,若是想看到更詳細的信息能夠將該選項給兩次如-vv,這樣能夠包含一些數據類型和元信息的註釋內容,如
先切換到binlog所在的目錄下
#mysqlbinlog mysql-bin.000001
#mysqlbinlog -v mysql-bin.000001
#mysqlbinlog -vv mysql-bin.000001
另外mysqlbinlog和能夠經過--read-from-remote-server選項從遠程服務器讀取二進制日誌文件,這時須要一些而外的鏈接參數,如-h,-P,-p,-u等,這些參數僅在指定了--read-from-remote-server後有效。
另外其餘的一些參數能夠經過mysqlbinlog --help查看若是看更詳細的可使用man手冊
2)mysqldump工具的介紹:
主要是用來備份和數據轉移的工具,主要產生一系列的sql語句,能夠分裝到文件,而分裝的這個文件主要用於重建數據庫所需的sql命令,能夠用來實現輕量級的快速遷移或恢復數據庫。mysqldump 是將數據表導成 SQL 腳本文件,在不一樣的 MySQL 版本之間升級時相對比較合適,這也是最經常使用的備份方法。
mysqldump主要用於數據量很小的時候能夠備份,當數據量龐大的時候就顯得力不存心了,就不建議使用mysqldump工具進行備份,後續會爲你們帶來新的備份工具。
mysqldump能夠針對單個表、多個表、單個數據庫、多個數據庫、全部數據庫進行導出的操做
#mysqldump [options] db_name [tbl_name ...] //導出指定數據庫或單個表
#mysqldump [options] --databases db_name ... //導出多個數據庫
#mysqldump [options] --all-databases //導出全部
mysqldump -uroot -p --flush-logs test > /opt/test.sql //--flush-logs這個選項就會完整備份的時候從新開啓一個新binlog
數據庫的導入
在前面咱們介紹了mysql的binlog和mysqldump工具,下面咱們來學習如何實現mysqldump全庫備份+binlog的數據恢復
環境準備與備份還原:
檢查開啓binlog
先建立一些原始數據
mysql> reset master;===========清除以前的全部二進制文件,而且生成一個新的二進制文件
mysql> create database test_db;===========建立一個test_db的庫
mysql> use test_db;==================進入test_db庫
mysql> create table tb1(id int primary key auto_increment,name varchar(20));=======建立tb1表
mysql> insert into tb1(name) values('tom1');==============在表中插入數據tom1
mysql> insert into tb1(name) values('tom2');==============在表中插入數據tom2
mysql> commit;===========完成
查看下錶中的內容:
前期準備工做已經就緒,如今開始進入備份的工做環節:
方案:mysqldump全庫備份+binlog還原
1、mysqldump備份方案:
每週一凌晨1點全庫備份
2、備份步驟
(1) 建立備份目錄
# mkdir /opt/mysqlbackup
# mkdir /opt/mysqlbackup/daily
(2)全庫備份
這裏咱們模擬週一的完整備份數據庫任務
#mysqldump -uroot -p --flush-logs test_db > /opt/mysqlbackup/test_db_2017_06_24.sql
[root@localhost data]# ls -l /opt/mysqlbackup/
-rw-r--r--. 1 root root 1871 Sep 13 21:06 test_db_2017_06_24.sql
備份mysqldump全庫備份以前的binlog日誌文(注:生產環境中可能不僅一個binlog文件)
# cp /usr/local/mysql/data/mysql-bin.000001 /opt/mysqlbackup/daily/
# mysql -uroot -p -e "purge binary logs to 'mysql_bin.000002'"
接下來模擬操做失誤,將數據修改錯誤:
mysql> insert into tb1(name) values('tom3');
mysql> commit;
備份自mysqldump以後的binlog日誌文件
上面的模擬的誤操做是刪除了id=1的記錄
(3)如今咱們使用mysqldump的全庫備份和binlog來恢復數據。
使用mysqldump的備份進行全庫恢復
# mysql -uroot -p test_db < /opt/mysqlbackup/test_db_2017_06_24.sql
查詢一下數據
[root@localhost ~]# mysql -uroot -p -e "select * from test_db.tb1"
從顯示結果能夠看到使用mysqldump備份將數據還原到了備份時的狀態,剛纔刪除的數據(id=2)恢復回來了,但備份後產生的數據卻丟失了(tom3)因此還得利用binlog進一步還原
由於刪除是在全庫備份後發生的,而mysqldump全庫備份時使用--flush-logs選項,因此只須要分析全庫備份後的binlog即mysql_bin.000002。
先查看下binlog的信息:
查看mysql-bin.000002中的事件,能夠看到有刪除事件
mysql> show binlog events in 'mysql_bin.000002';
使用mysqlbinlog 命令能夠查看備份的binlog文件的詳細事件。
恢復流程:咱們直接用bin-log日誌將數據庫恢復到刪除位置前,而後跳過故障點,再進行恢復刪除後的全部操做。
若是想看的在詳細點能夠經過
# mysqlbinlog -v /opt/mysqlbackup/daily/mysql_bin.000002語句查看,你們若是還不太瞭解,這裏能夠在演示一遍:
經過mysqlbinlog命令所顯示的結果能夠看到誤操做delete的開始postion爲219,結束position是422。
從二進制日誌中讀取指定position=219事件位置做爲截至,即把數據恢復到delete刪除前
# mysqlbinlog --stop-position=219 /opt/mysqlbackup/daily/mysql-bin.000002 | mysql -u root -p
從二進制日誌中讀取指定position=422事件位置做爲開始,即跳過刪除事件,恢復刪除事件以後對數據的正常操做
#mysqlbinlog --start-position=422 /opt/mysqlbackup/daily/mysql-bin.000002 | mysql -u root -p
查看恢復結果:
從上面顯示能夠看出數據恢復到正常狀態
爲咱們今天的mysql災難備份與恢復作個總結:
1)介紹了binlog日誌文件的做用,以及打開方式,另外裏面包括了咱們對數據庫的修改sql語句,它是以每個單獨的事件存儲在裏面的
2)mysqlbinlog工具,主要用來打開binlog日誌的工具,能夠查看更加詳細的信息經過-vv選項;另外也能夠給binlog日誌二進制文件進行備份
3)mysqldump工具;能夠用來備份二進制文件,但只適合少許的數據,龐大的數據量就不太適用了
4)其實恢復就是經過二進制文件查看到以前的命令,將刪除或者操做錯誤的命令的那一段事件跳過去而執行其餘沒有問題的sql語句。
生產環境中Mysql數據庫的備份是週期性重複的操做,因此一般是要編寫腳本實現,經過crond計劃任務週期性執行備份腳本,這是下次爲你們帶來的,有什麼不足但願你們多多指教