Feature Request: more verbose output during initial table scan

Bug #369913 reported by Todd Lyons on 2009-04-30
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Percona XtraBackup moved to https://jira.percona.com/projects/PXB
Fix Released
Wishlist
Alexey Kopytov
2.0
Won't Fix
Undecided
Unassigned
2.1
Won't Fix
Undecided
Unassigned
2.2
Fix Released
Wishlist
Alexey Kopytov
2.3
Fix Released
Wishlist
Alexey Kopytov

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

Todd Lyons (tlyons) 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.

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/

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

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

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
tags: removed: feature-request

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

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

Other bug subscribers