mysql 備份軟體 Xtrabackup 的 xtrabackup_binlog_pos_innodb和xtrabackup_binlog_info 檔案區別

標籤：style   blog   http   color   io   os   ar   for   strong   

今天在操作 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  這個檔案。

$ lsibdata1      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_innodbmaster.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  靠譜，不知道你們是採用哪個位置？如果有什麼疑問，可以提出來大家一起探討。

 

mysql 備份軟體 Xtrabackup 的 xtrabackup_binlog_pos_innodb和xtrabackup_binlog_info 檔案區別