Comment 8 for bug 932623

Revision history for this message
Vojtech Kurka (vojtech-kurka) wrote : Re: [Bug 932623] Re: RENAME TABLE causes incremental prepare to fail

OK, thank you Alexey :)

Best regards,

Vojtech

On Fri, Nov 16, 2012 at 3:37 PM, Alexey Kopytov
<email address hidden> wrote:
> Vojtech,
>
> Thanks for the report. It appears to be a different issue, so I reported
> it as bug #1079700.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/932623
>
> Title:
> RENAME TABLE causes incremental prepare to fail
>
> Status in Percona XtraBackup:
> Fix Released
> Status in Percona XtraBackup 2.0 series:
> Fix Released
> Status in Percona XtraBackup 2.1 series:
> Fix Released
>
> Bug description:
> Issue we're seeing is that renaming a table after taking and preparing
> a full backup but before taking and applying an incremental backup is
> causing the incremental prepare step to fail with the following error.
> Backup in total is about 180GB in size, and the tables here are ~3MB
> and ~70,000 rows. We use the renames to rotate a set of tables in
> order to introduce some new data to the system. Our workaround for
> this at the moment is to convert the tables to MyISAM so that they're
> not part of the incremental step.
>
> Relevant tables:
> ---
> mytable
> mytable_old
>
> Rotate process:
> ---
> CREATE TABLE mytable_temp [ ... ]
> LOAD DATA INFILE data INTO TABLE mytable_temp
> DROP TABLE IF EXISTS mytable_old
> RENAME TABLE mytable TO mytable_old
> RENAME TABLE mytable_temp TO mytable
> ANALYZE TABLE mytable
>
> Backup process:
> ---
> $ innobackupex --no-timestamp /backup/full/
> ...
> $ innobackupex --apply-log --redo-only --use-memory=16GB /backup/full/
> ...
>
> [ ROTATE HAPPENS HERE ]
>
> $ innobackupex --no-timestamp --incremental --incremental-basedir=/backup/full/ /backup/inc01/
> ...
> $ innobackupex --apply-log --redo-only --use-memory=16GB --incremental-dir=/backup/inc01/ /backup/full/
> [ ... APPLYING DELTA FILES UP TO HERE ... ]
> xtrabackup: Temporary instance for recovery is set as followings.
> xtrabackup: innodb_data_home_dir = ./
> xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend
> xtrabackup: innodb_log_group_home_dir = /backup/inc01/
> xtrabackup: innodb_log_files_in_group = 1
> xtrabackup: innodb_log_file_size = 562397184
> 120214 15:25:58 InnoDB: Using Linux native AIO
> xtrabackup: Starting InnoDB instance for recovery.
> xtrabackup: Using 17179869184 bytes for buffer pool (set by --use-memory parameter)
> 120214 15:25:58 InnoDB: The InnoDB memory heap is disabled
> 120214 15:25:58 InnoDB: Mutexes and rw_locks use GCC atomic builtins
> 120214 15:25:58 InnoDB: Compressed tables use zlib 1.2.3
> 120214 15:25:58 InnoDB: Using Linux native AIO
> 120214 15:25:58 InnoDB: Warning: innodb_file_io_threads is deprecated. Please use innodb_read_io_threads and innodb_write_io_threads instead
> 120214 15:25:58 InnoDB: Initializing buffer pool, size = 16.0G
> 120214 15:25:59 InnoDB: Completed initialization of buffer pool
> 120214 15:25:59 InnoDB: highest supported file format is Barracuda.
> InnoDB: Log scan progressed past the checkpoint lsn 9195483965206
> 120214 15:25:59 InnoDB: Database was not shut down normally!
> InnoDB: Starting crash recovery.
> InnoDB: Reading tablespace information from the .ibd files...
> InnoDB: Error: trying to add tablespace 6558 of name './database/mytable.ibd'
> InnoDB: to the tablespace memory cache, but tablespace
> InnoDB: 6558 of name './database/mytable_old.ibd' already exists in the tablespace
> InnoDB: memory cache!
> innobackupex: Error:
> innobackupex: ibbackup failed at /usr/bin/innobackupex line 349.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/percona-xtrabackup/+bug/932623/+subscriptions