一、數據備份的重要性
在生產環境中,數據的安全性是至關重要的,任何數據的丟失都可能產生嚴重的後果
生產環境中,可以使用shell腳本自動實現定期備份
造成數據丟失的原因:
- 程序錯誤(系統錯誤)
- 人爲錯誤(人爲誤操作等)
- 計算機失敗(比如事務未提交,突然斷電)
- 磁盤失敗(存儲方式——文件系統(分佈式存儲)——備份(比如銀行))
- 災難(如火災、地震)和偷竊
二、數據庫備份的分類
1、從物理與邏輯的角度,備份可以分爲
- 物理備份:對數據庫操作系統的物理文件(如數據文件、日誌文件等)的備份
- 物理備份又可以分爲脫機備份(冷備份)和聯機備份(熱備份)
- 冷備份:是在關閉數據庫的時候進行的
- 熱備份:數據庫處於運行狀態,這種備份方法依賴於數據庫的日誌文件
- 物理備份又可以分爲脫機備份(冷備份)和聯機備份(熱備份)
- 邏輯備份:對數據庫邏輯組件(如表等數據庫對象)的備份
物理備份示例:
#先創建表
#壓縮備份
&(date +%F) 表示已當前日期格式爲結尾
2、從數據庫的備份策略角度,備份可分爲
- 完全備份:每次對數據進行完整的備份
- 優點:安全
- 缺點:冗餘數據太多(重複數據多,佔磁盤),空間利用率不高
- 差異備份:備份那些從上次完全備份之後被修改過的文件(差異備份依賴於完全備份)
- 優點:比完全備份效率高
- 缺點:也會存在數據冗餘
- 適用:比較折中的場景
- 增量備份:只有那些在上次完全備份或者增量備份後被修改的文件纔會被備份
- 優點:效率高,空間利用率高
- 缺點:安全性低
差異備份與增量備份差異:
三、MySQL備份思路
-
定期實施備份,制定備份計劃或者策略,並嚴格遵守
-
除了進行完全備份,開啓MySQL服務器的日誌功能是很重要的
- 完全備份加上日誌,可以對MySQL進行最大化還原
-
使用統一的和易理解的備份文件名稱
- 不要使用backup1、backup2等這樣沒有意義的名字
- 推薦使用庫名或者表名 加上時間的命名規則
完全備份
一、MySQL完全備份
完全備份是對整個數據庫的備份、數據庫結構和文件結構的備份
完全備份保存的是備份完成時刻的數據庫
完全備份是增量備份的基礎
完全備份的優點:
備份與恢復操作簡單方便
完全備份的缺點:
數據存在大量的重複
佔用大量的備份空間
備份與恢復時間長
二、mysqldump備份庫
MySQL數據庫的備份可以採用用多種方式
-
直接打包數據庫文件夾,如/usr/local/mysql/data
-
使用專用備份工具mysqldump
mysqldump命令
-
MySQL自帶的備份工具,相當方便對MySQL進行備份
-
通過該命令工具可以將指定的庫、表或全部的庫導出爲SQL腳本,在需要恢復時可進行數據恢復
1、mysqldump命令對單個庫進行完全備份
mysqldump -u 用戶名 -p [密碼][選項][數據庫名] > /備份路徑/備份文件名
單庫備份示例
2、mysqldump命令對多個庫進行完全備份
mysqldump -u 用戶名 -p [密碼][選項]--databases 庫名1 [庫名2]… > /備份路徑/備份文件名
多庫備份示例
3、mysqldump命令對所有庫進行完全備份
–opt 固定語法
mysqldump -u 用戶名 -p [密碼][選項] --all-databases > /備份路徑/備份文件名
所有庫備份示例
三、mysqldump備份表
在實際生產環境中,存在對某個特定表的維護操作,此時mysqldump同樣發揮重大作用
1、mysqldump命令備份表操作
mysqldump -u 用戶名 -p [密碼][選項] 數據庫名 表名 > /備份路徑/備份文件名
備份表示例
2、mysqldump命令備份表結構操作
-d 就是describe顯示錶結構 首字母
mysqldump -u 用戶名 -p [密碼][選項] -d 數據庫名 表名 > /備份路徑/備份文件名
備份表結構示例
四、完全恢復
#模擬刪除表
1、數據庫恢復
使用mysqldumo命令到處的SQL備份腳本,在進行數據恢復時可使用以下方法導入
- source命令(mysql內操作)
- mysql命令(linux內操作)
1)使用source恢復數據庫
-
登陸到mysql數據庫
-
執行source 備份sql腳本的路徑(絕對路徑)
source <庫備份sql腳本的路徑>
-
source恢復示例
模擬刪除:
恢復
2)使用mysql命令恢復數據庫
-
在linux操作界面
-
使用命令
mysql -u 用戶名 -p [密碼] < 庫備份腳本的路徑>
-
mysql命令恢復示例
模擬刪除
恢復
2、數據表恢復
-
恢復表時同樣可以使用source或者mysql命令進行
-
source恢復表的操作與恢復庫的操作相同
-
當備份文件中只包含表的備份,而不包括創建庫的語句時,必須指定庫名,且目標庫必須存在
mysql -u 用戶名 -p [密碼] < 表備份腳本的路徑
恢復表示例:source
模擬刪除表
恢復
恢復表示例:mysql
模擬刪除表
恢復
增量備份
一、MySQL增量備份
1、使用mysqldump進行完全備份的存在的問題
- 備份數據中有重複數據
- 備份時間與恢復時間長
2、增量備份就是備份自上次備份之後增加或變化的文件或者內容
3、增量備份的特點
- 沒有重複數據,備份量不大,時間短(優點)
- 恢復麻煩(缺點):需要上次完全備份及完全備份之後所有的增量備份才能恢復,而且要對所有增量備份進行逐個反推恢復
4、MySQL沒有提供直接的增量備份方法
5、可以通過MySQL提供的二進制日誌(binary logs)間接實現增量備份
6、MySQL二進制日誌對備份的意義
- 二進制日誌保存了所有更新或者可能更新數據庫的操作
- 二進制日誌在啓動MySQL服務器後開始記錄,並在文件達到 max_binlog_size所設置的大小或者接收到fush logs命令後重新創建新的日誌文件
- 只需定時執行flush logs方法重新創建新的日誌,生成二進制文件序列,並及時把這些舊的日誌保存到安全的地方就完成了一個時間段的增量備份
備份示例
#開啓二進制日誌功能:vim /etc/my.cnf 並重啓服務
log-bin=是固定格式
mysql-bin 是自定義的名字( 日誌文件名字就是mysql-bin.000001等等)
#這時會產生日誌文件,但目前裏面是空的,還沒有操作記錄
#執行完整備份(增量備份是基於完整備份或增量備份之上的備份)
#執行增量備份
刷新,創建新的增量備份日誌文件 0002
0001文件存放的時之前操作的內容
0002文件是存放下面即將操作的內容
#進入庫中模擬操作及誤刪除
#創建新的增量備份日誌文件(0003)
#之前的模擬操作及誤刪除都寫到0002日誌文件中了(看日誌文件,操作記錄是亂碼)
#所以使用64位解碼器輸出並且按行讀取顯示 生成到文件中
mysqlbinlog --no-defaults --base64-output=decode-rows -v mysql-bin.000002 > /opt/bak.txt
#查看解碼出來的日誌文件,文件中有操作過的3條語句
二、MySQL數據庫增量恢復
-
一般恢復
-
斷點恢復
- 基於位置恢復
- 就是將某個起始時間的二進制日誌導入數據庫中,從而跳過某個發生錯誤的時間點實現數據的恢復
- 基於時間點恢復
- 使用基於時間點的恢復 ,可能會出現在一個時間點裏既同時存在正確的操作又存在錯誤的操作,所以我們需要一種更爲精確的恢復方式
- 基於位置恢復
1、一般恢復
mysqlbinlog [--no-defaults] 增量備份日誌文件 | mysql -u 用戶名 -p
模擬刪除:
先執行完整性恢復:
在執行一般恢復:
2、斷點恢復
#模擬刪除
#執行完整性恢復
1)基於位置的恢復
-
恢復數據到指定位置
mysqlbinlog [--no-defaults] --stop-position='操作id'二進制日誌 | mysql -u 用戶名 -p 密碼
-
從指定的位置開始恢復數據
mysqlbinlog [--no-defaults] --start-position='操作id'二進制日誌 | mysql -u 用戶名 -p 密碼
2)基於時間點的恢復
-
從日誌開頭截止到某個時間點的恢復
mysqlbinlog [--no-defaults] --stop-datetime='年-月-日 小時:分鐘:秒' 二進制日誌 | mysql -u 用戶名 -p 密碼
-
從某個時間點到日誌結尾的恢復
mysqlbinlog [--no-defaults] --start-datetime='年-月-日 小時:分鐘:秒' 二進制日誌 | mysql -u 用戶名 -p 密碼
-
從某個時間點到某個時間點的恢復
mysqlbinlog [--no-defaults] --start-datetime='年-月-日 小時:分鐘:秒' --stop-datetime='年-月-日 小時:分鐘:秒' 二進制日誌 | mysql -u 用戶名 -p 密碼