mysqldump備份資料庫
1、首先打開mysql資料庫軟體進入軟體主界面。
2. mysql資料庫備份
在資料庫表丟失或損壞的情況下，備份你的資料庫是很重要的。如果發生系統崩潰，你肯定想能夠將你的表盡可能丟失最少的數據恢復到崩潰發生時的狀態。有時，正是MySQL管理員造成破壞。管理員已經知道表以破壞，用諸如vi或Emacs等編輯器試圖直接編輯它們，這對表絕對不是件好事！
備份資料庫兩個主要方法是用mysqlmp程序或直接拷貝資料庫文件（如用cp、cpio或tar等）。每種方法都有其優缺點：
• mysqlmp與MySQL伺服器協同操作。直接拷貝方法在伺服器外部進行，並且你必須採取措施保證沒有客戶正在修改你將拷貝的表。如果你想用文件系統備份來備份資料庫，也會發生同樣的問題：如果資料庫表在文件系統備份過程中被修改，進入備份的表文件主語不一致的狀態，而對以後的恢復表將失去意義。文件系統備份與直接拷貝文件的區別是對後者你完全控制了備份過程，這樣你能採取措施確保伺服器讓表不受干擾。
• mysqlmp比直接拷貝要慢些。
• mysqlmp生成能夠移植到其它機器的文本文件，甚至那些有不同硬體結構的機器上。直接拷貝文件不能移植到其它機器上，除非你正在拷貝的表使用MyISAM存儲格式。ISAM表只能在相似的硬體結構的機器上拷貝。在MySQL 3.23中引入的MyISAM表存儲格式解決了該問題，因為該格式是機器無關的，所以直接拷貝文件可以移植到具有不同硬體結構的機器上。只要滿足兩個條件：另一台機器必須也運行MySQL 3.23或以後版本，而且文件必須以MyISAM格式表示，而不是ISAM格式。
不管你使用哪種備份方法，如果你需要恢復資料庫，有幾個原則應該遵守，以確保最好的結果：
• 定期實施備份。建立一個計劃並嚴格遵守。
• 讓伺服器執行更新日誌。當你在崩潰後需要恢復數據時，更新日誌將幫助你。在你用備份文件恢復數據到備份時的狀態後，你可以通過運行更新日誌中的查詢再次運用備份後面的修改，這將資料庫中的表恢復到崩潰發生時的狀態。
• 以文件系統備份的術語講，資料庫備份文件代表完全傾倒（full mp），而更新日誌代表漸進傾倒（incremental mp）。
• 使用一種統一的和易理解的備份文件命名機制。象backup1、buckup2等不是特別有意義。當實施你的恢復時，你將浪費時間找出文件里是什麼東西。你可能發覺用資料庫名和日期構成備份文件名會很有用。例如：
• %mysqlmp samp_db >/usr/archives/mysql/samp_db.1999-10-02
• %mysqlmp menagerie >/usr/archives/mysql/menagerie.1999-10-02
• 你可能想在生成備份後壓縮它們。備份一般都很大！你也需要讓你的備份文件有過期期限以避免它們填滿你的磁碟，就象你讓你的日誌文件過期那樣。
• 用文件系統備份備份你的備份文件。如果遇上了一個徹底崩潰，不僅清除了你的數據目錄，也清除了包含你的資料庫備份的磁碟驅動器，你將真正遇上了麻煩。也要備份你的更新日誌。
• 將你的備份文件放在不同於用於你的資料庫的文件系統上。這將降低由於生成備份而填滿包含數據目錄的文件系統的可能性。
用於創建備份的技術同樣對拷貝資料庫到另一台機器有用。最常見地，一個資料庫被轉移到了運行在另一台主機上的伺服器，但是你也可以將數據轉移到同一台主機上的另一個伺服器。
1 使用mysqlmp備份和拷貝資料庫
當你使用mysqlmo程序產生資料庫備份文件時，預設地，文件內容包含創建正在傾倒的表的CREATE語句和包含表中行數據的INSERT語句。換句話說，mysqlmp產生的輸出可在以後用作mysql的輸入來重建資料庫。
你可以將整個資料庫傾倒進一個單獨的文本文件中，如下：
%mysqlmp samp_db >/usr/archives/mysql/samp_db.1999-10-02
輸出文件的開頭看起來象這樣：
# MySQL Dump 6.0# # Host: localhost Database: samp_db#---------------------------------------# Server version 3.23.2-alpha-log## Table structure for table 'absence'#CREATE TABLE absence( student_id int(10) unsigned DEFAULT '0' NOT NULL, date date DEFAULT '0000-00-00' NOT NULL, PRIMARY KEY (student_id,date));## Dumping data for table 'absence'#INSERT INTO absence VALUES (3,'1999-09-03');INSERT INTO absence VALUES (5,'1999-09-03');INSERT INTO absence VALUES (10,'1999-09-08');......
文件剩下的部分有更多的INSERT和CREATE TABLE語句組成。
如果你想壓縮備份，使用類似如下的命令：
%mysqlmp samp_db | gzip >/usr/archives/mysql/samp_db.1999-10-02.gz
如果你要一個龐大的資料庫，輸出文件也將很龐大，可能難於管理。如果你願意，你可以在mysqlmp命令行的資料庫名後列出單獨的表名來傾到它們的內容，這將傾倒文件分成較小、更易於管理的文件。下例顯示如何將samp_db資料庫的一些表傾到進分開的文件中：
%mysqlmp samp_db student score event absence >grapbook.sql
%mysqlmp samp_db member president >hist-league.sql
如果你生成准備用於定期刷新另一個資料庫內容的備份文件，你可能想用--add-drop-table選項。這告訴伺服器將DROP TABLE IF EXISTS語句寫入備份文件，然後，當你取出備份文件並把它裝載進第二個資料庫時，如果表已經存在，你不會得到一個錯誤。
如果你倒出一個資料庫以便能把資料庫轉移到另一個伺服器，你甚至不必創建備份文件。要保證資料庫存在於另一台主機，然後用管道傾倒資料庫，這樣mysql能直接讀取mysqlmp的輸出。例如：你想從主機pit-viper.snake.net拷貝資料庫samp_db到boa.snake.net，可以這樣很容易做到：
%mysqladmin -h boa.snake.net create samp_db
%mysqlmp samp_db | mysql -h boa.snake.net samp_db
以後，如果你想再次刷新boa.snake.net上的資料庫，跳過mysqladmin命令，但要對mysqlmp加上--add-drop-table以避免的得到表已存在的錯誤：
%mysqlmp --add-drop-table samp_db | mysql -h boa.snake.net samp_db
mysqlmp其它有用的選項包括：
• --flush-logs和--lock-tables組合將對你的資料庫檢查點有幫助。--lock-tables鎖定你正在傾倒的所有表，而--flush-logs關閉並重新打開更新日誌文件，新的更新日誌將只包括從備份點起的修改資料庫的查詢。這將設置你的更新日誌檢查點位備份時間。（然而如果你有需要執行個更新的客戶，鎖定所有表對備份期間的客戶訪問不是件好事。）
• 如果你使用--flush-logs設置檢查點到備份時，有可能最好是傾倒整個資料庫。如果你傾倒單獨的文件，較難將更新日誌檢查點與備份文件同步。在恢復期間，你通常按資料庫為基礎提取更新日誌內容，對單個表沒有提取更新的選擇，所以你必須自己提取它們。
• 預設地，mysqlmp在寫入前將一個表的整個內容讀進內存。這通常確實不必要，並且實際上如果你有一個大表，幾乎是失敗的。你可用--quick選項告訴mysqlmp只要它檢索出一行就寫出每一行。為了進一步優化傾倒過程，使用--opt而不是--quick。--opt選項打開其它選項，加速數據的傾倒和把它們讀回。
• 用--opt實施備份可能是最常用的方法，因為備份速度上的優勢。然而，要警告你，--opt選項確實有代價，--opt優化的是你的備份過程，不是其他客戶對資料庫的訪問。--opt選項通過一次鎖定所有表阻止任何人更新你正在傾倒的任何錶。你可在一般資料庫訪問上很容易看到其效果。當你的資料庫一般非常頻繁地使用，只是一天一次地調節備份。
• 一個具有--opt的相反效果的選項是--dedayed。該選項使得mysqlmp寫出INSERT DELAYED語句而不是INSERT語句。如果你將數據文件裝入另一個資料庫並且你想是這個操作對可能出現在該資料庫中的查詢的影響最小，--delayed對此很有幫助。
• --compress選項在你拷貝資料庫到另一台機器上時很有幫助，因為它減少網路傳輸位元組的數量。下面有一個例子，注意到--compress對與遠端主機上的伺服器通信的程序才給出，而不是對與本地主機連接的程序：
%mysqlmp --opt samp_db | mysql --compress -h boa.snake.net samp_db
• mysqlmp有很多選項，詳見《MySQL參考手冊》。
2 使用直接拷貝資料庫的備份和拷貝方法
另一種不涉及mysqlmp備份資料庫和表的方式是直接拷貝資料庫表文件。典型地，這用諸如cp、tar或cpio實用程序。本文的例子使用cp。
當你使用一種直接備份方法時，你必須保證表不在被使用。如果伺服器在你則正在拷貝一個表時改變它，拷貝就失去意義。
保證你的拷貝完整性的最好方法是關閉伺服器，拷貝文件，然後重啟伺服器。如果你不想關閉伺服器，要在執行表檢查的同時鎖定伺服器。如果伺服器在運行，相同的制約也適用於拷貝文件，而且你應該使用相同的鎖定協議讓伺服器「安靜下來」。
假設伺服器關閉或你已經鎖定了你想拷貝的表，下列顯示如何將整個samp_db資料庫備份到一個備份目錄（DATADIR表示伺服器的數據目錄）：
%cdDATADIR%cp -r samp_db /usr/archive/mysql
單個表可以如下備份：
%cdDATADIR/samp_db%cp member.* /usr/archive/mysql/samp_db%cp score.* /usr/archive/mysql/samp_db ....
當你完成了備份時，你可以重啟伺服器（如果關閉了它）或釋放加在表上的鎖定（如果你讓伺服器運行）。
要用直接拷貝文件把一個資料庫從一台機器拷貝到另一台機器上，只是將文件拷貝到另一台伺服器主機的適當數據目錄下即可。要確保文件是MyIASM格式或兩台機器有相同的硬體結構，否則你的資料庫在另一台主機上有奇怪的內容。你也應該保證在另一台機器上的伺服器在你正在安裝資料庫表時不訪問它們。
3 復制資料庫（Replicating Database）
復制（Replication）類似於拷貝資料庫到另一台伺服器上，但它的確切含義是實時地保證兩個資料庫的完全同步。這個功能將在3.23版中出現，而且還不很成熟，因此本文不作詳細介紹。
4 用備份恢復數據
資料庫損壞的發生有很多原因，程度也不同。如果你走運，你可能僅損壞一兩個表（如掉電），如果你倒霉，你可能必須替換整個數據目錄（如磁碟損壞）。在某些情況下也需要恢復，比如用戶錯誤地刪除了資料庫或表。不管這些倒霉事件的原因，你將需要實施某種恢復。
如果表損壞但沒丟失，嘗試用myisamchk或isamchk修復它們，如果這樣的損壞可有修復程序修復，你可能根本不需要使用備份文件。關於表修復的過程，見《資料庫維護與修復》。
恢復過程涉及兩種信息源：你的備份文件和個更新日誌。備份文件將表恢復到實施備份時的狀態，然而一般表在備份與發生問題之間的時間內已經被修改，更新日誌包含了用於進行這些修改的查詢。你可以使用日誌文件作為mysql的輸入來重復查詢。這已正是為什麼要啟用更新日誌的原因。
恢復過程視你必須恢復的信息多少而不同。實際上，恢復整個資料庫比單個表跟容易，因為對於資料庫運用更新日誌比單個表容易。
4.1 恢復整個資料庫
首先，如果你想恢復的資料庫是包含授權表的mysql資料庫，你需要用--skip-grant-table選項運行伺服器。否則，它會抱怨不能找到授權表。在你已經恢復表後，執行mysqladmin flush-privileges告訴伺服器裝載授權標並使用它們。
• 將資料庫目錄內容拷貝到其它某個地方，如果你在以後需要它們。
• 用最新的備份文件重裝資料庫。如果你用mysqlmp產生的文件，將它作為mysql的輸入。如果你用直接從資料庫拷貝來的文件，將它們直接拷回資料庫目錄，然而，此時你需要在拷貝文件之前關閉資料庫，然後重啟它。
使用更新日誌重復做備份以後的修改資料庫表的查詢。對於任何可適用的更新日誌，將它們作為mysql的輸入。指定--one-database選項使得mysql只執行你有興趣恢復的資料庫的查詢。如果你知道你需要運用所有更新日誌文件，你可以在包含日誌的目錄下使用這條命令：
% ls -t -r -1 update.[0-9]* | xargs cat | mysql --one-databasedb_name
ls命令生成更新日誌文件的一個單列列表，根據伺服器產生它們的次序排序（主意：如果你修改任何一個文件，你將改變排序次序，這導致更新日誌一錯誤的次序被運用。）
很可能你會是運用某幾個更新日誌。例如，自從你備份以來產生的更新日誌被命名為update.392、update.393等等，你可以這樣重新運行：
%mysql --one-database db_name < update.392
%mysql --one-database db_name < update.393
.....
如果你正在實施恢復且使用更新日誌恢復由於一個錯誤建議的DROP DATABASE、DROP TABLE或DELETE語句造成丟失的信息，在運用更新日誌之前，要保證從其中刪除這些語句。
4.2 恢復單個表
恢復單個表較為復雜。如果你用一個由mysqlmp生成的備份文件，並且它不包含你感興趣的表的數據，你需要從相關行中提取它們並將它們用作mysql的輸入。這是容易的部分。難的部分是從只運用於該表的更新日誌中拉出片斷。你會發覺mysql_find_rows實用程序對此很有幫助，它從更新日誌中提取多行查詢。
另一個可能性是使用另一台伺服器恢復整個資料庫，然後拷貝你想要的表文件到原資料庫中。這可能真的很容易！當你將文件拷回資料庫目錄時，要確保原資料庫的伺服器關閉。
至於用php語句寫mysql備份，涉及一些php課程，我也不是太懂，不好意思~~
3. mysql備份方式有哪些
資料庫最直接的備份方法就是使用自帶的mysqlmp命令進行備份。
1、 mysqlmp命令備份數據
在MySQL中提供了命令行導出資料庫數據以及文件的一種方便的工具mysqlmp,我們可以通過命令行直接實現資料庫內容的導出mp,首先我們簡單了解一下mysqlmp命令用法:
#MySQLmp常用
mysqlmp -u root -p --databases 資料庫1 資料庫2 > xxx.sql
2、 mysqlmp常用操作實例
2.1備份全部資料庫的數據和結構
mysqlmp -uroot -p123456 -A > /data/mysqlDump/mydb.sql
2.2備份全部資料庫的結構（加 -d 參數）
mysqlmp -uroot -p123456 -A -d > /data/mysqlDump/mydb.sql
2.3 備份全部資料庫的數據(加 -t 參數)
mysqlmp -uroot -p123456 -A -t > /data/mysqlDump/mydb.sql
2.4 備份單個資料庫的數據和結構(,資料庫名mydb)
mysqlmp -uroot-p123456 mydb > /data/mysqlDump/mydb.sql
2.5 備份單個資料庫的結構
mysqlmp -uroot -p123456 mydb -d > /data/mysqlDump/mydb.sql
2.6 備份單個資料庫的數據
mysqlmp -uroot -p123456 mydb -t > /data/mysqlDump/mydb.sql2
2.7 備份多個表的數據和結構（數據，結構的單獨備份方法與上同）
mysqlmp -uroot -p123456 mydb t1 t2 > /data/mysqlDump/mydb.sql
2.8 一次備份多個資料庫
mysqlmp -uroot -p123456 --databases db1 db2 > /data/mysqlDump/mydb.sql
4. MySQL 常用備份工具流程解析
下面我們就看一下常見的備份工具，以及目前最流行的 Percona XtraBackup 的備份流程。
MySQL 常見的備份工具主要分為三種：
這里先說一下 binlog 備份，它只是把 binlog 又復制了一份，並且需要在邏輯備份或者物理備份的基礎上才能進行數據恢復，無法單獨進行數據恢復。
mysqlmp 備份出的文件就是 sql 文件，其核心就是對每個表執行 select ，然後轉化成相應的 insert 語句。mysqlmp 的備份流程大致如下：
從上面可以看出在 mysqlmp 備份期間，備份到某個資料庫時，該資料庫下的表都會處於只讀狀態，無法對表進行任何變更，直到該庫下的表備份完畢，這對於線上環境一般是無法接受的。若是指定了--master-data或者 --mp-slave 則會在備份開始時加全局讀鎖（FLUSH TABLES WITH READ LOCK），直到備份結束。當然我們可以選一個從庫進行備份，這樣就不會影響線上業務。另外使用 mysqlmp 備份還有一個最大的好處，因為備份出來的是 sql 語句，所以它支持跨平台和跨版本的數據遷移或者恢復，這是物理備份無法做到的。
但是也正是因為 mysqlmp 備份出來的是 sql 語句，在使用時要更加註意，否則可能會釀成大禍。例如，使用 mysqlmp 常見的問題有：
所以使用 mysqlmp 時一定要了解各個選項的作用，以及確認備份出來的 sql 文件里會有什麼操作，會對現有數據造成什麼影響。
Mymper 原理與 Mysqlmp 原理類似，最大的區別是引入了多線程備份，每個備份線程備份一部分表，當然並發粒度可以到行級，達到多線程備份的目的。這里不再單獨介紹。
Percona XtraBackup 是 Percona 公司開發的一個用於 MySQL 資料庫物理熱備的備份工具，是基於 InnoDB 的崩潰恢復功能來實現的。它的基本工作原理如下：
Percona XtraBackup 在進行恢復時會應用拷貝的 redo log ，應用已提交的事務，回滾未提交的事物，將資料庫恢復到一致性狀態。因為 Percona XtraBackup 備份出來的是物理文件，所以在使用備份出的文件進行恢復或者遷移時，不會像 mysqlmp 那樣會存在很多問題。
使用 XtraBackup 備份時根據備份參數設置不同，對資料庫的變更會造成不同程度的影響，具體影響會在下文分析。
通過對比發現，XtraBackup 具有對資料庫影響小，且能快速恢復的優點，在日常備份中是首選；mysqlmp 使用相對更加靈活，但是使用是要注意對資料庫原有數據的影響。
備份策略主要有：全量備份和增量備份，再加上 binlog 備份。
目前去哪兒網資料庫備份主要採用 XtraBackup 全量備份 +binlog 備份。資料庫的重要級別不同，全量備份的頻率不同。備份程序主要架構如下：
說明：
Percona XtraBackup 是目前備份 MySQL 使用最廣泛的工具。在備份過程中，資料庫可以進行正常的讀寫或者其他變更操作，但是偶爾也會遇見備份引起的元數據鎖，或提交事務時發現被 binlog lock 阻塞等情況。下面我們就看一下 Percona XtraBackup 的備份流程和加鎖時機。
說明：以下對 Percona XtraBackup 的分析都是基於 2.4.23 的版本，其他版本會略有差別，但是關鍵步驟基本相同。
XtraBackup 在備份開始時，會創建一個後台線程，專門用於拷貝資料庫的 redo log 。首先 XtraBackup 會掃描每組 redo log 的頭部，找出當前的 checkpoint lsn ，然後從該 lsn 後順序拷貝所有的 redo log ，包括後續新產生的 redo log 。該線程會一直持續到將非事務表完全拷貝完成，才會安全退出。備份日誌輸出中會記錄拷貝開始時的 checkpoint lsn 。日誌輸出如下：
在拷貝ibd文件之前，會先掃描資料庫的數據文件目錄，獲取ibdata1，undo tablespaces及所有的ibd文件列表，並會記錄相應的 space id，因為在恢復時需要這些 space id來找到對應 doublewrite buffer里頁面的內容，以及對應的redo log條目。然後開始循環拷貝ibdata1，undo tablespaces及所有的ibd文件。
這里可通過設置--parallel進行多線程備份，提高物理文件的拷貝效率。不設置則默認為1。
在所有ibd文件拷貝完成後，XtraBackup開始備份非ibd文件。這一部分的邏輯比較復雜，因為備份非ibd文件前需要加鎖，具體是否會加鎖主要受到--no-lock 參數設置的影響。
若是設置了--no-lock為TRUE，則不會使用"FLUSH TABLES WITH READ LOCK"去加全局讀鎖，但是若備份過程中對non-InnoDB表執行了DDL或者DML操作， 這會導致備份的不一致，恢復出來的數據就會有問題。所以是不建議將--no-lock為TRUE，默認值是FALSE，也就是在不指定該選項的情況下會在備份非ibd文件前加全局讀鎖。
下面我們結合源碼來看看判斷是否加全局鎖這部分的具體流程邏輯：
流程圖如下：
總結來看：
1）若--no-lock為FALSE（默認值），則先施加全局讀鎖，然後再進行拷貝文件，另外若 --safe-slave-backup 設置為TRUE ，則會在加全局鎖之前關閉SQL_THREAD線程；
2）若--no-lock為TRUE，則不會施加鎖，直接進行拷貝文件。
加鎖的邏輯主要由lock_tables_maybe實現,先看一下lock_tables_maybe源代碼，如下：
lock_tables_maybe 函數簡化處理流程如下：
1）若備份實例上已經加鎖（ LOCK TABLES FOR BACKUP / FLUSH TABLES WITH READ LOCK）或者設置lock-ddl-per-table 則直接返回；
2）若支持備份鎖，則執行LOCK TABLES FOR BACKUP；
3）若不支持備份鎖，則執行 FLUSH TABLES WITH READ LOCK。根據相應選項設置，在執行該操作前會判斷是否有執行中的DDL/DML，以及等待超時時間，是否kill 對應的未結束的事務等。
從上文中我們還看到一個參數--safe-slave-backup ，該參數的主要作用是：
若是在從庫執行的備份操作時設置了該參數，可以防止因從庫同步主庫操作，而導致XtraBackup長時間請求不到鎖而造成備份失敗。
若是設置了 --safe-slave-backup 為TRUE，那麼會執行"STOP SLAVE SQL_THREAD"，並等待Slave_open_temp_tables 為零才開始拷貝非 ibd 文件，Slave_open_temp_tables 為零說明SQL thread執行的事務都已經完成，這樣就能保證備份的一致性。並且此時也不會有在執行的事務阻塞 XtraBackup 施加全局鎖。
備份完非 ibd 文件後，將會備份 slave 和 binlog 信息。
mysql-bin.000004 2004 6b7bda9f-15f0-11ec-ba14-fa163ea367a4:1-83,9841546e-15f0-11ec-9557-fa163e736db4:1
需要注意，在支持備份鎖的實例上備份，指定了 --slave-info 或--binlog-info 均會先施加 binlog 備份鎖（ LOCK BINLOG FOR BACKUP），這會阻塞任何會更改 binlog 位點的操作。
備份完資料庫的所有文件和binlog等相關信息，備份工作就基本完成了，之後主要執行的操作如下：
1）執行"FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS",將所有的redo log刷盤；
2）停止redo log復制線程；
3）釋放全局讀鎖（備份鎖），binlog鎖；
4）開啟SQL_THREAD；
5）拷貝ib_buffer_pool和ib_lru_mp文件；
6）生成配置文件backup-my.cnf；
7）列印備份信息到xtrabackup_info文件，這些信息主要包含備份時使用的參數信息，備份起止時間，binlog位點信息，以及將會回到的lsn點。
下面是xtrabackup_info記錄的部分內容：
加鎖對應的函數是 mdl_lock_tables ，釋放鎖對應的函數是 mdl_unlock_all，主要是執行COMMIT，結束 mdl_lock_tables 中開啟的顯式事務，來釋放MDL鎖。mdl_lock_tables 流程如下：
上面參數--lock-ddl和--lock-ddl-per-table是在 Percona XtraBackup 2.4.8 之後添加的，因為 MySQL 5.7 新增了一個叫做 Sorted Index Builds 的功能，這會導致某些 DDL 操作不記錄重做日誌而導致備份失敗。使用--lock-ddl或--lock-ddl-per-table 就會在備份開始時施加鎖，阻止 DDL 操作。
另外，若備份時指定了--lock-ddl或--lock-ddl-per-table，則在備份非 ibd 文件時就不是再有加鎖操作。
注意：LOCK TABLES FOR BACKUP和LOCK BINLOG FOR BACKUP 語句只有在支持備份鎖的實例上才會執行，Percona Server for MySQL已經在 5.6.16-64.0 版本開始支持這種更加輕量的備份鎖。
Q1: 使用 XtraBackup 備份的文件進行恢復時，恢復到哪個時間點？ A1：恢復到執行 LOCK BINLOG FOR BACKUP 或 FLUSH TABLES WITH READ LOCK 的時間點，因為這時任何改變 binlog 位點的操作都會被阻塞，redo log和binlog 是一致的。
Q2: 在開啟 binlog 的情況下，MySQL 的奔潰恢復是同時依賴 binlog 和 redo log 這兩種日誌的，為什麼XtraBackup 不用備份binlog？
A2：因為在備份中有執行LOCK BINLOG FOR BACKUP/FLUSH TABLES WITH READ LOCK，阻止了任何改變binlog位點的操作，這樣只需要根據redo log將有commit log 的事務提交，沒有commit log的事務進行回滾即可。
Q3: 使用Percona XtraBackup備份完成後redo的位點是和binlog是一樣還是比binlog多一些？
A3：通過分析備份流程可以發現備份 binlog 位點信息（加binlog鎖）是發生在停止 redo 拷貝線程前，而釋放鎖是在停止 redo 拷貝線之後，所以 redo log 會多一些。鎖住了 binlog 保證了在該 binlog 位點前已經提交的事務的 redo log 都有 commit log 的信息，未提交的事物也就沒有對應的 commit log 的信息，即便在鎖住 binlog 後有 Innodb 表新的 DML 產生的 redo log ，但是事務無法提交，也就沒有 commit log 的信息的，最後在回放的過程中對沒有 commit log 的事務進行回滾就可以了。
Q4：Percona XtraBackup什麼時候會加鎖，以及影響加鎖時間長度的因素有哪些？
A4：上面進行了分析，加鎖操作只在備份非 ibd 文件時執行，加鎖時長主要和非事務表的數量和大小有關，非事務表的數量越多，體積越大，拷貝文件所用的時間越長，那麼加鎖時間也就越長。也會和 redo log 生成的速度有關，只是 redo log 刷盤受到多個因素的影響，未及時刷盤的 redo log 一般很小。
Q5：Percona XtraBackup 和mysqlmp選擇哪個更好？
A5：通過上面的的解析，若是整個實例備份，首先選擇 Percona XtraBackup ，因為對資料庫的影響最小。若只是備份某個庫表，這個就要視數據量而定，若數據量不大可以使用 mysqlmp 。注意，對資料庫做備份時最好選擇業務連接最少的從庫，因為備份也會消耗一定的資源，避免影響業務。
5. 如何實現MySQL資料庫的備份與恢復
在資料庫表丟失或損壞的情況下 備份你的資料庫是很重要的 如果發生系統崩潰 你肯定想能夠將你的表盡可能丟失最少的數據恢復到崩潰發生時的狀態 有時 正是MySQL管理員造成破壞 管理員已經知道表以破壞 用諸如vi或Emacs等編輯器試圖直接編輯它們 這對表絕對不是件好事！備份資料庫兩個主要方法是用mysqlmp程序或直接拷貝資料庫文件（如用cp cpio或tar等） 每種方法都有其優缺點 mysqlmp與MySQL伺服器協同操作 直接拷貝方法在伺服器外部進行 並且你必須採取措施保證沒有客戶正在修改你將拷貝的表 如果你想用文件系統備份來備份資料庫 也會發生同樣的問題 如果資料庫表在文件系統備份過程中被修改 進入備份的表文件主語不一致的狀態 而對以後的恢復表將失去意義 文件系統備份與直接拷貝文件的區別是對後者你完全控制了備份過程 這樣你能採取措施確保伺服器讓表不受干擾 mysqlmp比直接拷貝要慢些 mysqlmp生成能夠移植到其它機器的文本文件 甚至那些有不同硬體結構的機器上 直接拷貝文件不能移植到其它機器上 除非你正在拷貝的表使用MyISAM存儲格式 ISAM表只能在相似的硬體結構的機器上拷貝 在MySQL 中引入的MyISAM表存儲格式解決了該問題 因為該格式是機器無關的 所以直接拷貝文件可以移植到具有不同硬體結構的機器上 只要滿足兩個條件 另一台機器必須也運行MySQL 或以後版本 而且文件必須以MyISAM格式表示 而不是ISAM格式 不管你使用哪種備份方法 如果你需要恢復資料庫 有幾個原則應該遵守 以確保最好的結果 定期實施備份 建立一個計劃並嚴格遵守 讓伺服器執行更新日誌 當你在崩潰後需要恢復數據時 更新日誌將幫助你 在你用備份文件恢復數據到備份時的狀態後 你可以通過運行更新日誌中的查詢再次運用備份後面的修改 這將資料庫中的表恢復到崩潰發生時的狀態 以文件系統備份的術語講 資料庫備份文件代表完全傾倒（full mp） 而更新日誌代表漸進傾倒（incremental mp） 使用一種統一的和易理解的備份文件命名機制 象backup buckup 等不是特別有意義 當實施你的恢復時 你將浪費時間找出文件里是什麼東西 你可能發覺用資料庫名和日期構成備份文件名會很有用 例如 %mysqlmp samp_db >/usr/archives/mysql/samp_db %mysqlmp menagerie >/usr/archives/mysql/menagerie 你可能想在生成備份後壓縮它們 備份一般都很大！你也需要讓你的備份文件有過期期限以避免它們填滿你的磁碟 就象你讓你的日誌文件過期那樣 用文件系統備份備份你的備份文件 如果遇上了一個徹底崩潰 不僅清除了你的數據目錄 也清除了包含你的資料庫備份的磁碟驅動器 你將真正遇上了麻煩 也要備份你的更新日誌 將你的備份文件放在不同於用於你的資料庫的文件系統上 這將降低由於生成備份而填滿包含數據目錄的文件系統的可能性 用於創建備份的技術同樣對拷貝資料庫到另一台機器有用 最常見地 一個資料庫被轉移到了運行在另一台主機上的伺服器 但是你也可以將數據轉移到同一台主機上的另一個伺服器 使用mysqlmp備份和拷貝資料庫 當你使用mysqlmo程序產生資料庫備份文件時 預設地 文件內容包含創建正在傾倒的表的CREATE語句和包含表中行數據的INSERT語句 換句話說 mysqlmp產生的輸出可在以後用作mysql的輸入來重建資料庫 你可以將整個資料庫傾倒進一個單獨的文本文件中 如下 %mysqlmp samp_db >/usr/archives/mysql/samp_db 輸出文件的開頭看起來象這樣 # MySQL Dump ## Host: localhost Database: samp_db# # Server version alpha log## Table structure for table absence #CREATE TABLE absence(student_id int( ) unsigned DEFAULT NOT NULL date date DEFAULT NOT NULL PRIMARY KEY (student_id date));## Dumping data for table absence #INSERT INTO absence VALUES ( );INSERT INTO absence VALUES ( );INSERT INTO absence VALUES ( ); 文件剩下的部分有更多的INSERT和CREATE TABLE語句組成 如果你想壓縮備份 使用類似如下的命令 %mysqlmp samp_db | gzip >/usr/archives/mysql/samp_db gz如果你要一個龐大的資料庫 輸出文件也將很龐大 可能難於管理 如果你願意 你可以在mysqlmp命令行的資料庫名後列出單獨的表名來傾到它們的內容 這將傾倒文件分成較小 更易於管理的文件 下例顯示如何將samp_db資料庫的一些表傾到進分開的文件中 %mysqlmp samp_db student score event absence >grapbook sql%mysqlmp samp_db member president >hist league sql如果你生成准備用於定期刷新另一個資料庫內容的備份文件 你可能想用 add drop table選項 這告訴伺服器將DROP TABLE IF EXISTS語句寫入備份文件 然後 當你取出備份文件並把它裝載進第二個資料庫時 如果表已經存在 你不會得到一個錯誤 如果你倒出一個資料庫以便能把資料庫轉移到另一個伺服器 你甚至不必創建備份文件 要保證資料庫存在於另一台主機 然後用管道傾倒資料庫 這樣mysql能直接讀取mysqlmp的輸出 例如 你想從主機拷貝資料庫samp_db到 可以這樣很容易做到 %mysqladmin h create samp_db%mysqlmp samp_db | mysql h samp_db以後 如果你想再次刷新上的資料庫 跳過mysqladmin命令 但要對mysqlmp加上 add drop table以避免的得到表已存在的錯誤 %mysqlmp add drop table samp_db | mysql h samp_dbmysqlmp其它有用的選項包括 flush logs和 lock tables組合將對你的資料庫檢查點有幫助 lock tables鎖定你正在傾倒的所有表 而 flush logs關閉並重新打開更新日誌文件 新的更新日誌將只包括從備份點起的修改資料庫的查詢 這將設置你的更新日誌檢查點位備份時間 （然而如果你有需要執行個更新的客戶 鎖定所有表對備份期間的客戶訪問不是件好事 ）如果你使用 flush logs設置檢查點到備份時 有可能最好是傾倒整個資料庫 如果你傾倒單獨的文件 較難將更新日誌檢查點與備份文件同步 在恢復期間 你通常按資料庫為基礎提取更新日誌內容 對單個表沒有提取更新的選擇 所以你必須自己提取它們 預設地 mysqlmp在寫入前將一個表的整個內容讀進內存 這通常確實不必要 並且實際上如果你有一個大表 幾乎是失敗的 你可用 quick選項告訴mysqlmp只要它檢索出一行就寫出每一行 為了進一步優化傾倒過程 使用 opt而不是 quick opt選項打開其它選項 加速數據的傾倒和把它們讀回 用 opt實施備份可能是最常用的方法 因為備份速度上的優勢 然而 要警告你 opt選項確實有代價 opt優化的是你的備份過程 不是其他客戶對資料庫的訪問 opt選項通過一次鎖定所有表阻止任何人更新你正在傾倒的任何錶 你可在一般資料庫訪問上很容易看到其效果 當你的資料庫一般非常頻繁地使用 只是一天一次地調節備份 一個具有 opt的相反效果的選項是 dedayed 該選項使得mysqlmp寫出INSERT DELAYED語句而不是INSERT語句 如果你將數據文件裝入另一個資料庫並且你想是這個操作對可能出現在該資料庫中的查詢的影響最小 delayed對此很有幫助 press選項在你拷貝資料庫到另一台機器上時很有幫助 因為它減少網路傳輸位元組的數量 下面有一個例子 注意到 press對與遠端主機上的伺服器通信的程序才給出 而不是對與本地主機連接的程序 %mysqlmp opt samp_db | mysql press h samp_dbmysqlmp有很多選項 詳見《MySQL參考手冊》 使用直接拷貝資料庫的備份和拷貝方法 另一種不涉及mysqlmp備份資料庫和表的方式是直接拷貝資料庫表文件 典型地 這用諸如cp tar或cpio實用程序 本文的例子使用cp 當你使用一種直接備份方法時 你必須保證表不在被使用 如果伺服器在你則正在拷貝一個表時改變它 拷貝就失去意義 保證你的拷貝完整性的最好方法是關閉伺服器 拷貝文件 然後重啟伺服器 如果你不想關閉伺服器 要在執行表檢查的同時鎖定伺服器 如果伺服器在運行 相同的制約也適用於拷貝文件 而且你應該使用相同的鎖定協議讓伺服器 安靜下來 假設伺服器關閉或你已經鎖定了你想拷貝的表 下列顯示如何將整個samp_db資料庫備份到一個備份目錄（DATADIR表示伺服器的數據目錄） %cd DATADIR%cp r samp_db /usr/archive/mysql單個表可以如下備份 %cd DATADIR/samp_db%cp member * /usr/archive/mysql/samp_db%cp score * /usr/archive/mysql/samp_db 當你完成了備份時 你可 lishixin/Article/program/MySQL/201311/29384
6. mysql中備份資料庫的命令是
使用mysqlmp工具進行備份：
1）備份所有資料庫：
$ mysqlmp -uroot -p --all-database > all.sql
（2）備份資料庫test
$ mysqlmp -uroot -p test > test.sql
（3）備份資料庫test下的表emp
$ mysqlmp -uroot -p test emp > emp.sql
（4）備份資料庫test下的表emp和dept
$ mysqlmp -uroot -p test emp dept > emp_dept.sql