今天在操作 innobackupex 的時候，執行 change master to 的時候發現 xtrabackup_binlog_pos_innodb xtrabackup_binlog_info 兩個檔案對應的master 的 binary log 位置不一致：
less xtrabackup_binlog_info mysql-bin.002961 70176740
less xtrabackup_binlog_pos_innodb mysql-bin.002961 38716155
後面我就找了下這兩個引數究竟是有什麼區別
1.官網上的定義：
xtrabackup_binlog_pos_innodb containing the position of the binary log at the moment of backing up relative to InnoDB transactions;
xtrabackup_binlog_info containing the position of the binary log at the moment of backing up;
2.別人的講述：
這是另外一個人的部落格講述：http://julyclyde.org/?p=403
3.官網上的一種做法：
How to setup a slave for replication in 6 simple steps with Percona XtraBackup
4.個人理解：
1）官網上的demo 是 cat /var/lib/mysql/xtrabackup_binlog_info TheMaster-bin.000001 481 ，並且是第一個二進位制日誌，所以很有可能 xtrabackup_binlog_pos_innodb xtrabackup_binlog_info 記錄的是相同的二進位制位置。
2）我首先根據官網上的操作按照 xtrabackup_binlog_info 記錄的 mysql-bin.002961 70176740 來執行 change master to *** master_log_file='mysql-bin.002961',master_log_pos=70176740 *** ,在執行 show slave status \G 的時候發現下面的錯誤：
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Client requested master to start replication from impossible position; the first event 'mysql-bin.002961' at 70176740, the last event read from '/home/mysql/node-2/mysql-bin.002961' at 4, the last byte read from '/home/mysql/node-2/mysql-bin.002961' at 4.'
3）本人 stop slave ，然後按照 xtrabackup_binlog_pos_innodb 記錄的位置 38716155 執行了 下面的命令， start slave 以後，結果顯示正常，change master to *** master_log_file='mysql-bin.002961',master_log_pos=38716155***
我用的版本是Xtrabackup-1.6.7， 從這個裡面可以看出，要保證有 InnoDB 的事務也能夠正常的從 master 獲取binary log ，應該是按照 xtrabackup_binlog_pos_innodb 記錄的位置來的，而且通過 innobackupex 的 copy-back 命令執行以後， 資料目錄（引數檔案裡面配置的 datadir 目錄）下只有 xtrabackup_binlog_pos_innodb，並沒有 xtrabackup_binlog_info 這個檔案。
$ ls
ibdata1 mysql mysqld.log mysqld-relay-bin.index relay-log.info ***
ib_logfile0 mysql-bin.000001 mysqld.pid mysqld.sock test ****
ib_logfile1 mysql-bin.000002 mysqld-relay-bin.000006 mysql-slow.log *** xtrabackup_binlog_pos_innodb
master.info mysql-bin.index mysqld-relay-bin.000007 performance_schema *** xtrabackup_checkpoints
5.我平時的做法：
我總是執行到 copy-back 以後，然後 檢視 datadir 目錄下的 xtrabackup_binlog_pos_innodb binary log position 。然後執行 change master 命令 。今天偶爾的去看備份目錄下有兩個 xtrabackup_binlog_pos 相關的檔案，結果還不一致，最終導致了上面的錯誤。
6.個人總結：
可能我用的是低版本的原因，在高版本上的解釋如下
http://www.percona.com/doc/percona-xtrabackup/2.1/xtrabackup_bin/working_with_binary_logs.html
http://www.percona.com/doc/percona-xtrabackup/1.6/xtrabackup_bin/working_with_binary_logs.html
If your backup is from a server with binary logging enabled, xtrabackup will create a file named xtrabackup_binlog_info in the target directory. This file contains the binary log file name and position of the exact point in the binary log to which the prepared backup corresponds.
You will also see output similar to the following during the prepare stage:
.....
This output can also be found in the xtrabackup_binlog_pos_innodb file, but it is only correct when no other than XtraDB or InnoDB are used as storage engines.
If other storage engines are used (i.e. MyISAM), you should use the xtrabackup_binlog_info file to retrieve the position.
這是 Xtrabackup 2.1 上面的解釋 （1.6 上面的也是類似的）, 這個意思和我理解的正好相反，他們建議採用的是 xtrabackup_binlog_info 上面記錄的二進位制日誌位置，可是事實上我每次都採用的是 xtrabackup_binlog_pos_innodb （大部分情況下兩個檔案記錄的位置是相同的），並且並沒有出錯過。
個人感覺採用 xtrabackup_binlog_pos_innodb 靠譜，不知道你們是採用哪個位置？如果有什麼疑問，可以提出來大家一起探討。
====更新 2015-5-6 13:17:54 ====
最近我用 percona-xtrabackup-2.0.3 備份的時候出現了這樣子情況，
$ less xtrabackup_binlog_pos_innodb
/home/dba/mysqlnode/nodedata3/mysql-bin.000002 0
$ cat xtrabackup_binlog_info
mysql-bin.000002 335293969
發現 xtrabackup_binlog_info 比較正確，真的是感覺版本問題。。我還是按照官網遵從 xtrabackup_binlog_info 指定的算了，建議大家採用高版本的備份軟體備份 MySQL 5.5 及以上的吧。