Mysql 邏輯備份

邏輯備份特點

在日常工作中，我們會使用 mysqldump 命令建立sql格式的轉儲檔案來備份資料庫。或者我們把資料匯出後做資料遷移，主從複製等操作。mysqldump是乙個邏輯備份工具,複製原始的資料庫物件定義和表資料產生一組可執行的sql語句。預設情況下,生成insert語句，也能生成其它分隔符的輸出或xml格式的檔案。

特點自動記錄position位置。

show master  status\g;

可用性，一致性

鎖表機制

用法

mysqldump -h 伺服器 -u使用者名稱 -p密碼資料庫名 > 備份檔案.sql /*檢視幫助*/

mysqldump --help

常見引數

有幾個選項控制mysqldump如何處理儲存的程式（儲存過程和函式，觸發器和事件）：

--triggers預設情況下啟用該選項，以便在轉儲表時，它們伴隨著它們具有的任何觸發器。

預設情況下要禁用這些選項。需要明確設定這些選項：

--skip-events，--skip-routines,--skip-triggers。

備份所有庫

// 先配置使用者名稱和密碼
shell>
vi ~/.mysql_user
[mysqldump]
user=root
password=123
shell> mysqldump --defaults-file=~/.mysql_user -h172.16.153.10 --all-databases >
`date +%ft%h_%m_%s`
dump_all.sql
# 不包含 information_schema,performance_schema,sys

備份指定的多個庫

// 為了考慮篇幅，請自行新增指定使用者名稱密碼引數和指定伺服器的引數 // --defaults-file=~/.mysql_user -hip shell> mysqldump --databases db1 db2 db3 > `date +%ft%h_%m_%s`

dump_all.sql

備份指定庫的指定幾個表

shell> mysqldump db1 t1 t3 t7 > dump.sql

其他引數優勢

mysqldump的優勢：

可以檢視或者編輯十分方便，它也可以靈活性的恢復之前的資料。

不關心底層的儲存引擎，既適用於支援事務的，也適用於不支援事務的表。

不過它不能作為乙個快速備份大量的資料或可伸縮的解決方案。如果資料庫過大,即使備份步驟需要的時間不算太久,但有可能恢復資料的速度也會非常慢,因為它涉及的sql語句插入磁碟i/o,建立索引等等。對於大規模的備份和恢復,更合適的做法是物理備份,複製其原始格式的資料檔案,可以快速恢復。

恢復

shell> mysql -uroot -p123456   db1  < dump.sql

或者，在mysql中，使用source命令：

mysql> source dump.sql

如果檔案是不包含create database和use語句的單資料庫轉儲，請首先建立資料庫（如有必要）：

shell> mysqladmin create db1

然後在載入轉儲檔案時指定資料庫名稱：

shell> mysql db1 < dump.sql

或者，在mysql中建立資料庫，將其選為預設資料庫，然後載入轉儲檔案：

mysql> create database if not exists db1;
mysql> use db1;
mysql>source dump.sql

example

shell> mysql --defaults-file=~/.mysql_user < /backup/2016-12-08-04-mysql-all.sql

shell> mysqldump --single-transaction --flush-logs --master-data=2 \
--all-databases > backup_sunday_1_pm.sql

該--flush-logs選項會導致伺服器重新整理其日誌。

在星期一下午1點，我們可以通過重新整理日誌來開始新的二進位制日誌檔案來建立增量備份。例如，執行mysqladmin flush-logs命令會建立gbichot2-bin.000008。週日下午1點完整備份和周一下午1點之間的所有更改都將在gbichot2-bin.000007檔案中。此增量備份很重要，因此最好將其複製到安全的地方。

在星期二下午1點，執行另乙個mysqladmin flush-logs命令。周一下午1點到周二下午1點之間的所有更改都將在gbichot2-bin.000008檔案中（也應該在安全的地方複製）。

使用備份進行恢復

shell> mysql < backup_sunday_1_pm.sql

此時，資料將恢復到截至週日下午1點的狀態。要恢復自那時以來所做的更改，我們必須使用增量備份; 也就是gbichot2-bin.000007和gbichot2-bin.000008二進位制日誌檔案。必要時從備份位置獲取檔案，然後按如下方式處理其內容：

shell> mysqlbinlog gbichot2-bin.000007 gbichot2-bin.000008 | mysql

我們現在已經將資料恢復到周二下午1點的狀態，但仍然缺少從該日期到崩潰日期的更改。為了不丟失它們，我們需要讓mysql伺服器將其mysql二進位制日誌儲存到與儲存其資料檔案的地方不同的安全位置（raid磁碟，san，…），以便這些日誌不會在被破壞的磁碟上。（也就是說，我們可以使用乙個--log-bin選項來啟動伺服器，該選項指定與資料目錄所在的物理裝置不同的物理裝置上的位置。這樣，即使包含該目錄的裝置丟失，日誌也是安全的。）如果我們做到了這一點，我們會有gbichot2-bin.000009手頭的檔案（以及任何後續檔案），我們可以使用mysqlbinlog和mysql來應用它們來恢復最新的資料更改，直到崩潰時都沒有損失：

shell> mysqlbinlog gbichot2-bin.000009 ... | mysql

有關使用mysqlbinlog處理二進位制日誌檔案的更多資訊

時間點恢復基於以下原則：

時間點恢復的資訊源是由完全備份操作之後生成的二進位制日誌檔案表示的增量備份集。

要從二進位制日誌還原資料，您必須知道當前二進位制日誌檔案的名稱和位置。

要檢視所有二進位制日誌檔案的列表，請使用以下語句：

mysql> show binary logs;

要確定當前二進位制日誌檔案的名稱，請發出以下語句：

mysql> show master status;

Mysql 邏輯備份

mysql 邏輯備份 mysql的邏輯備份和恢復

Mysql邏輯備份

MySQL邏輯備份

Mysql 邏輯備份

mysql 邏輯備份 mysql的邏輯備份和恢復

Mysql邏輯備份

MySQL邏輯備份

相關推薦