【MySQL】innobackupex 長時間hang

楊奇龍發表於2013-02-25
原文網址 : http://blog.itpub.net/22664653/viewspace-754714/
MySql
【問題現象】
一個資料庫例項的備庫在做備份時,備份的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/，如需轉載，請註明出處，否則將追究法律責任。

相關文章