今天在操作 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  靠谱，不知道你们是采用哪个位置？如果有什么疑问，可以提出来大家一起探讨。

原文：http://www.cnblogs.com/liushuiwuqing/p/4014339.html