原創|高逼格企業級MySQL資料庫備份方案,原來是這樣....
很多人,這裡說的是運維工程師們,一提到寫某某方案,很是頭疼。不是上某度一統搜尋,就是同樣一句話在N個群全部群發一遍:“有沒有某某方案,可以共享一下的嗎??求助,各位大佬們”,估計十有八九,全部石沉大海,杳無音訊。
其實,到底是真的很難,還是說你沒有完全掌握整個備份思路的整理?一個方案的好壞,在於對於外行人來說,能不能一眼就能看懂其中要表達的意思,而且不需要很多的思考就可以。
一份好的備份方案無非包括以下幾點:
-
為什麼需要備份?
-
備份的方式有哪些?
-
某幾種備份方式的區別在哪?
-
備份實戰操作概述
-
恢復實戰操作概述
-
其它備註資訊
那麼,此文將從以上幾個角度,結合一些實際的實戰經驗,分步闡述一個完整的備份方案到底是怎麼樣構成的。需要學習更多Mysql資料庫相關的知識,可以在公眾號:民工哥技術之路的後臺回覆「MySQL」即可獲取一份最全的MySQL資料庫學習指南。
為什麼需要資料庫備份?
很多人,一看這標題,肯定張口就會答,這不是廢話麼。不備份故障了怎麼辦?跑路嗎?資料被沙雕開發(不許噴)誤刪了怎麼辦?背鍋嗎?
當然,大家都知道備份的重要性與必要性。
1、保證資料安全與完整
企業的資料安全應該來說是企業的命脈,一旦丟失或造成損壞,輕則損失客戶與金錢,重則倒閉(已經有前例在)。
備份的目的:為了保證資料在被人為失誤、操作不當、蓄意等情況下刪除或損壞後,能及時、有效的進行恢復並不會很大程度上影響到業務執行。
2、為業務提供不間斷服務
實際生產環境對資料庫的要求,首先就是具備7×24×365不間斷服務的能力,這也是一定要備份資料庫的其中原因之一。
資料庫的備份方式
常用的備份方式包括以下:
-
邏輯備份
-
物理備份
1、邏輯備份
邏輯備份其實就是利用MySQL資料庫自帶的mysqldump命令,或者使用第三方的工具,然後把資料庫裡的資料以SQL語句的方式匯出成檔案的形式。在需要恢復資料時,通過使用相關的命令(如:source )將備份檔案裡的SQL語句提取出來重新在資料庫中執行一遍,從而達到恢復資料的目的。
例項如下:
mysqldump -A -B --single-transaction >/server/backup/mysql_$(date +%F).sql
一般備份時都會進行壓縮處理,以節省磁碟空間,如下
mysqldump -A -B --single-transaction |gzip>/server/backup/mysql_$(date +%F).sql.gz
恢復操作
cd /server/backup/
gzip -o mysql_$(date +%F).sql.gz
mysql -uroot -pMyadmin -h mysqldb.mingongge.com
> source /server/backup/mysql_$(date +%F).sql
邏輯備份的優點與使用場景
優點:簡單,易操作,自帶工具方便、可靠。
使用場景:資料庫資料量不大的情況可以使用,資料量比較大(超過20G左右)時備份速度比較慢,一定程度上還會影響資料庫本身的效能。
2、物理備份
物理備份就是利用命令(如cp、tar、scp等)直接將資料庫的儲存資料檔案複製一份或多份,分別存放在其它目錄,以達到備份的效果。
這種備份方式,由於在備份時資料庫還會存在資料寫入的情況,一定程度上會造成資料丟失的可能性。在進行資料恢復時,需要注意新安裝的資料的目錄路徑、版本、配置等與原資料要保持高度一致,否則同樣也會有問題。
所以,這種物理備份方式,常常需要在停機狀態下進行,一般對實際生產中的資料庫不太可取。因此,此方式比較適用於資料庫物理遷移,這種場景下這種方式比較高效率。
物理備份的優點及使用場景
優點:速度快,效率高。
場景:可用於停機維護及資料庫物理遷移場景中。
實際生產環境中,具體使用哪種方式,就需要看需求與應用場景所定。
全量與增量備份概述
在介紹完備份方式之後,再來介紹一下,增量與全量備份這兩個概念。
什麼是全量備份?
全量備份:就是將資料庫中的所有資料,或者是某一個特定的庫裡的所有資料,一次全部備份下。
備份資料庫中所有資料
mysqldump -A -B --single-transaction |gzip>/server/backup/All_data_$(date +%F).sql.gz
備份某個庫的資料
mysqldump -A -B --single-transaction testDB1|gzip>/server/backup/testDB1_$(date +%F).sql.gz
什麼是增量備份?
增量備份:指的是上一次全量備份之後到下一次全量備份這前這段時間內資料庫所更新或者是增加的資料,將其備份下來。
注:全量備份是一個檔案,而增量備份則是MySQL的binlog日誌檔案。所以常說的增量備份就是備份binlog日誌檔案。
兩者的區別在哪?
全量備份:需要的備份時間長一點,恢復時間會短一點,因為檔案數少,維護方便。但是,全量備份的檔案大,佔用一定的磁碟空間,全理備份時會一定程式上影響資料庫的效能(這也就是為什麼在0:00點備份的原因),也因檔案大的原因,不便於伺服器本地儲存過多檔案,重要業務的全量備份檔案可能需要手工下載或遷移到伺服器之外的儲存空間中。
增量備份:備份簡單,恢復時複雜一點,因為檔案數量多,需將所有binlog檔案解析成SQL語句,如下:
mysqlbinlog testDB1-bin.000001 testDB1-bin.000002 >./bin.sql
然後,再通過恢復的方式進行恢復
mysql -uroot -pMyadmin -h mysqldb.mingongge.com
> source /server/backup/bin.sql
或者如下操作
cd /server/backup
mysql testDB1 <./bin.sql
備份與恢復實踐操作
對於Mysql資料庫的備份,一般採取指令碼+定時任務進行日常備份。
常用執行策略是:
-
每天0:00執行一次全量備份
-
按業務需求執行增量備份
分享一個我在一個創業公司初期的一個備份方案例項
阿里雲資料庫伺服器備份方案
方案一:
目前資料庫是主從同步,從庫開啟binlog日誌功能進行異地備份,就目前資料量而言,只需要在從庫的基礎上進行定時全量與增量備份資料庫即可。
1、建立備份目錄
mkdir /server/backup
2、備份資料庫到指定目錄
mysqldump --single-transaction -F -B phoenix_coupon_production|gzip >/server/backup/phoenix_$(date +%F).sql.gz
mysqldump --single-transaction -F -B ywotx|gzip >/server/backup/ywotx_$(date+%F).sql.gz
find /server/backup/ -type f –name “*.sql.gz”-mtime +7 |xargs rm-f
將指令碼寫入定時任務,分時段進行打包備份
3、定時備份二進位制檔案
通過引數重新整理binlog產生新的檔案,通過指令碼判斷檔案新舊,然後備份舊的日誌檔案
mysqladmin -uroot -pywotx!123 flush-logs #重新整理日誌,產生新的日誌檔案
最終將備份檔案同步或定時手工下載到異地備份伺服器異地儲存備份檔案,實現資料庫備份檔案雙備份儲存,防止伺服器硬體故障。
方案二
後期資料量增大之後,資料庫需要進行讀寫分離,實現主寫,從讀,主從同步的架構,備份還是按照原來的備份方案進行,可採用分庫分表進行資料備份,防止資料量大導致的恢復時間的問題,提升恢復效率。
1、建立備份目錄
Mkdir /server/backup
2、備份資料到指定目錄( 分庫分表)
#/bin/sh
#create by mingongge at 2017-06-01
BACKUPDIR=/server/backup
DATE=`date +%F`
USER=root
PASSWD=”123456”
CMD=”mysql –u$USER –p$PASSWD”
DUMPCMD=”mysqldump –u$USER –p$PASSWD --single-transaction -F”
for dbname in `${CMD} –e “show databases”|sed ‘1d’`
do
mkdir –p${BACKUPDIR}/${dbname}
for tablename in`${CMD} –D ${dbname} –e “show tables”|sed ‘1d’`
do
${DUMPCMD} --tables${dbname} ${tablename} |gzip > ${BACKUPDIR}/${dbname}/${tablename}_$(DATE).sql.gz
done
done
find /server/backup/${dbname} -type f –name “*.sql.gz”-mtime +7|xargs rm -f
3、定時備份二進位制檔案(增量)
備份方法同方案一
備份頻率:
-
每天0:00進行一次資料庫全備
-
每天03:00 9:00 15:00 21:00 增量備份一次
資料庫的備份,每天一次全備,在全備時會更新binlog日誌,重新生成新的日誌檔案,因此在下一次增量備份時再重新整理binlog,再次產生新的日誌檔案,實現從全備之後對資料庫的操作的增量備份,一旦發現數據問題,立即重新整理binlog重新成新的日誌檔案,將原來的日誌檔案手工備份一份,然後找出產生資料問題的點,從而利用日誌檔案進行恢復全備到產生資料問題點之間的資料,然後恢復從問題點到發現問題時間段之間的資料.
新增一臺備份伺服器,配置如下:
例項配置:2核/4G/40G + 200G高效雲盤 經典網路 1M 295元/月
方案總結:
對於資料庫伺服器本地的備份檔案基本上只保留一週時間內的資料,備份伺服器按需求(一般保留至少30天的資料),保留30天的資料包括資料庫全備檔案與增量備份檔案,後期可按實際生產需求進行修改,保留時間長短只會增加相應的伺服器磁碟空間,增加一定的成本,其它無需改動,操作較為靈活、方便。
如果需要整套備份方案的,可以在民工哥技術之路公眾號後臺回覆「備份」獲取全套方案的下載地址。有興趣的讀者朋友們可以試試更多的關鍵字:「專案、MySQL、避坑」。