共計 2581 個字符，預計需要花費 7 分鐘才能閱讀完成。
這篇文章將為大家詳細講解有關如何解決 MySQL 中使用 innobackup 2.4 遇到的問題，丸趣 TV 小編覺得挺實用的，因此分享給大家做個參考，希望大家閱讀完這篇文章后可以有所收獲。
一 前言
Percona 公司發布 innobackup 2.4 版本已經很久了，增加了新的特性比如 xtrabackup 支持非 Innodb 表備份，指定 –safe-slave-backup，增加備份的一致性，最重要的一點是支持 5.7 的備份，2.2 是不能備份 5.7 版本的。
因此我們決定將我們的 percona 的 pt 工具和備份軟件更新到最新版本。本文主要記錄我們使用 2.4 版本過程中遇到的問題和之前的一些改變。
二 問題和差異
2.1 backup-my.cnf 文件
innobackup 2.4 版本比 之前的版本多了幾個參數
2.2 版本的內容
[mysqld]
innodb_checksum_algorithm=innodb
innodb_log_checksum_algorithm=innodb
innodb_data_file_path=ibdata1:12M:autoextend
innodb_log_files_in_group=2
innodb_log_file_size=1073741824
innodb_page_size=16384
innodb_log_block_size=512
innodb_undo_directory=.
innodb_undo_tablespaces=0
2.4 版本的內容
[mysqld]
innodb_checksum_algorithm=innodb
innodb_log_checksum_algorithm=innodb
innodb_data_file_path=ibdata1:12M:autoextend
innodb_log_files_in_group=2
innodb_log_file_size=1073741824
innodb_page_size=16384
innodb_log_block_size=512
innodb_undo_directory=.
innodb_undo_tablespaces=0
server_id=0 # 2.4 新增參數
redo_log_version=0 # 2.4 新增參數
innodb_fast_checksum=false # 2.4 新增參數
這里強調一下 innodb_fast_checksum ，在 applay log 之后依賴 backup-my.cnf 啟動 MySQL 的時候 5.6 是不能識別該參數的, 導致啟動失敗。[ERROR] mysqld: unknown variable innodb_fast_checksum=0
來看看 2014 年 相關的 bug 說法
“Or maybe a separate feature request should be opened to copy the whole my.cnf to the backup directory as well. I will leave that up to others to decide.”
都 3 年了，都沒有得出什么有效的結果。。
其他地方的討論，其實可以直接關閉。
https://dba.stackexchange.com/questions/6386/is-there-any-reason-not-to-use-percona-innodb-fast-checksum
2.2 場景
由于歷史原因，我們還有部分數據庫是是基于 mysqld_multi 做單機多實例的。這種單機多實例的配置文件有兩種 /etc/my.cnf 和 /path/my.multi.cnf 兩個配置文件。my.multi.cnf 文件里面配置了實例級別的個性參數。比如
[mysqld_multi]
mysqld=/usr/bin/mysqld_safe
mysqladmin=/usr/bin/mysqladmin
user=mysql
log=/data/multi.log
[3306]
port = 3306
datadir=/data/my3306
socket=/data/my3306/mysql.sock
user=mysql
pid-file=/data/my3306/mysql.pid
log=/data/my3306/mysqld.log
[3307]
port = 3307
datadir=/data/my3307
socket=/data/my3307/mysql.sock
user=mysql
pid-file=/data/my3307/mysql.pid
log=/data/my3307/mysqld.log
innobackup 2.4 在備份時會去讀 /etc/my.cnf , 如果該文件中沒有配置 server_id 則系統報錯失敗。如果沒有 /etc/my.cnf 則會去獲取數據庫實例配置的 my.cnf 而不是 my.multi.cnf ..
innobackupex: [ERROR] /usr/bin/innobackupex: Empty value for server-id specified
解決方法回退到老的版本。
2.3 備份集文件內容的變化
我們的備份命令如下:
/usr/bin/innobackupex –socket=/srv/my_3344/mysqld.sock –user=root –password= –no-timestamp –slave-info –rsync –compress –compress-threads=2 –parallel=1 /data/backup/rac1_3344/full/bk20170827105656 /data/logs/zandb_agent/backup/rac1_3344_bk20170827105656.log 2 1
使用了 compress 功能, 2.2 版本的備份集壓縮了數據庫相關的數據文件
2.4 版本的備份集文件
對自動化備份系統的影響是需要調整讀取 backup-my.cnf 的步驟，必須在解壓縮之后讀取。
關于“如何解決 MySQL 中使用 innobackup 2.4 遇到的問題”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，使各位可以學到更多知識，如果覺得文章不錯，請把它分享出去讓更多的人看到。
