一：備份的類型
1.1按數據庫服務器的狀態
1.2按備份文件的類型
1.3備份數據庫的內容
二：備份策略
2.1備份應該備份什麼？
2.2物理備份還是邏輯備份？
2.3備份策略
三：MySQL備份工具
3.1 mysqldump
3.2 mysqlhotcopy
3.3 ibackup
3.4 xtrabackup
1.1按數據庫服務器的狀態
熱備份：在線備份，讀寫操作不受影響
溫備份：能讀不能寫，僅能執行讀操作
冷備份：離線備份，讀寫操作都不能進行
1.2按備份文件的類型
物理備份：直接備份數據文件
邏輯備份：將數據導出到文本文件中
1.3備份數據庫的內容
完全備份：備份全部數據，可能是某個庫的全部數據，也可能是所有庫的全部數據
增量備份：僅備份上次完全備份或增量備份以後變化的數據
差異備份：僅備份上次完全備份以後變化的數據
2.1備份應該備份什麼？
數據、配置文件、二進制日誌、事務日誌
2.2物理備份還是邏輯備份？
物理備份：速度快
邏輯備份：速度慢、丟失浮點數精度、可以方便使用文本處理工具直接對其處理、可移植能力好、跨MySQL服務器版本
2.3備份策略
根據數據量的大小，可以做不同的選擇，例如：一週一次完全，一天一次增量或差異或者一個月一次完全備份，一天一次增量或者差異備份
完全+增量
完全+差異
3.1mysqldump邏輯備份工具、MyISAM(溫備份)、InnoDB(熱備份)
3.1.1備份單個數據庫或庫中的特定表
db_name[tb1][tb2]：備份指定數據庫，不包括創建數據庫的命令，所以恢復的時候必須手動的創建數據庫
mysqldump -uroot -p mydb > /root/mydb.sql
注意：以上的方式是在MySQL服務器運行期間執行的備份，如果在備份的過程中有數據插入，會導致數據的不一致。所以在備份的時候一定要鎖表
注意：最後一條數據沒有在備份文件中，所以如要要拿剛纔的備份文件去恢復，是不能夠恢復到服務器出事故之前的狀態的，但是可以去二進制日誌文件中查找讀出來，但是到二進制日誌文件中查找的時候，怎麼知道剛纔插入數據的時間點呢？還原的時候應該是完全備份+完全備份以後的事件進行恢復，但是怎麼知道二進制日誌文件當中剛纔從哪個事件開始的？或者說哪個位置？哪個時間點？而且每次還得手動記錄存放於哪個二進制日誌文件中。
3.1.2 --master-date={0|1|2}
0表示不記錄二進制日誌文件及其事件位置
1表示以CHANGE MASTER TO 的方式記錄二進制日誌文件位置，可用於恢復後直接啓動服務器
2表示以CHANGE MASTER TO的方式記錄二進制日誌文件位置，但是默認被註釋掉了
3.1.3--lock-all-tables：鎖定所有表
3.1.4--flush-logs：執行日誌滾動
3.1.5如果指定庫中的表類型都爲InnoDB，可使用--single-transaction啓動熱備，使用它的時候就不需要在使用--lock-all-tables選項了，它會自動釋加鎖
3.1.6備份多個庫
--all-databases：備份所有庫
--databases DB_NAME1,DB_NAME2...：備份指定庫
注：這兩個選項都會自動創建CREATEDATABASE命令，所以還原的時候就不用在手動指定庫了
3.1.7其它選項
--event：備份數據庫的事件調度器
--routines：備份存儲過程和存儲函數
--triggers：備份觸發器
3.1.8執行備份與還原
備份策略：周完全+日增量
完全備份：mysql>mysqldump
增量備份：備份二進制日誌文件（flush logs）
模擬完全備份，然後每天備份增量
1.假如現在是第一次執行mydb數據庫的完全備份
2.執行完完全備份以後，進入數據庫做一些操作，模擬這些操作是在第二天用戶做的
3.然後模擬執行第二天的增量備份
4.mysql-bin.000019是第一天的增量
5.模擬到了第二天了，增加了一些信息
6.假如一不小心把整個數據庫給刪了，假如二進制日誌文件和數據沒放到同一目錄下
7.關閉mysql服務，初始化數據庫，啓動mysql服務
8.開始使用備份文件進行數據庫恢復
注意：此時還沒有恢復到數據庫出事故前一刻的狀態，需要執行數據庫出事故前一刻的二進制日誌文件進行最終的恢復
mysqldump -uroot -p --master-data=2 --flush-logs --all-databases --single-transaction --events --ignore-table=mysql.evnets > /root/full_database.sql