1.一般使用的是mysqldump來進行備份，每次dump的數據是1000條，並且在這個過程中會進行鎖表。
(這種方式是邏輯備份，即直接將數據庫中的數據導成sql語句進行備份的過程)
主要的使用方法：
(1).不帶參數的進行備份：
1 備份test數據庫中的所有表數據和表結構 2 mysqldump -uroot -ppassword test >/tmp/test.sql 3 4 備份test數據庫中的某個表數據和表結構 5 mysqldump -uroot -ppassword test student >/tmp/test_student.sql
(2).使用-B參數進行備份：（在SQL文件中自動創建原有的數據庫名和連接數據庫）
1 備份test數據庫中的所有表數據和表結構 2 3 使用-B會自動的創建數據庫並且使用數據庫 4 5 mysqldump -uroot -ppassword -B test >/tmp/test.sql
(3).使用-B參數進行多個數據庫的備份：
1 mysqldump --user root --password=myrootpassword -B db_test db_second db_third > db_test.sql
(4).使用gzip進行壓縮數據文件進行備份：(使用管道符將數據傳給gzip然后進行壓縮數據成gz的包)
1 mysqldump --user root --password=myrootpassword -B db_test db_second db_third |gzip > db_test.sql.gz
(5).使用shell進行分庫備份：
1 mysql -uroot -ppasswd -e "show databases;" |grep -Eiv "database|information|performance"|sed -r 's#^([a-zA-Z_0-9]*$)#mysql -uroot -ppasswd --events -B \1 |gzip> /opt/\1.sql.gz#g'|bash
上面的命令是將mysql中需要的庫進行了分庫的備份，這種是在遇到比較多的庫的時候，我們可以進行分庫的備份。
分庫的意義何在：
有時一個企業的數據庫中會有多個庫，例如（bbs，www，blog），但是出問題的時候很可能往往是一個庫，那如果我們將所有庫的數據保存到一個文件中去，那么將來恢復數據的時候，可能會帶來很大的麻煩，所以我們一般將庫進行分庫備份。
有的時候我們也需要將某個庫中的多個表進行分別編程，思想也是和上面的分庫備份一致的。
(6).備份mysql數據庫的表結構（不包含數據）
1 mysqldump -uroot -ppassword -d test 2 3 參數 -d 的作用就是備份數據庫的表結構。
(7).備份mysql的數據庫中的數據（不包含表結構）
1 mysqldump -uroot -ppassword -t test 2 3 參數 -t 的作用就是備份數據庫的表數據（不包含表結構）。
(8).備份的時候切割binlog日志：（進行增量備份的時候可以用到）
1 mysqldump -uroot -ppassword -t -B -F test 2 3 參數 -F 的作用就是備份數據庫的時候，將binlog日志進行重新刷新。
(9).備份的時候會記錄指定文件的位置以及mysqlbinglog的文件名稱：
1 mysqldump -uroot -ppassword -t -B -F --master-data test 2 3 參數 --master-data=1 的作用就是備份數據庫的時候，將binlog日志進行重新刷新。
mysqldump的一些關鍵參數總結：
1、-B：表示的是指定多個庫，增加了建庫語句和use數據庫的語句。
2、--compact：去掉注釋，適合調試輸出，不適合在生產環境使用。
3、-A： 表示的是本分所有的庫。
4、-F：刷新binlog日志，方便進行增量的恢復。
5、--master-data：增加binlog日志文件名及其對應的位置點。
6、-x，--lock-all-tables ：在備份的時候進行鎖表，保持數據的一致性。
7、-d：只備份表的結構。
8、--single-transaction 適合innodb數據庫的備份。
Innodb表在備份的時候，通常啟用選項--single-transaction 來保證備份的一致性，實際上他的工作原理是設定本次備份的會話級別為：repeattable read ，以確保本次會話dump時，不會看到其他的會話提交了數據。
對於不同的引擎，表的備份數據：
MyISAM:
1 mysqldump -uroot -ppassword --flush-privileges -A -B --master-data=2 -x --flush-logs --triggers --routines --events --hex-blob |gzip > /opt/all.sql.gz
InnoDB:
1 mysqldump -uroot -ppassword --flush-privileges -A -B --master-data=2 --single-transaction --flush-logs --triggers --routines --events --hex-blob |gzip > /opt/all.sql.gz
推薦使用InnoDB的備份方式，備份數據。(--triggers 表示的是觸發器)
企業場景全量和增量的頻率是怎樣做的呢？
1）中小公司，全量一般是每天一次，業務流量低谷執行的是全備，備份時會鎖表。
2）單台數據庫，如和增量。使用rsync（配合定時任務頻率大點或者inotify，主從復制），把所有的binlog備份到遠程服務器，盡量做主從復制。
3）大公司周備，每周六00點一次全量，下周日-下周六00點前都是增量。
優點：節省備份時間，減小備份壓力。缺點：增量的binlog文件副本太多，還原會很麻煩
4）一主五從，會有一個從庫做備份，延遲同步。
什么情況下會用到備份呢？
1) 需要升級數據庫或者是需要增加一個從庫的時候。
2）主庫或者從庫宕機，需要數據的備份。
3）人為的DDl或者是DML的語句，導致主從庫的數據消失
4）跨機房的災備，需要備份數據到遠端程序。
什么情況下才會用到增量恢復呢？
1）主或者從庫宕機（硬件損壞）是否需要增量恢復？
答：不需要增量恢復，主庫宕機，只需要把其中的一個同步最快的從庫提升為主庫即可。
主庫宕機，只要選擇更新最快的從庫，提升為主庫即可
從庫宕機，直接不用就好了（一般都會陪LVS負載均衡），或者就正常修復即可
2）人為操作數據庫SQL語句破壞主庫是否需要增量恢復？
在數據庫主庫內部命令行進行誤操作，會導致所有的數據庫（包括主從庫）的數據丟失，例如：在主庫執行了drop database test這樣的刪除語句，這時候所有的從庫也會執行這個drop語句，從而導致所有的數據庫上的數據庫的數據丟失，這樣的場景下面需要進行增量恢復的。
3）只有一個主庫是否需要增量恢復呢？
如果公司只有一個主庫的情況下，首先應該做定時的全量備份（每天一次）以及增量備份（每隔1-10分鍾對binlog日志做切割然后被分到其他的服務器上，或者本地其他硬盤中）或者寫到網絡文件系統中。
使用binlog進行增量備份以及查看文件數據的方法：
1 /data1/mysql/bin/mysqlbinlog -uroot -psina.com mysql-bin.000068 > bin.sql 2 3 我們也可以同時進行拆庫的分析，使用-d參數即可指定數據庫進行拆分 4 /data1/mysql/bin/mysqlbinlog -uroot -psina.com -d test mysql-bin.000068 > bin.sql
是可以導成SQL語句進行查看的。
增量恢復的前提：
1）人為的SQL造成的誤操作。
2）需要全備和增量的數據。
3）恢復時建議對外停止更新。
4）恢復的時候，先恢復全量，再把增量日志中有問題的SQL語句刪除，然后恢復到數據庫。
增量恢復的核心思想：
1）流程制度的控制。如果不做，面臨服務和數據，魚和熊掌不可得。
2）延遲備份來解決，通過監控，加白名單的方式進行控制。
3）業務需求的容忍度，可量化的目標，根據需求選擇停庫或鎖表或者容忍丟失部分數據。