Percona XtraBackup moved to https://jira.percona.com/projects/PXB

Feature Request: more verbose output during initial table scan

Bug #369913 reported by Todd Lyons on 2009-04-30

This bug affects 1 person

	Status	Importance	Assigned to	Milestone
Percona XtraBackup moved to https://jira.percona.com/projects/PXB	Fix Released	Wishlist	Alexey Kopytov	Percona XtraBackup moved to https://jira.percona.com/projects/PXB 2.3.1-beta1
2.0	Won't Fix	Undecided	Unassigned
2.1	Won't Fix	Undecided	Unassigned
2.2	Fix Released	Wishlist	Alexey Kopytov	Percona XtraBackup moved to https://jira.percona.com/projects/PXB 2.2.6
2.3	Fix Released	Wishlist	Alexey Kopytov	Percona XtraBackup moved to https://jira.percona.com/projects/PXB 2.3.1-beta1

Bug Description

We ran innobackupex-1.5.1 to test it on our development system, 125 total databases, consisting of 23768 tables in innodb format (innodb_table_per_file *.idb) and 937 tables in myisam format (*.MYD). The total dataset is around 13 GB.

When doing the initial table scan, there is a long pause where nothing is printed out. On our system with a lot of db's and tables, I initially though that long period of inactivity might be a lock-up. An strace showed that it was in fact reading in massive amounts of database info, so outputting a "Generating db/table list" type of message would be a helpful message to people with large numbers of tables.

On the opposite end, there could possibly also be a --quiet option that will suppress the "Copying $FILE to $DESTFILE" messages when it is copying all of the messages. If you think that &>/dev/null is a sufficient synonym for --quiet, then I am quite happy with that too.

Related branches

lp://staging/~akopytov/percona-xtrabackup/bug369913

Merged into lp://staging/percona-xtrabackup/2.2 at revision 5038

Alexey Kopytov (community): Approve on 2014-10-21

Revision history for this message

Todd Lyons (tlyons) wrote on 2009-06-05:

We just used innobackupex again to restore a production slave from scratch. It worked fantastic! I would like to request one additional verbose output addition. At the start of the process, print the date/time, and at the end of the process, print the date/time again. Analyzing this data allows us to estimate duration of current and future scripted events based on the known size of databases.

I usually do "innobackupex-1.5.1 ... 2&>1 | tee /tmp/innobackupex.log" so it would be nice to be able to head and tail the file and get duration of the operation.

Revision history for this message

Vadim Tkachenko (vadim-tk) wrote on 2009-06-05: Re: [Bug 369913] Re: Feature Request: more verbose output during initial table scan

Todd,

But it does write

090605 11:55:04 innobackupex: Starting mysql with options: --unbuffered
....
090605 01:06:05 innobackupex: innobackup completed OK!

Todd Lyons wrote:
> We just used innobackupex again to restore a production slave from
> scratch. It worked fantastic! I would like to request one additional
> verbose output addition. At the start of the process, print the
> date/time, and at the end of the process, print the date/time again.
> Analyzing this data allows us to estimate duration of current and future
> scripted events based on the known size of databases.
>
> I usually do "innobackupex-1.5.1 ... 2&>1 | tee /tmp/innobackupex.log"
> so it would be nice to be able to head and tail the file and get
> duration of the operation.
>

--
Vadim Tkachenko, CTO
Percona Inc.
ICQ: 369-510-335, Skype: vadimtk153, Phone +1-888-401-3403
MySQL Performance Blog - http://www.mysqlperformanceblog.com
MySQL Consulting http://www.percona.com/

Revision history for this message

Todd Lyons (tlyons) wrote on 2009-06-05: Re: [Bug 369913] Re: Feature Request: more verbose output during initial table scan

On Fri, Jun 5, 2009 at 8:56 AM, Vadim Tkachenko<email address hidden> wrote:
> Todd,
>
> But it does write
>
> 090605 11:55:04 innobackupex: Starting mysql with options: --unbuffered
> ....
> 090605 01:06:05 innobackupex: innobackup completed OK!

My apologies, I omitted the important information that I was
specifically asking for this in the copy-back operation. This is how
the output looks for --copy-back:

IMPORTANT: Please check that the copy-back run completes successfully.
At the end of a successful copy-back run innobackup
prints "innobackup completed OK!".

innobackupex: Starting to copy MyISAM tables, indexes,
innobackupex: .MRG, .TRG, .TRN, .opt, and .frm files
innobackupex: in '/mysqlBackups/mysqlBackup1/2009-05-30_16-32-10'
innobackupex: back to original data directory '/var/lib/mysql'
innobackupex: Copying directory
'/mysqlBackups/mysqlBackup1/2009-05-30_16-32-10/magento_ws_58455'
innobackupex: Copying directory
'/mysqlBackups/mysqlBackup1/2009-05-30_16-32-10/magento_ws_27421'
<snip>

Here's how I called it:

innobackupex-1.5.1 --copy-back
/mysqlBackups/mysqlBackup1/2009-05-30_16-32-10/ 2>&1 | tee
/tmp/innobackup.out

Thank you for pointing that out :-)

--
Regards... Todd

Vadim Tkachenko (vadim-tk) on 2009-08-07

Changed in percona-xtrabackup:
status:	New → Confirmed
importance:	Undecided → Low
assignee:	nobody → Yasufumi Kinoshita (yasufumi-kinoshita)

Revision history for this message

Stewart Smith (stewart) wrote on 2011-05-20:

Leaving as unassigned as I don't see Yasufumi having this on his radar at the moment.

Changed in percona-xtrabackup:
importance:	Low → Wishlist
status:	Confirmed → Triaged
assignee:	Yasufumi Kinoshita (yasufumi-kinoshita) → nobody

Alexey Kopytov (akopytov) on 2013-03-26

tags:

removed: feature-request

Revision history for this message

Shahriyar Rzayev (rzayev-sehriyar) wrote on 2018-01-20:

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

Report a bug

This report contains Public information

Everyone can see this information.

You are

Subscribing...

Edit bug mail

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.