最近在我們線上庫物理備份的時候出現(xiàn)一個奇怪的現(xiàn)象：
我們備份都在從庫上備份的，在業(yè)務(wù)低一般是在晚上2點鐘開始備份.有天發(fā)現(xiàn)從庫的延遲一直在增加，登錄上實例，通過show processlist 發(fā)現(xiàn)，sql 線程在等待 binlog lock。同時看到我們從2點鐘開始的壓縮遠程備份并沒有完成，備份日志還在掃面ibd文件。
那么這個binlog lock 是誰持有的呢？仔細想想我們的業(yè)務(wù)場景，這是一個只讀從庫，且?guī)焐媳銢]有提供任何讀的服務(wù)，唯一的一個疑點就是我們的備份導(dǎo)致的，通過show processlist 可以看到，Time列的數(shù)值 均是18510，兩個時間上邊吻合，那么問題可以初步確認是由于備份引起的。
mysql> show processlist;
+---------+-------------+-----------+------------+---------+-------+-----------------+
| Id | User | Host | db | Command | Time | State | Info | Rows_sent | Rows_examined |
+---------+-------------+-----------+------------+---------+-------+-----------------+
| 4613465 | system user | | NULL | Connect | 65348 | Waiting for master to send event | NULL | 0 | 0 |
| 4613466 | system user | | NULL | Connect | 18510 | Waiting for binlog lock | NULL | 0 | 0 |
| 4631056 | dbbackup | localhost | NULL | Sleep | 18510 | | NULL | 0 | 0 |
進一步的，我們?nèi)フ艺夜傥?，看看什么時候xtrabackup 會用到這個binlog lock 呢？截取一段出來：
LOCK TABLES FOR BACKUP
... copy .frm, MyISAM, CSV, etc. ...
LOCK BINLOG FOR BACKUP
UNLOCK TABLES
... get binlog coordinates ...
... wait for redo log copying to finish ...
UNLOCK BINLOG
可以看到，Binlog Lock是在備份的尾聲階段，是為了在獲取Master 或者slave 的一致性位置點而是用的。
那么問題來了， 我們的備份現(xiàn)在是到了那個階段呢？如果已經(jīng)到了尾聲階段，那么這個鎖Binlog的過程應(yīng)該是很短暫的。
為了確認我們當前備份的一個狀態(tài)， 使用strace -p{pid} 來看一下，當前xtrabackup、innobackupex 都在做些什么事情。
在通過strace 查看這個進程到底在做什么事之前， 我們先來看看一些前埔的知識：
由于我們備份MySQL 是主要用到 innobackupex 和 xtrabackup，前者是一個 perl 腳本，后者是 C/C++ 編譯的二進制。
xtrabackup 是用來備份 InnoDB 表的，不能備份非 InnoDB 表，和 mysqld server 沒有交互；而innobackupex 腳本用來備份非 InnoDB 表，同時會調(diào)用 xtrabackup 命令來備份 InnoDB 表，還會和 mysqld server 發(fā)送命令進行交互，如加讀鎖（FTWRL）、獲取位點（SHOW SLAVE STATUS）等。簡單來說，innobackupex 在 xtrabackup 之上做了一層封裝。
一般情況下，我們是希望能備份 MyISAM 表的，雖然我們可能自己不用 MyISAM 表，但是 mysql 庫下的系統(tǒng)表是 MyISAM 的，因此備份基本都通過 innobackupex 命令進行；另外一個原因是我們可能需要保存位點信息。
那么一個perl腳步和C程序是如何進行通信的呢？它們是如何知道撒時候該執(zhí)行什么步驟的呢？
2個工具之間的交互和協(xié)調(diào)
