Feature Request: more verbose output during initial table scan

[Todd Lyons]

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.

[Todd Lyons (tlyons)]

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 (vadim-tk)]

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 [phone]
MySQL Performance Blog - http://www.mysqlperformanceblog.com
MySQL Consulting http://www.percona.com/

[Todd Lyons (tlyons)]

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:

InnoDB Backup Utility v1.5.1-xtrabackup; Copyright 2003, 2009 Innobase Oy.
All Rights Reserved.

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

[Stewart Smith (stewart)]

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

[Shahriyar Rzayev (rzayev-sehriyar)]

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