1. 程式人生 > >MySQL備份之mysqldump

MySQL備份之mysqldump

備份型別:
1.物理備份:指的是物理檔案的複製,從一個存放位置拷貝到另一個位置;分為冷備和熱備和溫備;熱備份:讀、寫不受影響; 溫備份:僅可以執行讀操作;冷備份:離線備份;讀、寫操作均中止;很少使用,生產環境下的伺服器堅決不允許停機
優點:直接拷貝mysql的資料目錄,速度快,但只適用於MyISAM型別的表,這種型別的表是與機器獨立的。
缺點:不能去操作正在執行的mysql伺服器(在拷貝的過程中有使用者通過應用程式訪問更新資料,這樣就無法備份當時的資料)可能無法移植到其他機器上去;更多的情況是根據業務特點,查詢速度,服務效能來選擇表型別的。
說明:熱備份需要根據不同的儲存引擎採用不同的備份工具
MyISAM:


方法一: MySQL提供了一個用Perl編寫的實用程式mysqlhotcopy,其主要實現原理是先鎖表,然後執行flush tables動作,該關閉的表正常關閉,該進行flush同步的資料都進行同步,然後通過複製命令,將需要備份的資料的所有物理檔案都複製到指定的備份位置上,語法:mysqlhotcopy database backupdir
方法二:在SQL命令列下執行flush tables for read,將資料庫中所有的表加read lock,以保證資料的一致性,然後通過cp命令將資料檔案備份到指定目錄下。
InnoDB:對於InnoDB可以使用Percona公司的xtrabackup,或者InnoBase自己的收費產品ibbackup
MyISAM中為了保持資料的一致性,需要在備份之前對所備份的資料庫加讀鎖操作flush table with read lock;InnoDB則可以在mysqladmin命令中加入-single-transaction選項,生成一個快照來保證資料備份期間的一致性。
2.邏輯備份:
將資料庫的結構連同資料匯出至文字檔案中;可以檢視編輯匯出的檔案,邏輯備份對所有的儲存引擎來說都是適用的;邏輯備份使用mysql自帶的mysqldump工具進行備份,備份成.sql的檔案形式。
優點:方便使用文字處理工具直接對其處理、可移植能力強;最大好處是能夠與正在執行的mysql自動協同工作(通過加引數來控制mysql伺服器,比如鎖定所有表只能進行讀,不能進行寫操作),在執行期間可以確保備份是當時的點,它會自動將對應操作的表鎖定,不允許其他使用者修改(只能訪問),可能會阻止修改操作。
缺點:備份的速度比較慢,如果是資料量很多的時候,就很耗時間。如果資料庫伺服器處在提供給使用者服務狀態,在這段長時間操作過程中,意味著要鎖定表(一般是讀鎖定,只能讀不能寫入資料)。那麼服務就會受到影響。另外也可能會丟失浮點數精度、備份出的資料更佔用儲存空間;壓縮後可大大節省空間;不適合對大資料庫做完全備份。
3.完全備份、增量備份和差異備份;

