原文地址：http://www.zsythink.net/archives/1450
mysqldump是mysql自帶的邏輯備份工具。它的備份原理是，通過協議連接到mysql數據庫，將需要備份的數據查詢出來，將查詢出的數據轉換成對應的insert語句，當我們需要還原這些數據時，只要執行這些insert語句，即可將對應的數據還原。
mysqldump的優點：
可以直接使用文本處理工具處理對應的備份數據，因為備份數據已經被mysqldump轉換為了對應的insert語句，所以，我們可以借助文件系統中的文本處理工具對備份數據進行直接處理。
mysqldump的缺點：
當數據為浮點類型時，會出現精度丟失
mysqldump的備份過程屬於邏輯備份，備份速度、恢復速度與物理備份工具相比較慢，而且mysqldump備份的過程是串行化的，不會並行的進行備份，如果想要並行備份，可以使用mydumper，但是此處我們不考慮這些，只考慮mysqldump，當數據量較大時，一般不會使用mysqldump進行備份，因為效率較低。
mysqldump對innodb存儲引擎支持熱備，innodb支持事務，我們可以基於事務通過mysqldump對數據庫進行熱備。mysqldump對myisam存儲引擎只支持溫備，通過mysqldump對使用myisam存儲引擎的表進行備份時，最多只能實現溫備，因為在備份時會對備份的表請求鎖，當備份完成后，鎖會被釋放。
我們先通過一些最簡單的實驗，來了解一下mysqldump，但是這些操作過於簡陋，不足以滿足我們的備份需求，備份的數據也有可能出現問題，所以不要使用簡單示例中的語句進行備份，我們只是通過它們去了解mysqldump命令罷了，等我們掌握了它，再總結一些實用的備份命令，
簡單示例：
假設，我們現在想要通過mysqldump備份zsythink數據庫，那么，我們可以通過如下mysqldump命令：
mysqldump -u用戶 -h localhost 數據庫 -p數據庫密碼
該條命令執行后會將備份過程中創建的sql語句打印到終端，但是執行完后並不會實現備份效果。我們可以將打印出來的sql輸出到sql文件內，這就是基本的msyql邏輯備份
mysqldump -u用戶 -h localhost 數據庫 -p數據庫密碼 > /tmp/db.sql
但是，細心如你一定發現了，此sql腳本中並不包含任何創建數據庫的語句，只有創建表的語句，也就是說，在還原時，必須先確保對應的數據庫已經存在，那么，我們能不能再備份時就生成創建庫的語句呢？必須的額，使用--databases選項指定數據庫，即可在備份時生成創建數據庫的語句，
示例如下。
mysqldump -u用戶 -h localhost --databases 數據庫 -p數據庫密碼 > /tmp/db.sql
那么，我們能不能只備份數據庫中的某張表呢？能不能同時備份指定的多張表呢？能不能一次備份多個數據庫呢？必須能啊，只要我們靈活的運用一些選項即可，總結如下。使用如下語句備份zsythink數據庫中的所有表，但是不會生成創建zsythink數據庫的語句，只是備份其中的表（包括創建表的語句和數據）。
mysqldump -uroot -h192.168.1.146 zsythink -p
使用如下語句備份zsythink數據庫中指定的表，下例中只會備份zsythink數據庫中的t1、t2、t3表，其他表不會備份，也不會生成創建zsythink數據庫的語句（但是對應的表的創建語句會生成，表數據會備份）。
mysqldump -uroot -h192.168.1.146 zsythink t1 t2 t3 -p
使用如下語句備份zsythink整個數據庫，包括其中的所有表，並且會生成創建zsythink數據庫的語句。
mysqldump -uroot -h192.168.1.146 --databases zsythink -p
使用如下語句備份指定的多個數據庫，所有被指定的數據庫中的表都會被備份，對應的創建庫的語句也會生成，下例表示同時備份zsythink庫與test庫。
mysqldump -uroot -h192.168.1.146 --databases zsythink test -p
使用如下語句備份當前數據庫服務中的所有庫。
mysqldump -uroot -h192.168.1.146 --all-databases -p
其實，在某些時候，我們只是想要將數據庫的表結構備份出來，不想備份數據，以便創建一個完全相同的干凈數據庫，那么我們可以使用如下語句備份數據庫的所有表結構，如下命令表示備份zsythink數據庫中的所有表的表結構，不包含表數據，不包含創建庫的語句，只有創建表的語句，如下命令的"-d"選項可使用"--no-data"代替，他們效果完全相同。
mysqldump -uroot -hlocalhost -d zsythink -p
如下命令表示備份zsythink數據庫中test表的表結構，不包含表數據，不包含創建庫的語句，只有創建test表的語句。
mysqldump -uroot -hlocalhost -d zsythink test -p
常用的選項：
--master-data
在實際進行數據恢復時，往往需要進行時間點還原，通常的做法是先通過最近一次的備份，將數據恢復到備份時的樣子，然后再通過二進制日志，將備份之后的更改操作重放一遍，這樣就將數據恢復成了最近的模樣，比如，備份開始時，二進制日志對應的position為123，那么我們在進行時間點還原時，則需要先通過"備份文件"將數據恢復為備份時的樣子，然后再通過二進制日志文件，將position 123之后的所有操作重放一遍。但是，在還原時，我們怎么知道備份時position的值呢？沒錯，我們必須在備份時就做好標記，在恢復時才知道應該從哪里重放。否則在恢復時，我們則無法獲取到重放二進制日志的起始點位置。
其實，備份時二進制日志文件的position非常重要，對於主從復制結構來說，我們同樣需要用到它，如果，你的數據庫已經運行了一段時間，里面已經存在了一些數據，而此時，你想要將數據庫架構從單機架構改為主從架構，你想把當前的主機作為主服務器，然后再新加入一台服務器作為從服務器，那么，一般的做法是將主庫中的數據先備份一份出來，然后導入到從庫中，但是，當你從主庫中備份數據時，往往是熱備的，也就是說，備份完成后，有一些操作只在主庫中完成了，而備份中卻不存在這些數據，所以，我們使用備份在從庫中將數據還原以后，還要告訴"從庫"，將備份之后的操作從"主庫"那邊同步過來，但是，我們怎么知道從哪里開始同步呢？沒錯，我們必須在備份的時候就記住它的position，以便告訴從庫，從哪里開始同步。其實，這與我們手動重放二進制日志時的場景並沒有什么不同，它們的最終目的都是要確定通過備份還原數據以后，要從哪個位置開始執行之后的"重放"或"同步"操作。
--master-data選項有3個可用值，0、 1 、2，這三個值分別表示不同的含義
此值為0：
表示在使用mysqldump進行備份時，不記錄對應二進制日志文件位置，將此值顯式的設置為0與不使用此選項的效果相同。
此值為1：
表示在使用mysqldump進行備份時，記錄對應二進制日志文件位置，此值為默認值，也就是說，使用--master-data與使用--master-data=1的效果相同，如果將此選項的值設置為1，則會在備份文件中生成對應的"CHANGE MASTER TO"語句，此語句中標明了備份開始時二進制日志的前綴名以及其所處的position(位置)，生成此語句的目的是，在主從復制結構中的"從服務器"中通過備份sql還原數據以后，告訴"從庫"，從"主庫"的二進制日志文件中的哪個位置開始"同步"。如果我們沒有使用主從復制結構，同時又想要在備份時記錄二進制日志文件的position，則可以將此選項的值設置為2。
此值為2：
表示在使用mysqldump進行備份時，記錄對應二進制日值文件的位置，如果將此選項的值設置為2，則會在備份文件中生成對應的"CHANGE MASTER TO"語句，此語句中標明了備份開始時二進制日志的前綴名以及其所處的position(位置)，但是"CHANGE MASTER TO"語句將會被注釋，與此值為1時不同，此選項值為1時，"CHANGE MASTER TO"語句不會被注釋，此選項值為2時，"CHANGE MASTER TO"語句會被注釋，所以，如果只是單純的為了記錄備份時的二進制日志文件位置，那么將此選項值設置為2即可。
--flush-logs
我們再來想另外一個問題，如果，我們將二進制日志的大小設置為600兆，那么，每當二進制日志的大小滿600兆，對應的二進制日志文件就會發生滾動，生成一個新的二進制文件，並將原來的600兆保存，假設，我們使用mysqldump對數據庫進行備份的那一刻，對應binlog的大小為300兆，也就是說，備份操作開始時，二進制日志文件的position的位置則會處於文件居中的位置，那么，當我們想要找到對應position進行重放時，此位置之前的操作記錄對於我們來說都是"無用"的，可是比較尷尬的是，我們還必須找到此位置，這樣就會產生一些"多余的工作量"，那么我們能不能直接避免這種情況的發生呢？必須的，勞動人民的智慧是無窮的，聰明如你一定想到了，使用一個選項就能搞定，沒錯，就是一個選項，它就是--flush-logs選項，當我們使用mysqldump進行備份時，如果使用了此選項，備份開始時就會滾動一次二進制日志，無論二進制日志對應的文件大小是否達到600兆，都會滾動，這樣，我們就能在對應的二進制日志文件的開頭部分開始重放日志了。
其他常用選項
我們說過，備份的最終目的是"還原"，而只備份表中的數據，往往是不夠的，因為在數據庫中，可能還存在一些存儲過程和存儲函數、存在一些觸發器、事件表，這些"東西"也需要備份，以免最終的備份"不全"，在恢復的時候就"懵逼"了，那么，我們來看一些其他的常用的選項，總結如下。
--routines選項：表示備份時，存儲過程和存儲函數也會被備份。
--triggers選項：表示備份時，觸發器會被備份。-
-events選項：表示備份時，事件表會被備份。
不同存儲引擎下的備份
我們還需要考慮一個問題，如果我們要備份數據，我們一定要保證備份出的數據的可用性，如果備份后的數據在恢復以后，無法正常使用，那么備份出的數據也就失去了備份的意義，數據可用的前提就是數據的正確性、完整性、一致性。而不同的存儲引擎，滿足一致性時所使用的方法不同
表類型為innodb
我們說過，mysqldump支持對innodb存儲引擎進行熱備，熱備的概念我們已經提到過，所謂熱備，就是在備份的時候能夠對數據庫進行讀寫，但是，如果在備份時對數據庫進行讀寫，怎樣保證數據的一致性呢？沒錯，之前的文章已經詳細解釋過，如果表類型為innodb，基於"可重讀"事務，即可保證熱備出的數據的一致性。
在備份innodb存儲引擎的表時，如果使用了--single-transaction選項，mysqldump會自動開啟一個"可重讀"的事務，基於這個獨立的"事務"，備份出一個滿足一致性的數據備份。
mysqldump自動將備份會話中的事務隔離級別設置為了"可重讀"，並且開啟了一個事務，而且，開始事務時，使用了"WITH CONSISTENT SNAPSHOT"，表示事務開始的那一刻，同時創建了快照，以保證備份事務中的"一致性讀"。
表類型為myisam
如果你數據庫中的表使用了myisam存儲引擎，那么，在備份時最多只能達到溫備的程度，因為myisam存儲引擎不支持事務，即使我們使用--single-transaction選項對myisam表進行備份，也不會有任何作用，我們只能通過鎖表的方式進行，即在備份開始到備份結束期間，備份的表會被加上讀鎖，以保證數據的一致性，但是如果你的mysql環境是主從環境，則可以在從服務器上進行備份操作，此處不考慮那么多，我們只要記住，對myisam表進行備份時，需要加鎖以保證數據一致性即可。
對所有數據備份時，可以使用--lock-all-tables選項，對所有庫的所有表加讀鎖，--lock-all-tables對應的短選項為-x，而且，此選項與--single-transaction選項不能同時存在，示例如下。
mysqldump -uroot -h192.168.1.146 --lock-all-tables --all-databases -p > dbbackup.sql
對指定的數據庫進行備份時，可以使用--lock-tables選項，對指定庫的所有表加鎖，--lock-tables對應的短選項為-l，注意，此選項與--single-transaction選項同時存在時，此選項將失效，示例如下
mysqldump -uroot -h192.168.1.146 --lock-tables --databases zsythink -p > zsythink.sql
當然，我們也可以使用上述語句對innodb存儲引擎的表進行備份，不過這樣就不是熱備了，而是溫備。
常用情景：
表使用innodb存儲引擎時常用的備份語句：
如果未開啟二進制日志，備份指定的zsythink數據庫，可以使用如下語句。
mysqldump -uroot -h192.168.1.146 --single-transaction --routines --triggers --events --databases zsythink -p > zsythink.sql
在開啟二進制日志的情況下，備份指定的zsythink數據庫，通常使用如下語句。
mysqldump -uroot -h192.168.1.146 --flush-logs --master-data=2 --single-transaction --routines --triggers --events --databases zsythink -p > zsythink.sql
在開啟二進制日志的情況下，備份所有數據庫，通常使用如下語句。
mysqldump -uroot -h192.168.1.146 --flush-logs --master-data=2 --single-transaction --routines --triggers --events --all-databases -p > dbbackup.sql
表使用myisam存儲引擎時常用的備份語句：
如果未開啟二進制日志，備份指定的zsythink數據庫，可以使用如下語句。
mysqldump -uroot -h192.168.1.146 --routines --triggers --events --lock-tables --databases zsythink -p > zsythink.sql
在開啟二進制日志的情況下，備份指定的zsythink數據庫，通常使用如下語句。
mysqldump -uroot -h192.168.1.146 --flush-logs --master-data=2 --routines --triggers --events --lock-tables --databases zsythink -p > zsythink.sql
在開啟二進制日志的情況下，備份所有數據庫，通常使用如下語句。
mysqldump -uroot -h192.168.1.146 --flush-logs --master-data=2 --routines --triggers --events --lock-all-tables --all-databases -p > dbbackup.sql
假設，管理員誤操作數據庫，drop了zsythink數據庫，現在需要回復，那么，可以參考如下過程。通過管理員賬號登錄mysql因為恢復數據時會執行大量的insert語句，如果沒有特殊要求，還原時沒有必要將這些操作記錄到二進制日志中，所以關閉當前會話的二進制日志記錄。
mysql > set sql_log_bin=OFF;
注意：所有恢復操作完成后，最好將當前會話中的sql_log_bin再次開啟。
假設，通過mysqldump備份的出的zsythink數據庫的數據文件存放在/testdir目錄下，那么，可以在mysql提示符中使用如下命令，執行對應的sql文件。
. /testdir/zsythink.sql
上述備份sql文件執行完畢后，zsythink數據庫已經恢復到了備份sql對應的時間點，如果不進行時間點恢復，那么做到這一步就算完成了恢復工作，但是我們往往需要進行時間點還原。
進行時間點恢復時，備份時間點之后的數據則需要通過二進制日志進行還原，首先，要從二進制日志中提取對應的sql，提取sql的起始位置為備份開始時那一刻二進制文件對應的position，因為在使用mysldump備份時，我們推薦使用--master-data=2選項，所以在對應的數據庫備份sql文件中應該存在對應的position，提取sql的結束位置應該是drop語句對應的位置，因為咱們模擬的場景是有人誤操作drop了數據庫，所以結束位置應該是drop語句的位置。注意，不要把誤操作的drop語句提取出來，否則重放對應sql時又會將對應的數據刪除，如果是那樣就前功盡棄了。