【MySQL】innobackupex 長時間hang
【問題現象】
一個資料庫例項的備庫在做備份時,備份的log 一直顯示
>> log scanned up to (3015320266621)
>> log scanned up to (3015320266621)
....
>> log scanned up to (3015320266621)
>> log scanned up to (3015320266621)
>> log scanned up to (3015320266621)
長達 10多個小時。
mysql> show processlist;
+--------+-------------+--------------------+------+------------+---------+----------------------------------
| Id | User | Host | db | Command | Time |State
+--------+-------------+--------------------+------+------------+---------+----------------------------------
| 1 | system user | | NULL | Connect | 2684619 | Waiting for master to sendevent
| 2 | system user | | NULL | Connect | 31 | Waiting for release of readlock ......
4 rows in set (0.00 sec)
system使用者顯示 Waiting for release of readlock
執行備份的使用者為Xtraback 對應的time 列則每4s 迴圈一次。system user 的狀態表示 xtraback 程式已經執行了flush tables with read only,並等待xtrabackup程式釋放read lock。我們首先來了解一下xtrabackup 大致過程:
backup()並記錄XTRABACKUP_BINARY資訊
mysql_open() 啟動管道連結的子程式連線mysql
mysql_check() 檢查連線mysql的子程式是否OK,傳送一個虛擬查詢,等待mysql_response_timeout超時退出
mysql_close() 關閉連線mysql子程式
start_ibbackup() 建立子程式執行ibbackup來備份innodb資料和索引
如果不是遠端備份,不是stream模式,進入wait_for_ibbackup_suspend() 檢查ibbackup子程式是否還活著
mysql_open()
如果指定–safe-slave-backup 進入wait_for_safe_slave() ,透過每隔3s啟停sql thread來不斷檢查例項上開啟臨時表數目是否為0
mysql_check()
如果沒有指定–no-lock,進入 mysql_lockall(),執行FLUSH TABLES WITH READ LOCK;
backup_files() 複製除ibd外所有的檔案
mysql_unlockall() 執行UNLOCK TABLES
如果指定–safe-slave-backup START SLAVE SQL_THREAD
mysql_close()
問題出現在 發出flush tables with read lock 並獲取了全域性鎖(systemuser 才在等待read lock) innodb 複製除ibd外所有的檔案.
但是根據
xtrabackup原始碼
# flush tables with read lock
mysql_check(); --沒有問題
mysql_lockall() if !$option_no_lock;
# timeout in seconds for a reply from mysql
my $mysql_response_timeout = 900;
sub mysql_send {
my $request = shift;
$current_mysql_request = $request;
print MYSQL_WRITER "$request\n";
mysql_check();
$current_mysql_request = '';
}
sub mysql_lockall {
$now = current_time();
print STDERR "$now $prefix Starting to lock all tables...\n";=
mysql_send "USE mysql;";
mysql_send "SET AUTOCOMMIT=0;";
if (compare_versions($mysql_server_version, '4.0.22') == 0
|| compare_versions($mysql_server_version, '4.1.7') == 0) {
# MySQL server version is 4.0.22 or 4.1.7
mysql_send "COMMIT;";
mysql_send "FLUSH TABLES WITH READ LOCK;";
} else {
# MySQL server version is other than 4.0.22 or 4.1.7
mysql_send "FLUSH TABLES WITH READ LOCK;";
mysql_send "COMMIT;";
}
write_binlog_info;
write_slave_info if $option_slave_info;
$now = current_time();
print STDERR "$now $prefix All tables locked and flushed to disk\n";
}
--在執行flush tables with read lock時,mysql_send函式執行超時900S,備份失敗。我的例項的備份卻一直表現為log scanned up to (3015320266621)。
記錄一個疑問在這裡。
參考資料:
%E8%B6%85%E6%97%B6%E9%80%80%E5%87%BA.html
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/22664653/viewspace-754714/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 【MySQL】innobackupex長時間hangMySql
- 資料泵匯入分割槽表長時間HANG住
- 應用長時間未呼叫後再次呼叫出現hang的情況
- mysql innobackupex 物理備份MySql
- 刪除臨時表空間hang處理
- MySQL時間戳、時間MySql時間戳
- mysql innobackupex備份指令碼MySql指令碼
- mysql 時間MySql
- Mysql DDL出現長時間等待MDL問題分析MySql
- innobackupex 備份MySQL資料庫MySql資料庫
- mysql innobackupex增量備份恢復MySql
- mysql innobackupex 的一則錯誤MySql
- 【MySql】innobackupex 增量備份的bugMySql
- MySQL alter table時執行innobackupex全備再看Seconds_Behind_MasterMySqlAST
- job 執行時間比排程間隔時間長
- 使用innobackupex恢復mysql資料庫MySql資料庫
- 使用innobackupex備份mysql資料庫MySql資料庫
- 【MySql】innobackupex增量備份和恢復MySql
- MySQL增量備份的指令碼(innobackupex)MySql指令碼
- MySQL innobackupex全量備份恢復MySql
- 【MySql】innobackupex 增量備份和恢復MySql
- mysql時間操作(時間差和時間戳和時間字串的互轉)MySql時間戳字串
- mysql時間指令碼MySql指令碼
- MySQL時間函式MySql函式
- 【Mysql】innobackupex備份還原單個庫MySql
- mysql時區與時間函式MySql函式
- 學Java要多長時間?Java
- MySQL:一個奇怪的hang案例MySql
- MySQL為欄位新增預設時間(插入時間)MySql
- MySQL查詢時間段MySql
- 安裝npm install時,長時間停留NPM
- mysql之 Innobackupex(全備+增量)備份恢復MySql
- mysql innobackupex xtrabackup 大資料量 備份 還原MySql大資料
- 關於MySQL使用的時長MySql
- 基於percona xtrabackup之innobackupex實現基於時間點資料庫恢復資料庫
- mysql將時間戳轉成常用可讀時間格式MySql時間戳
- innobackupex: Error: noError
- 【Mysql】mysql主鍵的缺少導致備庫hangMySql