完全備份:備份全部資料;
增量備份:僅備份上次完全備份或增量備份以後變化的資料;通過備份binlog日誌來實現,當啟用MySQL的二進位制日誌功能,對資料庫進行的DML(select除外),DDL操作都會記錄到其中,每當MySQL重啟時,資料庫會重新生成一個binlog檔案。
差異備份:僅備份上次完全備份以來變化的資料;
線上:物理完全備份
自動備份總體策略:
1.備份方案:每週完全+每日增量 (來實現即時點還原)
增量備份,每天備份二進位制日誌檔案
2.假設伺服器資料量小,使用mysqldump進行備份
3.使用邏輯備份方式:為了跨平臺,使用邏輯備份,儲存sql檔案的形式。
備份工具的路徑:/usr/local/mysql/bin/mysqldump
備份資料儲存路徑:完全:/root/Databak/weekly/
增量:/root/Logbak/daily/
備份指令碼的編寫思路:
1.在shell指令碼中呼叫mysqldump生成sql備份檔案到磁碟上
(擴充套件:可以將每次備份的操作記錄成日誌檔案:備份操作的時間,生成備份的檔名稱。這樣可以方便以後查閱哪天是否成功備份)
2.讓linux下的crontab程序呼叫指令碼執行:命令:crontab -e
定時在晚上或凌晨自動備份(考慮資料庫伺服器在執行中不能停機,在凌晨的時候mysqldump去鎖定,訪問資料庫伺服器,對伺服器幾乎沒什麼影響)
按照以上思路將步驟寫在指令碼中
完全備份指令碼:
這裡寫圖片描述
執行此指令碼生成完全備份檔案
這裡寫圖片描述
增量備份指令碼:增量備份是完全基於bin-log日誌來進行的
這裡寫圖片描述
執行此指令碼生成每日增量備份檔案
這裡寫圖片描述
開啟自動執行檔案

[root@DQ ~]# vim /etc/crontab

在etc中加入如下內容,讓其自動執行任務
這裡寫圖片描述
crontab採用按時間呼叫以下4個目錄中的指令碼執行的方式
/etc/cron.hourly:每小時;
/etc/cron.daily:每 天;
/etc/cron.weekly:每週;
/etc/cron.monthly:每月
因此將剛才編輯的指令碼複製到相應的目錄也可以
這裡寫圖片描述
重啟服務即可

[root@DQ ~]# /etc/rc.d/init.d/crond restart

測試模擬資料庫伺服器崩潰:
到資料存放目錄下,先複製二進位制日誌到root目錄下,以做即時點恢復
(模擬生產環境中二進位制日誌檔案沒有與資料庫檔案存放在同一塊儲存裝置上)
這裡寫圖片描述
而後刪除資料目錄下的所有資料
這裡寫圖片描述
重新初始化mysql資料庫
這裡寫圖片描述
這裡寫圖片描述
可能由於先前在mysql伺服器處於執行狀態下刪除其資料目錄下的檔案又重新初始化導致其鎖檔案,PID檔案的錯亂,造成服務無法啟動與停止,使用killall殺掉所有mysqld程序後成功啟動服務

[root@DQ ~]# killall mysqld

這裡寫圖片描述
連線到mysql伺服器檢視當前資料庫資訊
這裡寫圖片描述
進行資料恢復,匯入完全備份
這裡寫圖片描述
再次檢視資料庫資訊
這裡寫圖片描述
這裡寫圖片描述
匯入二進位制日誌
這裡寫圖片描述
再做即時點還原
這裡寫圖片描述
二進位制還原完成後tutors表的資料與還原完全備份時的資料狀態已經不同
這裡寫圖片描述
考慮到備份檔案日積月累檔案會佔據很大空間,所以每次備份成功後,刪除以前的檔案,保留最近一個星期的備份sql檔案,對指令碼進行改進
這裡寫圖片描述
這裡寫圖片描述
mysqldump:–master-data={0|1|2}
0: 不記錄二進位制日誌檔案及路位置;
1:以CHNAGE MASTER TO的方式記錄位置,可用於恢復後直接啟動從伺服器;
2:以CHANGE MASTER TO的方式記錄位置,但預設為被註釋;
這裡寫圖片描述
–lock-all-tables:鎖定所有表
–flush-logs: 執行日誌flush;
如果指定庫中的表型別均為InnoDB,可使用– single-transaction啟動熱備;
(線上繁忙的伺服器上啟用該引數可能會啟動一個執行時間很長的事務;自動實現鎖表等操作,不可與lock-all-tables同時使用)
備份多個庫:
–all-databases: 備份所有庫
–databases DB_NAME,DB_NAME,…: 備份指定庫
以下引數瞭解即可
–events
–routines
–triggers
mysqldump不適合用來做大型資料集的備份:
對MyISAM引擎只能做溫備,在備份前務必lock tables
對InnoDB建議做熱備
mysql> FLUSH TABLES WITH READ LOCK;
–single-transaction自動啟動一個事務藉助MVCC, 如果隔級別為REPEATABLE-READ完全可以實現一致性備份

