ib_lru_dump streaming fails with --stream=tar

Bug #1216648 reported by markus_albe on 2013-08-25
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Percona Server moved to https://jira.percona.com/projects/PS

Bug Description

Seems ib_lru_dump will sometimes get updated just as it's being streamed, which causes the following issue with xtrabackup 2.0.7 (and likely others):

xtrabackup: Streaming transaction log from a temporary file...
130824 15:43:52 innobackupex: Waiting for ibbackup (pid=36484) to finish
xtrabackup: Done.
xtrabackup: Transaction log of lsn (9139243529340) to (9140981673366) was copied.
130824 15:45:33 innobackupex: Connection to database server closed
innobackupex: Backing up as tar stream 'ib_lru_dump'
tar: ib_lru_dump: file changed as we read it
innobackupex: Error: Failed to stream 'ib_lru_dump': No such file or directory at /usr/bin/innobackupex line 386.

Full command:
innobackupex --no-lock --no-timestamp --stream=tar --tmpdir=$INNOBACKUP_TMP $INNOBACKUP_TMP 2> $INNOBACKUP_TMP/xtrabackup_$DATE.log | gzip - | ssh -i $KEY $REMOTE_HOST "cat - > $REMOTE_PATH/xtrabackup_$DATE.tgz"

The dump is done every 60 seconds:
innodb_buffer_pool_restore_at_startup = 60

I guess disabling dump ( innodb_buffer_pool_restore_at_startup =0) before streaming this file, and re-setting to previous value after it's copied would be a decent fix

Alexey Kopytov (akopytov) wrote :

It's a server bug. The server should first dump the buffer pool contents to a temporary file and then rename it instead of overwriting an existing file.

Which has been implemented as a part of https://blueprints.launchpad.net/percona-server/+spec/auto-lru-dump-improvements, but never got merged.

affects: percona-xtrabackup → percona-server

In 5.5 the description of the problem (dump to a temp file and rename) matches bug 686392, which is marked as Fix Released (as a part of George's LRU dump fixes instead of the Alexey's referenced blueprint). For 5.6 this is an upstream bug and should be reported there as such.

The report does not mention the version used but option names imply 5.5. Thus it need clarification whether this is indeed the same issue as bug 686392 and the fix is incomplete or some other issue.

Alexey Kopytov (akopytov) wrote :

Yep, it should actually be fixed in 5.1.65 and 5.5.24. As to the "buffer pool dump" implementation in 5.6, I see it handles it correctly: the dump is first created in a temp. file and then renamed.

markus_albe (markus-albe) wrote :

Customer got me output:

version 5.5.31-30.3-log
version_comment Percona Server (GPL), Release rel30.3, Revision 520
version_compile_machine x86_64
version_compile_os Linux

The xtrabackup version:

xtrabackup version 2.0.7 for Percona Server 5.1.59 unknown-linux-gnu (x86_64) (revision id: 552)

tags: added: i34560
Launchpad Janitor (janitor) wrote :

[Expired for Percona Server 5.1 because there has been no activity for 60 days.]

Launchpad Janitor (janitor) wrote :

[Expired for Percona Server 5.5 because there has been no activity for 60 days.]

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

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers