Not the answer you need?
Register and ask your own question!

Hit an old bug ? ( InnoDB data dictionary != tablespace )

rockandskarockandska EntrantInactive User Role Beginner
Hello ,

I'm facing a problem with a backup than i've tried to prepare.

This is the situation :
Host to backup:
Debian Squeeze
MariaDb 5.2.4
xtrabackup version 2.2.9
New Host:
Debian Wheezy
MariaDb 5.5.42
xtrabackup version 2.2.9

My backup has finished with :
50307 02:24:08  innobackupex: completed OK!
Some warnings at the begining:
150306 19:17:08  innobackupex: Warning: FLUSH ENGINE LOGS is not supported by the server. Data may be inconsistent with binary log coordinates!
But it failed when i tried to prepare the backup :/
......
......
InnoDB: Trx id counter is 8397891584
InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
InnoDB: Last MySQL binlog file position 0 1868814, file name /home/mysql/log/mariadb-bin.037316
2015-03-10 10:36:40 64bfd7fe7720  InnoDB: Error: table 'test_tmp/CP_VO_2013_03_26'
InnoDB: in InnoDB data dictionary has tablespace id 101137,
InnoDB: but the tablespace with that id has name STRUCTURE/CP_VO_2013_03_26.
.....
.....
[INDENT]etc...
InnoDB: Table test_tmp/Q_FIELD_11142_1 in the InnoDB data dictionary has tablespace id 100386, but tablespace with that id or name does not exist. Have you deleted or moved .ibd files? This may also be a table created with CREATE TEMPORARY TABLE whose .ibd and .frm files MySQL automatically removed, but the table still exists in the InnoDB internal data dictionary.
InnoDB: It will be removed from the data dictionary.[/INDENT]  [INDENT].....
.....
etc...
2015-03-10 10:36:43 64bfc9e16700  InnoDB: Rollback of non-prepared transactions completed

notice (again)
  If you use binary log and don't use any hack of group commit,
  the binary log position seems to be:
InnoDB: Last MySQL binlog file position 0 1868814, file name /home/mysql/log/mariadb-bin.037316

xtrabackup: ########################################################
xtrabackup: # !!WARNING!!                                          #
xtrabackup: # The transaction log file is corrupted.               #
xtrabackup: # The log was not applied to the intended LSN!         #
xtrabackup: ########################################################
xtrabackup: The intended lsn is 10338665879040
xtrabackup: starting shutdown with innodb_fast_shutdown = 1
InnoDB: FTS optimize thread exiting.
InnoDB: Starting shutdown...
InnoDB: Shutdown completed; log sequence number 10338665891853

150310 10:37:18  innobackupex: Restarting xtrabackup with command: xtrabackup  --defaults-file="/home/backup/backup-my.cnf"  --defaults-group="mysqld" --prepare --target-dir=/home/backup
for creating ib_logfile*
....
....
InnoDB: Renaming log file ./ib_logfile101 to ./ib_logfile0
InnoDB: New log files created, LSN=10338665891853
InnoDB: Highest supported file format is Barracuda.
2015-03-10 10:37:59 6ad7ba69e720  InnoDB: Operating system error number 2 in a file operation.
InnoDB: The error means the system cannot find the path specified.
InnoDB: If you are installing InnoDB, remember that you must create
InnoDB: directories yourself, InnoDB does not create them.
InnoDB: Could not find a valid tablespace file for 'test_tmp/CP_VO_2013_03_26'. See http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting-datadict.html for how to resolve the issue.
InnoDB: It will be removed from the data dictionary.[/INDENT]  [INDENT]....
....
etc....
InnoDB: 1 rollback segment(s) are active.
InnoDB: Waiting for purge to start
InnoDB: 5.6.22 started; log sequence number 10338665892364
InnoDB: Error: tablespace id is 100384 in the data dictionary
InnoDB: but in file ./test_tmp/FIELD_LIST_FOR_TABLE_10313.ibd it is 167234!
2015-03-10 10:38:04 6ad7ba69e720  InnoDB: Assertion failure in thread 117474778015520 in file fil0fil.cc line 582
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to 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: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
09:38:04 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: 0x345fe20
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
xtrabackup(my_print_stacktrace+0x2b) [0x8ed17b]
xtrabackup(handle_fatal_signal+0x252) [0x7991a2]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xf0a0) [0x6ad7ba2800a0]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35) [0x6ad7b889b165]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x180) [0x6ad7b889e3e0]
xtrabackup() [0x608571]
xtrabackup() [0x608649]
xtrabackup(fil_io(unsigned long, bool, unsigned long, unsigned long, unsigned long, unsigned long, unsigned long, void*, void*)+0x147) [0x6104b7]
xtrabackup() [0x6e57fd]
xtrabackup(buf_read_page(unsigned long, unsigned long, unsigned long)+0x44) [0x6e5ea4]
xtrabackup(buf_page_get_gen(unsigned long, unsigned long, unsigned long, unsigned long, buf_block_t*, unsigned long, char const*, unsigned long, mtr_t*)+0x22e) [0x67d71e]
xtrabackup(main+0x1dc1) [0x5c0931]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd) [0x6ad7b8887ead]
xtrabackup() [0x5d195d]

Please report a bug at https://bugs.launchpad.net/percona-xtrabackup
innobackupex: got a fatal error with the following stacktrace: at /usr/bin/innobackupex line 2654
    main::apply_log() called at /usr/bin/innobackupex line 1570
innobackupex: Error:
innobackupex: xtrabackup (2nd execution) failed at /usr/bin/innobackupex line 2654.[/INDENT]

Is there someone who faced the same problem ?

Do you think could it be related to this bugs ? https://bugs.launchpad.net/percona-x...up/+bug/722638


Best regards,

Edit:
Bug report submit : https://bugs.launchpad.net/percona-xtrabackup/+bug/1430266

Comments

  • jriverajrivera Percona Support Engineer Percona Staff Role
    I just tried to reproduce this with exact MariaDB version and OS on source and exact MariaDB version and OS on destination as shown above but create and prepare phase using both xtrabackup-2.1.9 and xtrabackup-2.2.9 worked.

    Can you share full commands used to create and prepare the backups?
Sign In or Register to comment.

MySQL, InnoDB, MariaDB and MongoDB are trademarks of their respective owners.
Copyright ©2005 - 2020 Percona LLC. All rights reserved.