SELECT
備份:
SELECT * INTO OUTFILE ‘/path/to/somefile.txt’ FROM tb_name [WHERE clause];
還原:
LOAD DATA INFILE ‘/path/to/somefile.txt’ INTO TABLE tb_name;
這裡寫圖片描述
這裡寫圖片描述

幾乎熱備:LVM
snapshot:
前提:
1、資料檔案要在邏輯捲上;
2、此邏輯卷所在卷組必須有足夠空間使用快照卷;
3、資料檔案和事務日誌要在同一個邏輯捲上;(避免做快照時時間點不一致)
步驟:開啟會話,施加讀鎖,鎖定所有表;
這裡寫圖片描述
通過另一個終端,儲存二進位制日誌檔案及相關位置資訊;
這裡寫圖片描述
建立快照卷
這裡寫圖片描述
這裡寫圖片描述
釋放鎖
這裡寫圖片描述
掛載快照卷,備份
這裡寫圖片描述
做全庫備份複製除二進位制日誌以外的所有檔案
這裡寫圖片描述
如果要單獨備份某個庫,只需複製該庫對應的目錄,但前提要開啟每表使用1個獨立表空間檔案
這裡寫圖片描述
刪除快照卷;
這裡寫圖片描述
插入一些資料,以在二進位制日誌中產生記錄,測試即時點還原備份
這裡寫圖片描述
增量備份二進位制日誌;如果事件跨檔案可以基於時間劃分來儲存到同一檔案中
這裡寫圖片描述
這裡寫圖片描述
模擬資料損壞,停止mysqld服務,刪除資料目錄下的所有檔案,而後將備份的資料cp到資料目錄下
這裡寫圖片描述
這裡寫圖片描述
這裡寫圖片描述
在啟用innodb儲存引擎,事務日誌實現MySQL備份時二進位制日誌相關幾個選項的設定:
innodb_support_xa={TRUE|FLASE}
儲存引擎事務在儲存引擎內部被賦予了ACID屬性,分散式(XA)事務是一種高層次的事務,它利用“準備”然後“提交”(prepare-then-commit)兩段式的方式將ACID屬性擴充套件到儲存引擎外部,甚至是資料庫外部。然而,“準備”階段會導致額外的磁碟刷寫操作。XA需要事務協調員,它會通知所有的參與者準備提交事務(階段1)。當協調員從所有參與者那裡收到“就緒”資訊時,它會指示所有參與者進行真正的“提交”操作。
此變數正是用於定義InnoDB是否支援兩段式提交的分散式事務,預設為啟用。事實上,所有啟用了二進位制日誌的並支援多個執行緒同時向二進位制日誌寫入資料的MySQL伺服器都需要啟用分散式事務,否則,多個執行緒對二進位制日誌的寫入操作可能會以與原始次序不同的方式完成,這將會在基於二進位制日誌的恢復操作中或者是從伺服器上創建出不同原始資料的結果。因此,除了僅有一個執行緒可以改變資料以外的其它應用場景都不應該禁用此功能。而在僅有一個執行緒可以修改資料的應用中,禁用此功能是安全的並可以提升InnoDB表的效能。作用範圍為全域性和會話級別,可用於選項檔案,屬動態變數。

sync_binlog=1(使二進位制日誌在寫入時以安全的方式進行,不會引起因備份導致二進位制日誌損毀)
設定多久同步一次二進位制日誌至磁碟檔案中,0表示不同步,任何正數值都表示對二進位制每多少次寫操作之後同步一次。當autocommit的值為1時,每條語句的執行都會引起二進位制日誌同步,否則,每個事務的提交會引起二進位制日誌同步。