Issues with renaming/rotating tables during the backup stage
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Percona XtraBackup moved to https://jira.percona.com/projects/PXB |
Fix Released
|
High
|
Alexey Kopytov | ||
| 2.0 |
Fix Released
|
High
|
Alexey Kopytov | ||
| 2.1 |
Fix Released
|
High
|
Alexey Kopytov | ||
Bug Description
Reporting https:/
RENAME TABLE run during the backup breaks our backup even it is not incremental:
-- versions -------
mysql --version
mysql Ver 14.14 Distrib 5.5.23, for Linux (x86_64) using readline 5.1
xtrabackup_55 -v
xtrabackup_55 version 2.0.3 for Percona Server 5.5.16 Linux (x86_64) (revision id: 470)
-- The problem occurs when applying log ------------
innobackupex --apply-log --use-memory=48GB /data/db_restore
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Error: trying to add tablespace 2788 of name './db2/
InnoDB: to the tablespace memory cache, but tablespace
InnoDB: 2788 of name './db2/
InnoDB: memory cache!
innobackupex: Error:
innobackupex: ibbackup failed at /usr/bin/
-- -------
The problem occurs always when this RENAME TABLE is done while the backup is being taken:
RENAME TABLE `ShopOfferAvgPo
Related branches
- Laurynas Biveinis (community): Approve
-
Diff: 2342 lines (+854/-211)11 files modifiedpatches/innodb51.patch (+116/-22)
patches/innodb51_builtin.patch (+123/-21)
patches/innodb55.patch (+118/-22)
patches/innodb56.patch (+102/-26)
patches/xtradb51.patch (+118/-25)
patches/xtradb55.patch (+106/-23)
src/xtrabackup.cc (+105/-39)
test/inc/common.sh (+19/-0)
test/t/ddl.sh (+37/-31)
test/testrun.sh (+3/-1)
utils/build.sh (+7/-1)
- Laurynas Biveinis (community): Approve
-
Diff: 1977 lines (+750/-183)9 files modifiedpatches/innodb51.patch (+116/-22)
patches/innodb55.patch (+105/-22)
patches/innodb56.patch (+102/-26)
patches/xtradb51.patch (+118/-25)
patches/xtradb55.patch (+106/-23)
src/fil_cur.cc (+104/-27)
src/fil_cur.h (+1/-0)
src/xtrabackup.cc (+61/-7)
test/t/ddl.sh (+37/-31)
| Alexey Kopytov (akopytov) wrote | #1 |
| Alexey Kopytov (akopytov) wrote | #2 |
| summary: |
- Issues with rotating tables during the backup stage + Issues with renaming/rotating tables during the backup stage |
| Shahriyar Rzayev (rzayev-sehriyar) wrote | #3 |
The reason is that even though we iterate and copy .ibd files based on a "data dictionary snapshot" (actually, a list of tablespaces represented by a fil_system_t structure) taken before starting a backup, we don't validate if the files being copied are consistent with that snapshot.
Consider the following case.
- before taking a backup there are tables t1 and t2 in fil_system.
- after t1 has been copied by xtrabackup, we do RENAME TABLE t1 TO temp, t2 TO t1, temp TO t2;
- xtrabackup then copies t2 (which is in fact the original t1)
As a result, the backup will contain two identical (i.e. with same ID) tables with different names, and the original table t2 will be lost.
I think the only way to guarantee that files being copied are consistent with the snapshot created before starting the backup is to reuse file handles created when populating the list in fil_system_struct, rather than reopen files by their names as we do currently.
However, there's still a possibility of table rotation occurring while fil_system is being populated before the backup. But in this case xtrabackup will fail with an InnoDB error message about duplicate tablespace IDs before copying any files. I.e. at least it will not create a broken backup.