Activity log for bug #932623

Date Who What changed Old value New value Message
2012-02-15 10:01:31 Matt bug added bug
2012-02-16 09:06:43 Matt 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/ ... $ 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. 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.
2012-02-16 09:07:19 Matt 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. 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.
2012-06-05 12:32:17 Alexey Kopytov attachment added bug932623.sh https://bugs.launchpad.net/percona-xtrabackup/+bug/932623/+attachment/3176153/+files/bug932623.sh
2012-06-05 12:32:32 Alexey Kopytov nominated for series percona-xtrabackup/2.0
2012-06-05 12:32:32 Alexey Kopytov bug task added percona-xtrabackup/2.0
2012-06-05 12:32:32 Alexey Kopytov nominated for series percona-xtrabackup/2.1
2012-06-05 12:32:32 Alexey Kopytov bug task added percona-xtrabackup/2.1
2012-06-05 12:32:46 Alexey Kopytov percona-xtrabackup/2.0: status New Triaged
2012-06-05 12:32:50 Alexey Kopytov percona-xtrabackup/2.1: status New Triaged
2012-06-05 12:32:53 Alexey Kopytov percona-xtrabackup/2.0: importance Undecided Medium
2012-06-05 12:32:56 Alexey Kopytov percona-xtrabackup/2.1: importance Undecided Medium
2012-06-05 12:32:59 Alexey Kopytov percona-xtrabackup/2.0: milestone 2.0.2
2012-06-05 12:33:01 Alexey Kopytov percona-xtrabackup/2.1: milestone 2.1-initial
2012-07-04 00:24:48 Vadim Tkachenko percona-xtrabackup/2.0: assignee Sergei Glushchenko (sergei.glushchenko)
2012-07-04 12:42:01 Sergei Glushchenko percona-xtrabackup/2.0: status Triaged In Progress
2012-07-04 12:42:04 Sergei Glushchenko percona-xtrabackup/2.1: status Triaged In Progress
2012-07-05 07:50:35 Raghavendra D Prabhu bug added subscriber Raghavendra D Prabhu
2012-07-06 05:21:34 Sergei Glushchenko branch linked lp:~sergei.glushchenko/percona-xtrabackup/xb20-bug932623
2012-07-06 05:21:46 Sergei Glushchenko percona-xtrabackup/2.0: status In Progress Fix Committed
2012-07-11 08:40:30 Sergei Glushchenko branch linked lp:~sergei.glushchenko/percona-xtrabackup/xb21-bug932623
2012-07-11 08:40:45 Sergei Glushchenko percona-xtrabackup/2.1: assignee Sergei Glushchenko (sergei.glushchenko)
2012-07-11 09:06:08 Sergei Glushchenko percona-xtrabackup/2.1: status In Progress Fix Committed
2012-08-03 05:16:04 Stewart Smith percona-xtrabackup/2.0: status Fix Committed Fix Released
2012-08-06 01:16:55 Stewart Smith percona-xtrabackup/2.1: status Fix Committed Fix Released
2012-10-29 00:21:38 Vojtech Kurka bug added subscriber Vojtech Kurka