mysql xtrabackup 遭遇嚴重bug
我們的mysql 備份系統遭遇嚴重bug
源於 開源軟體 xtrabackup 的一個bug
之前我們的大規模部署都沒有遇到這問題。
在做計數器轉mysql 後,我們部署了備份系統,屢屢備份失敗,於是決定徹底的解決這個問題,
經過一系列測試後,發現在備份過程無法跨越 計數器的資料入庫操作,
備份系統報錯:
[code]
[01] Copying ./cnt_it/cnt_referrer_channel_2011.ibd
to /usr/local/mysql/crontab/cnt_it/backup/innodb/full/2011-06-10_18-18-25/cnt_it/cnt_referrer_channel_2011.ibd
[01] ...done
[01] Copying ./cnt_it/cnt_goals_abandon_201109.ibd
to /usr/local/mysql/crontab/cnt_it/backup/innodb/full/2011-06-10_18-18-25/cnt_it/cnt_goals_abandon_201109.ibd
[01] ...done
[01] Copying ./cnt_it/cnt_referrer_search_keyword_201107.ibd InnoDB: Error: tablespace id is 43167 in the data dictionary
InnoDB: but in file ./cnt_it/cnt_referrer_summary_work.ibd it is 43178!
110610 18:37:57 InnoDB: Assertion failure in thread 1201920320 in file /home/buildbot/slaves/percona-server-51-12/TGZ_CentOS_5_x86_64/work/xtrabackup-1.6/Percona-Server-5.5/storage/innobase/fil/fil0fil.c line 780
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
to /usr/local/mysql/crontab/cnt_it/backup/innodb/full/2011-06-10_18-18-25/cnt_it/cnt_referrer_search_keyword_201107.ibd
[01] ...done
[01] Copying ./cnt_it/cnt_goals_referrer_201205.ibd
to /usr/local/mysql/crontab/cnt_it/backup/innodb/full/2011-06-10_18-18-25/cnt_it/cnt_goals_referrer_201205.ibd
[01] ...done
./backup.sh: line 109: 24002 備份失敗 xtrabackup --defaults-file=$CNF --backup --target-dir=$BACKUP/$ENGINE/full/$day --datadir=$DATADIR
+ return 1
+ critical
+ df -h
[/code]
上面是什麼問題呢?
就是說在備份過程中,資料庫的表不能rebuild 操作,比如: truncate table , drop table ,並重新建表 這樣的操作。
從報錯資訊上看,應該是xtrabackup 已經考慮到這個問題了,只是當時沒有處理,於是在相關的程式碼處加了一個assertion
程式碼這個地方出錯,就退出。
這個bug 在1.5,1.5.1 ,1.6 版本都存在這個問題。 要到1.7版本才能修復。
慢慢等吧!
目前替代方案,採用備份從庫解決。
源於 開源軟體 xtrabackup 的一個bug
之前我們的大規模部署都沒有遇到這問題。
在做計數器轉mysql 後,我們部署了備份系統,屢屢備份失敗,於是決定徹底的解決這個問題,
經過一系列測試後,發現在備份過程無法跨越 計數器的資料入庫操作,
備份系統報錯:
[code]
[01] Copying ./cnt_it/cnt_referrer_channel_2011.ibd
to /usr/local/mysql/crontab/cnt_it/backup/innodb/full/2011-06-10_18-18-25/cnt_it/cnt_referrer_channel_2011.ibd
[01] ...done
[01] Copying ./cnt_it/cnt_goals_abandon_201109.ibd
to /usr/local/mysql/crontab/cnt_it/backup/innodb/full/2011-06-10_18-18-25/cnt_it/cnt_goals_abandon_201109.ibd
[01] ...done
[01] Copying ./cnt_it/cnt_referrer_search_keyword_201107.ibd InnoDB: Error: tablespace id is 43167 in the data dictionary
InnoDB: but in file ./cnt_it/cnt_referrer_summary_work.ibd it is 43178!
110610 18:37:57 InnoDB: Assertion failure in thread 1201920320 in file /home/buildbot/slaves/percona-server-51-12/TGZ_CentOS_5_x86_64/work/xtrabackup-1.6/Percona-Server-5.5/storage/innobase/fil/fil0fil.c line 780
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
to /usr/local/mysql/crontab/cnt_it/backup/innodb/full/2011-06-10_18-18-25/cnt_it/cnt_referrer_search_keyword_201107.ibd
[01] ...done
[01] Copying ./cnt_it/cnt_goals_referrer_201205.ibd
to /usr/local/mysql/crontab/cnt_it/backup/innodb/full/2011-06-10_18-18-25/cnt_it/cnt_goals_referrer_201205.ibd
[01] ...done
./backup.sh: line 109: 24002 備份失敗 xtrabackup --defaults-file=$CNF --backup --target-dir=$BACKUP/$ENGINE/full/$day --datadir=$DATADIR
+ return 1
+ critical
+ df -h
[/code]
上面是什麼問題呢?
就是說在備份過程中,資料庫的表不能rebuild 操作,比如: truncate table , drop table ,並重新建表 這樣的操作。
從報錯資訊上看,應該是xtrabackup 已經考慮到這個問題了,只是當時沒有處理,於是在相關的程式碼處加了一個assertion
程式碼這個地方出錯,就退出。
這個bug 在1.5,1.5.1 ,1.6 版本都存在這個問題。 要到1.7版本才能修復。
慢慢等吧!
目前替代方案,採用備份從庫解決。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/133735/viewspace-697815/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- oracle ucm 的嚴重bugOracle
- 遭遇mysql 5.6.10 BUG 一例MySql
- MySQL8.0.32版本一個嚴重Bug及解決方案MySql
- 談談BUG嚴重級別(severity)管理
- 【MySQL】xtrabackup 2.4.12備份觸發的bugMySql
- MySQL 5.6 遭遇 OS bug INNODB MONITOR OUTPUT 事件MySql事件
- Bittrex交易平臺遭遇提現嚴重延遲問題
- Gitea 釋出 1.0.2 版本,修正幾個嚴重的 bugGit
- Linux核心修正5年曆史的嚴重bugLinux
- [ZT]智慧ABC一嚴重Bug可使任意程式崩潰
- 越南的遊戲市場同樣遭遇了嚴重的“盜版問題”遊戲
- 少年黑客發現MacOS鑰匙串中的嚴重BUG黑客Mac
- 軟體Bug引發的十次嚴重後果
- 軟體 Bug 引發的十次嚴重後果
- MySQL:xtrabackup備份MySql
- MySQL Percona XtraBackupMySql
- XtraBackup備份MySQLMySql
- Gitea 釋出 1.0.2版本,修正幾個嚴重的bugGit
- oracle 10.2.4 遭遇bug 當機Oracle
- MySQL8.0之XtraBackupMySql
- xtrabackup備份mysql innodbMySql
- 暫緩MongoDB 4.4.2 、4.4.3、 4.4.4版本升級: 存在嚴重BugMongoDB
- Facebook遭遇有史以來最嚴重當機事件,罪魁禍首與DNS故障有關?事件DNS
- 【MySql】 MySql備份工具Xtrabackup之二MySql
- 【MySql】 MySql備份工具Xtrabackup之一MySql
- 軟體測試培訓分享:如何劃分bug的嚴重級別
- delete操作時遭遇ora-600 bug[kntgslm]delete
- 計算機史上最嚴重漏洞被公開,風險等級嚴重計算機
- 使用Xtrabackup遠端備份MysqlMySql
- MySQL xtrabackup for centos7.2安裝MySqlCentOS
- Percona Xtrabackup 快速備份 MySQLMySql
- Taurine越獄工具迎來重大更新 修復嚴重Bug並改善電池續航
- mysql之 xtrabackup-2.4.12 安裝MySql
- 配置xtrabackup備份mysql資料庫MySql資料庫
- 使用Xtrabackup備份mysql資料庫MySql資料庫
- XtraBackup 2.2.8 釋出,MySQL 備份工具MySql
- Mysql 物理備份工具xtrabackup的使用MySql
- MySQL 備份軟體 Xtrabackup 的 xtrabackup_binlog_pos_innodb和xtrabackup_binlog_info 檔案區別MySql