高逼格企業級MySQL數據庫備份方案，原來是這樣....

不少人，這裏說的是運維工程師們，一提到寫某某方案，非常頭疼。不是上某度一統搜索，就是一樣一句話在N個羣所有羣發一遍：「有沒有某某方案，能夠共享一下的嗎？？求助，各位大佬們」，估計十有八九，所有石沉大海，杳無音訊。

其實，究竟是真的很難，仍是說你沒有徹底掌握整個備份思路的整理？一個方案的好壞，在於對於外行人來講，能不能一眼就能看懂其中要表達的意思，並且不須要不少的思考就能夠。

一份好的備份方案無非包括如下幾點：

• 爲何須要備份？
• 備份的方式有哪些？
• 某幾種備份方式的區別在哪？
• 備份實戰操做概述
• 恢復實戰操做概述
• 其它備註信息

那麼，此文將從以上幾個角度，結合一些實際的實戰經驗，分步闡述一個完整的備份方案究竟是怎麼樣構成的。須要學習更多Mysql數據庫相關的知識，能夠在公衆號：民工哥技術之路的後臺回覆「MySQL」便可獲取一份最全的MySQL數據庫學習指南。

爲何須要數據庫備份？

不少人，一看這標題，確定張口就會答，這不是廢話麼。不備份故障了怎麼辦？跑路嗎？數據被沙雕開發（不準噴）誤刪了怎麼辦？背鍋嗎？

固然，你們都知道備份的重要性與必要性。

一、保證數據安全與完整

企業的數據安全應該來講是企業的命脈，一旦丟失或形成損壞，輕則損失客戶與金錢，重則倒閉（已經有前例在）。

備份的目的：爲了保證數據在被人爲失誤、操做不當、蓄意等狀況下刪除或損壞後，能及時、有效的進行恢復並不會很大程度上影響到業務運行。

二、爲業務提供不間斷服務

實際生產環境對數據庫的要求，首先就是具有7×24×365不間斷服務的能力，這也是必定要備份數據庫的其中緣由之一。

數據庫的備份方式

經常使用的備份方式包括如下：

• 邏輯備份
• 物理備份

一、邏輯備份

邏輯備份其實就是利用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左右）時備份速度比較慢，必定程度上還會影響數據庫自己的性能。

二、物理備份

物理備份就是利用命令（如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日誌功能進行異地備份，就目前數據量而言，只須要在從庫的基礎上進行定時全量與增量備份數據庫便可。

一、建立備份目錄

mkdir /server/backup

二、備份數據庫到指定目錄

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

將腳本寫入定時任務，分時段進行打包備份

三、定時備份二進制文件

經過參數刷新binlog產生新的文件，經過腳本判斷文件新舊，而後備份舊的日誌文件

mysqladmin -uroot -pywotx!123 flush-logs #刷新日誌，產生新的日誌文件

最終將備份文件同步或定時手工下載到異地備份服務器異地存儲備份文件，實現數據庫備份文件雙備份存儲，防止服務器硬件故障。

方案二

後期數據量增大以後，數據庫須要進行讀寫分離，實現主寫，從讀，主從同步的架構，備份仍是按照原來的備份方案進行，可採用分庫分表進行數據備份，防止數據量大致使的恢復時間的問題，提高恢復效率。

一、建立備份目錄

Mkdir /server/backup

二、備份數據到指定目錄( 分庫分表)

#/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

三、定時備份二進制文件（增量）
備份方法同方案一

備份頻率：

天天0:00進行一次數據庫全備

天天03:00 9:00 15:00 21:00 增量備份一次

數據庫的備份，天天一次全備，在全備時會更新binlog日誌，從新生成新的日誌文件，所以在下一次增量備份時再刷新binlog,再次產生新的日誌文件，實現從全備以後對數據庫的操做的增量備份，一旦發現數據問題，當即刷新binlog從新成新的日誌文件，將原來的日誌文件手工備份一份，而後找出產生數據問題的點，從而利用日誌文件進行恢復全備到產生數據問題點之間的數據,而後恢復從問題點到發現問題時間段之間的數據.

新增一臺備份服務器，配置以下：

實例配置：2核/4G/40G + 200G高效雲盤 經典網絡 1M 295元/月

方案總結：

對於數據庫服務器本地的備份文件基本上只保留一週時間內的數據，備份服務器按需求（通常保留至少30天的數據），保留30天的數據包括數據庫全備文件與增量備份文件，後期可按實際生產需求進行修改，保留時間長短只會增長相應的服務器磁盤空間，增長必定的成本，其它無需改動，操做較爲靈活、方便。

若是須要整套備份方案的，能夠在民工哥技術之路公衆號後臺回覆「備份」獲取全套方案的下載地址。有興趣的讀者朋友們能夠試試更多的關鍵字：「項目、MySQL、避坑」。