MySQL Bugs: #54454: MEB: innobackup --databases does not create ibbackup_binlog

Bug #54454	MEB: innobackup --databases does not create ibbackup_binlog_marker.frm
Submitted:	12 Jun 2010 10:32	Modified:	8 Feb 2011 17:55
Reporter:	Ingo Strüwing	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Enterprise Backup	Severity:	S2 (Serious)
Version:	1.5.2, 1.7.1-rc	OS:	Any
Assigned to:	Ingo Strüwing	CPU Architecture:	Any

Description:
innobackup --database <regex> in conjunction with --innodb-file-per-table=1 creates mysql/ibbackup_binlog_marker.ibd in the backup directory, but not mysql/ibbackup_binlog_marker.frm.

innobackup --copy-back does not create one either. The result is an orphaned table mysql.ibbackup_binlog_marker, which cannot be dropped, nor a new one can be created.

This means that another backup doesn't work because mysql.ibbackup_binlog_marker cannot be created.

How to repeat:
You can use the test case innobackup3 from mysql-5.1-meb.

Suggested fix:
Copy mysql/ibbackup_binlog_marker.frm from datadir to backup dir after creation of the table.

Unacceptable workaround is to remove $DATADIR/mysql/ibbackup_binlog_marker.ibd manually before backup.

Sorry, the option is --databases, not --database. And it takes a list of fatabases, not a regular expression. It is just a typo in this bug report. The behavior is described correctly.

True. But often there is no InnoDB table in the mysql database. So why would a user want to add it to the list of databases?

Is a user expected to know that IHB creates an InnoDB table "mysql.ibbackup_binlog_marker", and therefore needs to include the mysql database unconditionally?

IMHO, that special table is an IHB internal affair and thus deserves special handling. It shouldn't be a problem to copy its .frm to backup dir immediately after creating it. Even if it turns out later that the mysql frms had to be included anyway, it shouldn't hurt to copy it again.

Approved on June 17.

Per Pekka:

Support for ibbackup_binlog_marker has been in innobackup since version
1.0.

The --databases option was introduced in innobackup 1.5.0 (released on
September 29, 2008). This feature was contributed by Paddy Sreenivasan
of Zmanda, Inc. (paddy at zmanda.com).

Ingo: IMHO it means that the bug was already in the wild. So it would be nice
to have a changelog entry for it.

Per Pekka:

Support for ibbackup_binlog_marker has been in innobackup since version
1.0.

The --databases option was introduced in innobackup 1.5.0 (released on
September 29, 2008). This feature was contributed by Paddy Sreenivasan
of Zmanda, Inc. (paddy at zmanda.com).

Ingo: IMHO it means that the bug was already in the wild. So it would be nice
to have a changelog entry for it.

Adding to the 3.5.0 change log:

The innobackup or mysqlbackup command could create an orphaned table
in the backup directory. The file mysql/ibbackup_binlog_marker.ibd
was created in the backup directory, but not
mysql/ibbackup_binlog_marker.frm. The resulting table
mysql.ibbackup_binlog_marker could not be dropped or re-created,
which could prevent subsequent backups from succeeding. This
condition could occur when a partial backup was created with the
--databases option, and the database had multiple tablespaces from
the setting --innodb-file-per-table=1. Now, the .frm file for this
internally produced table is copied into the backup without the table
being specified as part of the --databases argument list.