MySQL Bugs: #29815: Please add an option for suppressing last line of mysqldump: "Dump completed on"

Bug #29815	Please add an option for suppressing last line of mysqldump: "Dump completed on"
Submitted:	16 Jul 2007 11:17	Modified:	5 Sep 2007 7:31
Reporter:	Nick Jenkins
Status:	Closed
Category:	Server: Backup	Severity:	S4 (Feature request)
Version:	5.0.32-Debian_7etch1-log	OS:	Any
Assigned to:		Target Version:
Triage:	D5 (Feature request)

Description:
In bug 10877 a feature was added, in which an extra last line was added to the 
mysqldump output, that said: "-- Dump completed on YYYY-MM-DD hh:mm:ss" 

However, this removes a simple way of comparing dumps to see if they are the
same or not (using the "diff --brief" command).

How to repeat:
Perform a dump using mysqldump, then perform another mysqldump (without changing
anything), then compare the two dump files, and observe that they are now reported as
being different. This used to work: they would be reported as being the same.

Suggested fix:
would it please be possible to add a command-line option to mysqldump to suppress
that last "-- Dump completed on YYYY-MM-DD hh:mm:ss" line, for those of us who want to be
able to compare dumps very easily to see if anything has changed?

Thank you for a problem report. Why just not to use any of UNIX test processing tools to
remove last line if it starts with "-- Dump completed" before running diff, if you want
to ignore it?

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

2 ways for help:

a) mysqldump DATABASENAME|head --lines=-1
(head --lines=-1 cuts last line 
but i prefer using
b) mysqldump --compact DATABASENAME
(i don't need these /*!401xx SET ... lines )
JanQ

Thank you!

This produces output that's probably similar enough to what I was looking for, without
the date-created line:
/usr/bin/mysqldump --compact --add-drop-table --add-locks --extended-insert --quick
--lock-tables DATABASE-NAME > file.sql

Alternatively, the "| /usr/bin/head --lines=-1" method was marginally slower (23.096
seconds versus 21.780 seconds for a 80 Mb test backup, so around 6% slower), but I think
is probably the one I will use since it gives identical output apart from the last line.

I would like to second the original request to add an option to suppress that last line in
mysqldump.  This date line adds very little as far as value (the date of the dump is
implicit in the timestamp of the file) yet it breaks lots of database backup scripts (at
least mine).  Perhaps not many people have noticed because it doesn't break the backup
completely; it just causes lots of extraneous backup traffic of databases that haven't
changed at all except for that last line.

I actually do a simple cmp between two dumps to see if they have changed.  If they
haven't, the old database stays in place (inodes and all).  Keeping the old file in place
allows incremental backups to work as desired.  With this new feature, incremental backups
don't work since the dump is changing daily (assuming a daily dump).

Yes, the workarounds work but isn't it just as easy (much easier for your users) to add
the command line option?  Or better yet, just remove this needless feature.

Thanks.

I opened a new bug to track this issue since this one was closed.  Please add your
comments to bug #31077.  Thanks.

on the mysqldump file, the time of the dump completed is 7 hours ahead of the real time.
-- Perform a mysqldump (5.1) on 2008-05-20 14:33, the output shows
   Dump completed on 2008-05-20 21:33:40 
-- Perform a mysqldump (6.0) on 2008-05-20 14:36, the output shows
Dump completed on 2008-05-20 21:36:43

This feature is not needless; it was added for a reason.

Possible workaround: run mysqldump with the --skip-comments option. This may or may not
be suitable for your purposes because although it suppresses the final comment, it also
suppresses other comments from appearing in the dump file.