# xtrabackup failing with log sequence number in the future and ibdata/log dont match **URL:** \ **Category:** Percona XtraBackup\ **Created:** [April 4, 2017, 9:23am UTC](https://forums.percona.com/t/xtrabackup-failing-with-log-sequence-number-in-the-future-and-ibdata-log-dont-match/5525 "2017-04-04T09:23:06Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![dcg9381](https://avatars.discourse-cdn.com/v4/letter/d/5daacb/32.png) [@dcg9381](https://forums.percona.com/u/dcg9381)\ **Post date:** [April 4, 2017, 9:23am UTC](https://forums.percona.com/t/xtrabackup-failing-with-log-sequence-number-in-the-future-and-ibdata-log-dont-match/5525/1 "2017-04-04T09:23:06Z")
Centos systems 7 and 6.5. Using innobackupex version 2.3.7 Linux (x86\_64). Basically, I’m doing an live extrabackup from a hot slave to a development database. The copy takes place successfully, but when I apply the log to the backup, I get the following errors. Source DB: innobackupex --databases=“mysql performance\_schema logging\_prod” --host=localhost --stream=tar /tmp/ --slave-info --password=BLAH | ssh [root@mysql-full.dev.allwebleads.com](mailto:root@mysql-full.dev.allwebleads.com) tar xfi - -C /var/lib/mysql Target DB: innobackupex --apply-log --ibbackup=xtrabackup /var/lib/mysql: Output: innobackupex version 2.3.7 based on MySQL server 5.6.24 Linux (x86\_64) (revision id: 40f611f) xtrabackup: cd to /var/lib/mysql/ xtrabackup: This target seems to be not prepared yet. xtrabackup: xtrabackup\_logfile detected: size=2097152, start\_lsn=(10454830773361) xtrabackup: using the following InnoDB configuration for recovery: xtrabackup: innodb\_data\_home\_dir = ./ xtrabackup: innodb\_data\_file\_path = ibdata1:12M:autoextend xtrabackup: innodb\_log\_group\_home\_dir = ./ xtrabackup: innodb\_log\_files\_in\_group = 1 xtrabackup: innodb\_log\_file\_size = 2097152 xtrabackup: using the following InnoDB configuration for recovery: xtrabackup: innodb\_data\_home\_dir = ./ xtrabackup: innodb\_data\_file\_path = ibdata1:12M:autoextend xtrabackup: innodb\_log\_group\_home\_dir = ./ xtrabackup: innodb\_log\_files\_in\_group = 1 xtrabackup: innodb\_log\_file\_size = 2097152 xtrabackup: Starting InnoDB instance for recovery. xtrabackup: Using 104857600 bytes for buffer pool (set by --use-memory parameter) InnoDB: Using atomics to ref count buffer pool pages InnoDB: The InnoDB memory heap is disabled InnoDB: Mutexes and rw\_locks use GCC atomic builtins InnoDB: Memory barrier is not used InnoDB: Compressed tables use zlib 1.2.3 InnoDB: Not using CPU crc32 instructions InnoDB: Initializing buffer pool, size = 100.0M InnoDB: Completed initialization of buffer pool InnoDB: Highest supported file format is Barracuda. InnoDB: The log sequence numbers 10391861530602 and 10391861530602 in ibdata files do not match the log sequence number 10454830773361 in the ib\_logfiles! InnoDB: Database was not shutdown normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files… InnoDB: Restoring possible half-written data pages InnoDB: from the doublewrite buffer… 2017-04-04 09:30:24 7f5404d477e0 InnoDB: Error: page 7 log sequence number 10730744849496 InnoDB: is in the future! Current system log sequence number 10454830773361. InnoDB: Your database may be corrupt or you may have copied the InnoDB InnoDB: tablespace but not the InnoDB log files. See … InnoDB: Your database may be corrupt or you may have copied the InnoDB InnoDB: tablespace but not the InnoDB log files. See InnoDB: [url][http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html[/url]](http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html%5B/url%5D) InnoDB: for more information. InnoDB: 89 transaction(s) which must be rolled back or cleaned up InnoDB: in total 0 row operations to undo InnoDB: Trx id counter is 48805225984 InnoDB: Cleaning up trx with id 48805249746 2017-04-04 09:30:24 7f5404d477e0 InnoDB: Assertion failure in thread 139998835013600 in file trx0trx.cc line 292 InnoDB: Failing assertion: trx-\>update\_undo == NULL InnoDB: We intentionally generate a memory trap. InnoDB: Submit a detailed bug report to [http://bugs.mysql.com](http://bugs.mysql.com). InnoDB: If you get repeated assertion failures or crashes, even InnoDB: immediately after the mysqld startup, there may be InnoDB: corruption in the InnoDB tablespace. Please refer to InnoDB: [url][http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html[/url]](http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html%5B/url%5D) InnoDB: about forcing recovery. 14:30:24 UTC - xtrabackup got signal 6 ; This could be because you hit a bug or data is corrupted. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. Thread pointer: 0x0 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong… stack\_bottom = 0 thread\_stack 0x10000 Pointers would be great. my.cnf files match on both machines.