innobackupex ignores --databases without --stream

[Ville Skyttä]

If --stream is not given, innobackupex-1.5.1 from xtrabackup-1.2-14.rhel5 seems to ignore the --databases option and backs up all databases. If this cannot be fixed, the limitation should be documented in innobackupex-1.5.1's --help.

[Will Bryant (willbryant)]

Try using the --include option. --databases seems to affect for which databases the files other than .ibd are backed up, so I am using:

--databases="mysql myapp_production" --include="myapp_production\..*"

I'm not sure if this is the intended behavior.

[Valentine Gostev (longbow)]

Linked branch contains test

[Stewart Smith (stewart)]

Marking as Won't fix for the old stable 1.6 release. If you need a fix for this bug in 1.6, please say so here or contact us (Percona) to arrange something.

[Andrew Gaul (gaul)]

Using XtraBackup 2.0.0 I encountered the same symptoms with --databases. I worked around this with --include as suggested in comment #1.

[Alexey Kopytov (akopytov)]

In fact in XtraBackup 2.0 the --databases option has no effect for InnoDB files for both local and streaming backups, i.e. all InnoDB files are always backed up. Currently, only .frm and non-InnoDB tables are limited by that option.

[Sergei Glushchenko (sergei.glushchenko)]

I suggest to introduce --databases and --databases-file xtrabackup. --databases option of innobackupex would be mapped to one of them.

[Alexey Kopytov (akopytov)]

Bug #1274766 marked as a duplicate of this one.

[Matthew B (utdrmac)]

Just wanted to +1 this. I have a client with multiple databases but only wants 1 backed up. If I use --databases=dbToBackUp, I still get all other databases' .ibd files as demonstrated in #1274766.

Additionally, different behavior is experienced during the file phase of backups (during the .frm, MYI, MYD part). If I specify --databases=alex_and_ani_enterprise_live_new_theme, I see this:

140819 02:12:02 innobackupex: Continuing after ibbackup has suspended
140819 02:12:02 innobackupex: Executing FLUSH TABLES WITH READ LOCK...
>> log scanned up to (1286337694402)
140819 02:12:03 innobackupex: All tables locked and flushed to disk

140819 02:12:03 innobackupex: Starting to backup non-InnoDB tables and files
innobackupex: in subdirectories of '/mnt/san/mysql/mysql'
innobackupex: Backing up files '/mnt/san/mysql/mysql/alex_and_ani_enterprise_live_new_theme/*.{frm,isl,MYD,MYI,MAD,MAI,MRG,TRG,TRN,ARM,ARZ,CSM,CSV,opt,par}' (700 files)
>> log scanned up to (1286337694402)
140819 02:12:04 innobackupex: Finished backing up non-InnoDB tables and files

140819 02:12:04 innobackupex: Executing FLUSH ENGINE LOGS...
140819 02:12:04 innobackupex: Waiting for log copying to finish

xtrabackup: The latest check point (for incremental): '1286337692872'
xtrabackup: Stopping log copying thread.
.>> log scanned up to (1286337694402)

xtrabackup: Creating suspend file '/mnt/san/backups/20140819_full/xtrabackup_log_copied' with pid '25308'
xtrabackup: Transaction log of lsn (1286331699845) to (1286337694402) was copied.
140819 02:12:05 innobackupex: All tables unlocked

==== But if I do this, --include='^alex_and_ani_enterprise_live_new_theme\.*' I see this:

140819 09:29:05 innobackupex: Executing FLUSH TABLES WITH READ LOCK...
>> log scanned up to (1286949139524)
140819 09:29:05 innobackupex: All tables locked and flushed to disk

140819 09:29:05 innobackupex: Starting to backup non-InnoDB tables and files
innobackupex: in subdirectories of '/mnt/san/mysql/mysql'
innobackupex: Backing up files '/mnt/san/mysql/mysql/performance_schema/*.{frm,isl,MYD,MYI,MAD,MAI,MRG,TRG,TRN,ARM,ARZ,CSM,CSV,opt,par}' (18 files)
innobackupex: Backing up files '/mnt/san/mysql/mysql/alex_and_ani_test_db/*.{frm,isl,MYD,MYI,MAD,MAI,MRG,TRG,TRN,ARM,ARZ,CSM,CSV,opt,par}' (534 files)
innobackupex: Backing up files '/mnt/san/mysql/mysql/mysql/*.{frm,isl,MYD,MYI,MAD,MAI,MRG,TRG,TRN,ARM,ARZ,CSM,CSV,opt,par}' (72 files)
innobackupex: Backing up files '/mnt/san/mysql/mysql/alex_and_ani_magento_loadtesting/*.{frm,isl,MYD,MYI,MAD,MAI,MRG,TRG,TRN,ARM,ARZ,CSM,CSV,opt,par}' (700 files)
percona.checksums.frm is skipped because it does not match '^alex_and_ani_enterprise_live_new_theme\.*'.
percona.db.opt is skipped because it does not match '^alex_and_ani_enterprise_live_new_theme\.*'.
innobackupex: Backing up files '/mnt/san/mysql/mysql/alex_and_ani_wordpress_loadtesting/*.{frm,isl,MYD,MYI,MAD,MAI,MRG,TRG,TRN,ARM,ARZ,CSM,CSV,opt,par}' (34 files)
innobackupex: Backing up files '/mnt/san/mysql/mysql/alex_and_ani_wordpress_staging/*.{frm,isl,MYD,MYI,MAD,MAI,MRG,TRG,TRN,ARM,ARZ,CSM,CSV,opt,par}' (34 files)
innobackupex: Backing up files '/mnt/san/mysql/mysql/alex_and_ani_enterprise_live_new_...

[Shahriyar Rzayev (rzayev-sehriyar)]

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PXB-4