數據備份的重要性
在生產環境中，數據的安全性是至關重要的，任何數據的丟失都可能產生嚴重的後果
造成數據丟失的原因：
程序錯誤
人爲錯誤
計算機失敗
磁盤失敗
災難和偷竊數據庫備份的分類
物理備份：
對數據庫操作系統的物理文件(如數據文件，日誌文件等)的備份物理備份又分爲脫機備份（冷備份）和聯機備份（熱備份）
冷備份：是在關閉數據庫的時候進行的
熱備份：數據庫處於運行狀態，這種備份方法依賴於數據庫的日誌文件邏輯備份：
對數據庫邏輯組件（如表等數據庫對象）的備份從數據庫的備份策略角度，備份可分爲
完全備份：每次對數據進行完整的備份
差異備份：備份那些自從上次完全備份之後被修改過的文件
增量備份：只有那些在上次完全備份或者增量備份後被修改的文件纔會被備份MySQL完全備份
完全備份是對整個數據庫的備份，數據結構和文件結構的備份
完全備份保存的是備份完成時刻的數據庫
完全備份是增量備份的基礎完全備份的優點
備份與恢復操作簡單方便完全備份的缺點
數據存在大量的重複
佔用大量的備份空間
備份與恢復時間長mysqldump備份庫
MySQL數據庫的備份可以採用用多種方式
直接打包數據庫文件夾，如/usr/local/mysql/data
使用專用備份工具mysqldumpmysqldump命令
MySQL自帶的備份工具，相當方便對MySQL進行備份
通過該命令工具可以將指定的庫，表和全部的庫到處爲SQL腳本，在需要恢復時可進行數據恢復mysqldump命令對單個庫進行完全備份
mysqldump -u 用戶名 -p [密碼] [選項] [數據庫名] > /備份路徑/備份文件名單庫備份例子
mysqldump -u root -p auth > /backup/auth.sql
mysqldump -u root -p mysql > /backup/mysql.sqlmysqldump命令對多個庫進行完全備份
mysqldump -u 用戶名 -p [密碼] [選項] --database 庫名1 [庫名2]... > /備份路徑/備份文件名多庫備份例子
mysqldump -u root -p --databases auth mysql > /back/databases-auth-mysql.sql對所有庫進行完全備份
mysqldump -u 用戶名 -p [密碼] [選項] --all-databases > /備份路徑/備份文件名多有庫備份例子
mysqldump -u root -p --opt --all-databases > /backup/all-data.sql mysqldump備份表
在時間生產環境中，存在對某個特定表的維護操作，此時mysqldump同樣發揮重大作用
使用mysqldump備份表的操作
mysqldump -u 用戶名 -p [密碼] [選項] 數據庫名 表名 > /備份路徑/備份文件名備份表的例子
mysqldump -u root -p mysql user > /backup/mysql-user.sql恢復數據庫
使用mysqldump命令導出的SQL備份腳本，在進行數據恢復時可使用一下方法導入
source命令
mysql命令使用source恢復數據庫的步驟
登錄到MySQL數據庫
執行source備份sql腳本的路徑source恢復例子
MySQL [(none)]> source /backup/all-data.sql使用mysql命令恢復數據
mysql -u 用戶名 -p [密碼] < 庫備份腳本的路徑mysql命令恢復例子
mysql -u root -p < /backup/all-data.sql恢復表的操作
恢復表時同樣可以使用source或者mysql命令進行
source恢復表的操作與恢復庫的操作相同
當備份文件中只包含表的備份，而不包括創建庫的語句時，必須制定庫名，且目標庫必須存在
mysql -u 用戶名 -p [密碼] < 表備份腳本的路徑
mysql -u root -p mysql < /backup/mysql-user.sql在生產環境中，可以使用shell腳本自動實現定期備份
MySQL備份思路
定期實施備份，制定備份計劃或者策略，並嚴格遵守
除了進行完全備份，開啓MySQL服務器的日誌功能時很重要的
完全備份加上日誌，可以對MySQL進行最大化的還原使用同一的和易理解的備份文件名稱
推薦使用庫名或者表名加上時間的命名規則MySQL增量備份
使用mysqldump進行完全備份的存在的問題
備份數據中有重複數據
備份時間與恢復時間長增量備份就是備份自上一次備份之後增加或變化的文件或者內容
增量備份的特點：
沒有重複數據，備份量不大，時間短
恢復麻煩：需要上次完全備份及完全備份之後所有的增量備份才能恢復，而且要對所有增量備份進行逐個反推恢復MySQL沒有提供直接的增量備份方法
可以通過MySQL提供的二進制日誌(binary logs)間接實現增量備份
MySQL二進制日誌對備份的意義：
二進制日誌保存了所有更新或者可能更新數據庫的操作
二進制日誌在啓動MySQL服務器後開始記錄，並在文件達到max_ binlog_size所設置的大小或者接收到flush logs命令後重新創建新的日誌文件
只需定時執行flush logs方法重新創建新的日誌，生成二進制文件序列，並及時把這些舊的日誌保存到安全的地方就完成了一個時間段的增量備份
MySQL數據庫增量恢復
一般恢復：
基於位置恢復：
就是將某個起始時間的二進制日誌導入數據庫中，從而跳過某個發生錯誤的時間點實現數據的恢復基於時間點恢復
使用基於時間點的恢復，可能會出現在一個時間點裏既同時存在正確的操作又存在錯誤的操作，所以我們需要一種更爲精確的恢復方式增量恢復的方法
一般恢復：
mysqlbinlog [--no-defaults]增量備份文件 | mysql -u用戶名 -p基於位置的恢復：
恢復數據到指定位置
mysqlbinlog --stop-position=操作'id' 1進制日誌 | mysql -u用戶名 -p 密碼從指定的位置開始恢復數據
mysqlbinlog --start-position=操作'id'二進制日誌 | mysql -u用戶名 -p 密碼基於時間點的恢復：
從日誌開頭截止到某個時間點的恢復
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 密碼查看二進制日誌文件（解碼）
mysqlbinlog --no-defaults --base64-output=decode-rows -V mysql-bin.000002 > /opt/ bak. txt