1 環境描述
1.1 硬件環境
服務器類型：華為RH5885
IP: 10.148.128.100
內存: 64G
物理CPU個數：4
CPU核數：8
邏輯CPU個數：64
Intel(R) Xeon(R) CPU E7-4820 v2 @ 2.00GHz
1.2 Mysql版本
1.3 數據環境
生產按照130MW滿規格進行測試。所測試備份的最大數據量為381G。
由於監控數據量遠小於生產，故重點對生產的備份還原進行了測試。
監控只測試了數據量較小的情況，可參考生產的備份還原情況對其進行粗略估計。
2 采用的數據庫備份方法
2.1 Mysqlbackup
Mysqlbackup是物理備份的方式。對innodb的表空間進行物理復制，但是，它是記錄LSN點的。在備份過程中，新增加的輸入直接寫入備份文件的ibbackup_logfile中。同時記錄最后的LSN點。還原的時候，檢測對比ibbackup_logfile文件里面與表空間里面的差值，使ibbackup_logfile里面的數據進入事務日志或表空間。
2.1.1 壓縮備份
備份:
time /opt/mysql/meb-3.11/bin/mysqlbackup --compress --backup-dir=/srv/mytest --socket=/opt/mysql/data/mysql.sock --datadir=/opt/mysql/data -usystem -pHwsystem@com --include-tables="eSCS" backup
說明：--compress 壓縮備份
還原:
1．檢查事務日志，並解壓
time /opt/mysql/meb-3.11/bin/mysqlbackup --uncompress --backup-dir=/srv/mytest apply-log
【說明】：Apply-log之前，數據文件是不一致的，因為它們在不同時間點被備份。因此，apply-log會使所有數據文件的步調達成一致。通過innodb 的crash recovery把已經提交的事務寫入數據文件，把沒有提交的事務進行回滾。apply-log沒有強制在線上或者備份庫上運行。
2. 還原物理文件
time /opt/mysql/meb-3.11/bin/mysqlbackup --defaults-file=/etc/my.cnf --backup-dir=/srv/mytest --datadir=/opt/mysql/data copy-back
【注意】：壓縮備份只能應用於全備，不能對增量備份進行壓縮；
壓縮備份不能應用與已經是壓縮格式（Barracuda file format）的innodb 表。
2.1.2 非壓縮備份
備份
time /opt/mysql/meb-3.11/bin/mysqlbackup --backup-dir=/srv/mytest --socket=/opt/mysql/data/mysql.sock --datadir=/opt/mysql/data -usystem -pHwsystem@com --include-tables="eSCS" backup
說明：--compress 壓縮備份
還原
time /opt/mysql/meb-3.11/bin/mysqlbackup --backup-dir=/srv/mytest apply-log
time /opt/mysql/meb-3.11/bin/mysqlbackup --defaults-file=/etc/my.cnf --backup-dir=/srv/mytest --datadir=/opt/mysql/data copy-back
2.2 Mysqldump
Mysqldump是mysql自帶工具。備份出來的文件是一個可以直接倒入的sql腳本。該sql文件中實際上包含了多個CREATE 和INSERT語句，使用這些語句可以重新創建表和插入數據。
2.2.1 壓縮備份
備份
time mysqldump -usystem -pHwsystem@com --databases platform_eSCS910 eSCS | gzip > /opt/mybackupfile.sql.gz ;
還原
time gunzip < /opt/mybackupfile.sql.gz | mysql -usystem -pHwsystem@com
2.2.2 非壓縮備份
備份
time mysqldump -usystem -pHwsystem@com --databases platform_eSCS910 eSCS > /opt/mybackupfile.sql
還原
time mysql -usystem -pHwsystem@com < /opt/mybackupfile.sql
3 測試結果
3.1 910數據庫備份還原測試
| 備份方法 |
原始文件大小 |
備份文件大小 |
備份耗時 |
還原耗時 |
|||
| 壓縮 |
非壓縮 |
壓縮 |
非壓縮 |
壓縮 |
非壓縮 |
||
| Mysqldump |
13M ./eSCS 1.8M ./mysql 635K ./performance_schema 2.8M ./platform_eSCS910 191M /opt/mysql/data |
112K |
881K |
0.34s |
0.32s |
2.47s |
2.47s |
| Mysqlbackup |
2.8M (189M) 注1 |
92M (189M)注1 |
4.11s |
5.10s |
6.00s (2.94+ 3.06）注2 |
4.13s (1.039+ 3.09)注2 |
|
| Mysqldump |
419M ./eSCS 25M ./mysql 635K ./performance_schema 2.8M ./platform_eSCS910 619M /opt/mysql/data |
2M |
25M |
1m18.723s |
1m19.123s |
1m9.389s |
1m9.736s |
| Mysqlbackup |
58M (596M) |
499M (596M) |
45.969s |
45.92s |
1m11.64s (22.600s +49.038s) |
47.13s (1.955s +45.173s) |
|
注1：執行檢查事務日志(apply-log)后，備份文件目錄大小為：189M
注2：backup還原耗時為：apply-log + copy-back的總和。
3.2 710數據庫備份還原測試
| 備份方法 |
原始文件大小 |
備份文件大小 |
備份耗時 |
還原耗時 |
|||
| 壓縮 |
非壓縮 |
壓縮 |
非壓縮 |
壓縮 |
非壓縮 |
||
| Mysqldump |
5.8G ./ePMS 419M ./eSCS 14M ./mysql 635K ./performance_schema 2.9M ./platform_ePMS710 2.8M ./platform_eSCS910 6.9G . |
90M |
2.7G |
1m11.39s |
54.59s |
8m7.24s |
8m3.01s |
| Mysqlbackup |
569M (6.4G)注1 |
6.3G (6.4G) 注1 |
41.56s |
41.59s |
1m15.53s (28.694s+ 46.832s) |
47.38s (1.189s +46.189s） |
|
| Mysqldump |
27G ./ePMS 28G /opt/mysql/data （此數據環境為43G Mysqldump恢復之后的環境） |
--- |
--- |
--- |
--- |
--- |
--- |
| Mysqlbackup |
3.0G （28G） (壓縮率89.20%) |
27G （28G） |
3m18.77s |
3m4.86s |
6m30.01s (2m42.407s+ 3m47.713s） |
3m47.99S (1.163s+ 3m46.839s) |
|
| Mysqldump |
43G ./ePMS 44G /opt/mysql/data |
770M |
21G |
9m26.54s |
7m12.97s |
64m44.67s |
62m48.03s |
| Mysqlbackup |
--- |
--- |
--- |
--- |
--- |
--- |
|
| Mysqldump |
381G ./ePMS 13M ./eSCS 11M ./mysql 635K ./performance_schema 2.9M ./platform_ePMS710 2.8M ./platform_eSCS910 381G /opt/mysql/data |
3.4G 注 |
203G |
4h44m31.66s
備注*2 |
4h45m10.09s |
11h45m20.86s 注： 恢復完成后數據僅223G！(磁盤空間足夠) |
11h35m33.76s 注： 恢復完成后數據僅238G！(磁盤空間足夠) 備注*1 |
| Mysqlbackup |
24G (壓縮率93.90%) |
381G |
46m19.47s |
40m46.95s |
解壓到223G(耗時16m38.9s)，磁盤滿，還原失敗。 |
52m8.423s |
|
| Mysqldump |
238G ./ePMS 238G /opt/mysql/data （此數據環境為381G Mysqldump恢復之后的環境） |
3.4G |
--- |
1h41m0.22s |
--- |
--- |
--- |
| Mysqlbackup |
17G |
--- |
30m36.27s |
--- |
--- |
--- |
|
備注1*： mysqldunp方式還原后，文件占用大小與備份前數據大小不一致。對比備份前后數據庫表記錄條數：發現是一致的！
具體而言，文件大小減少的是某些數據文件(*.ibd)，由於還原時對數據文件進行了重新整理而節約了空間。
圖：測試dump還原后數據量變小
備注2* ：此處Mysqldump耗時可能會更高一些。這個第二次測試的數據，第一次測試耗時128m41s才備份完1.1G。覺得遙遙無期故手動中斷。按照備份完3.4G計算，備份大概需要6-7小時，高於表中所示數據。
圖：dump備份耗時可能會更久，估計與系統運行狀態有關
4 總結與分析
4.1 時間消耗
- 共部署情況，710/910備份及還原耗時情況，只與本網元數據庫數據量有關，基本不受共部署另一網元影響。
- 數據還原的耗時大於備份的耗時。
- Mysqlbackup耗時情況：
圖1. Mysqlbackup耗時情況
1） Mysqlbackup物理備份方式主要是進行文件的拷貝。其備份耗時與數據量大小呈較穩定的線性關系。在該測試環境下，基本滿足：y=7.3x。
2） 壓縮耗時差異：
Mysqlbackup方法，壓縮與否的備份耗時基本相同。
但還原時，壓縮情況要比非壓縮耗時長，約為非壓縮情況的1-2倍(執行copyback的時間與備份時間相當，時間多在執行apply-log解壓上)。還原的時間統計圖暫未列出。
- Mysqldump耗時情況：
圖2. Mysqldump耗時情況 及Mysqlbackup對比
1）在數據量較小時（10-100M數據量，如初始安裝狀態），Mysqldump耗時較少，低於Mysqlbackup方法。
2） 粗略估計：400M數據情況下，Mysqldump、Mysqlbackup耗時相當。
3）當數據量增加時（1G數據量以上），Mysqldump耗時增長較快。且隨着數據量的增加，耗時遠遠大於Mysqlbackup方法。
可參考以上測試結果，估算大概耗時情況。
4）對於Mysqldump方法，壓縮與否的耗時基本相同(包括備份、還原)。
5）Mysqldump備份耗時與原數據存儲的緊湊程度有較大的關系。
【其他說明】：以上測試結果都在第1.1節說明的環境下進行。若在E9000虛擬機上測試(分配20G內存，4 CPU)，根據實際耗時：備份耗時比此環境下測試結果高1-2倍，還原耗時比此環境高3-7倍。(僅測試了mysqldump方式，且不夠充分，這里是粗略總結。)
4.2 空間占用
- 壓縮率
Mysqldump ：壓縮率約為：96.5%。
Mysqlbackup：壓縮率也在90%以上。二者壓縮效率都很可觀！
之前說了壓縮與否耗時基本相當。故采用壓縮的方式進行備份和還原是比較划算的。
- Mysqldump與Mysqlbackup比較：
壓縮情況下Mysqldump與Mysqlbackup備份文件占用空間都不大。其次，Mysqldump邏輯備份的方式，其備份文件比Mysqlbackup的小。Mysqldump還原操作后，數據文件占用空間與原數據文件相比要小。
Mysqlbackup還原操作時，檢查事務文件並解壓，解壓完成后空間占用與原始文件(/opt/mysql/data/下)大小一致。
4.3 對系統性能影響
1. 數據量較大時，Mysqldump方法會消耗大量內存和CPU資源，也直接影響了自身的備份性能，導致在數據量大時備份速度更慢。
2. Mysqlbackup方法系統資源占用較少，基本不造成影響。這也從另一方面反映了其耗時呈線性狀態的原因。
3. Mysqlbackup還原時，請首先停掉數據庫！否則，還原結束后，重啟mysql服務會有異常。
4. Mysqlbackup還原時，第一步時檢查事務文件並解壓。請注意檢查磁盤空間，確保備份所在目錄空間足夠！否則解壓失敗后無法繼續進行還原操作：
4.4 備份還原注意事項
- 我們采用的存儲引擎是innodb，默認是共享表空間，即數據庫所有表數據、索引文件都放在/opt/mysql/data/ibdata1文件。共部署情況下Mysqlbackup還原可能存在問題，執行還原成功后數據庫可能無法正常使用。
===================================================
附錄 其他數據備份還原方式
其實，在mysqldump使用手冊上已經說明了，在數據量大的時候，並不適合采用mysqldump方式，其推薦采用的是物理備份的方式。然而Mysqlbackup物理備份的方式對共部署環境並不太適用(或者我們還不是很會用)。其他InnoDB 表備份/恢復策略小結：
1. 使用商業的在線熱備份工具 Hotbackup
Hotbackup可以在InnoDB數據庫運行之時備份你的InnoDB數據庫，並且它不設置任何鎖定或干擾你正常的數據庫處理。缺點：付費。
2. Xtrabackup
Xtrabackup是一個對InnoDB做數據備份的工具，支持在線熱備份（備份時不影響數據讀寫），據說是商業備份工具InnoDB Hotbackup較好的替代品。
3. 使用sql 語句備份
select into 熱備份單個/多個表。與mysqldump很相似，同樣是把數據庫備份到一個指定的文件中。常用於創建表的備份復件或者用於對記錄進行存檔。
4. 拷貝文件
直接備份數據文件較為直接、快速、方便。缺點是基本上不能實現增量備份。
為了保證數據的一致性，需要在拷貝文件前，執行以下 SQL 語句： FLUSH TABLES WITH READ LOCK;把內存中的數據都刷新到磁盤中，同時鎖定數據表，以保證拷貝過程中不會有新的數據寫入。
注意，對於 Innodb 類型表來說，還需要備份其日志文件，即 ib_logfile* 文件。總的來說，直接拷貝的方式可靠性低。
5. Navicat工具備份
優缺點：使用方便，但是備份和還原時間都比較長。