Bug #57451 | mysqldump omits events | ||
---|---|---|---|
Submitted: | 14 Oct 2010 11:02 | Modified: | 14 Oct 2010 15:18 |
Reporter: | Peter Laursen (Basic Quality Contributor) | Email Updates: | |
Status: | Duplicate | Impact on me: | |
Category: | MySQL Server: mysqldump Command-line Client | Severity: | S1 (Critical) |
Version: | 5.5.6 | OS: | Any |
Assigned to: | CPU Architecture: | Any | |
Tags: | qc |
[14 Oct 2010 11:02]
Peter Laursen
[14 Oct 2010 11:09]
MySQL Verification Team
probably his stored routines are lost too. he must give --routines --events to have those backed up.
[14 Oct 2010 11:11]
Peter Laursen
Really .. ? If you just specify a database or --all-databases everybody would expect that all type of database objects are backed up.
[14 Oct 2010 12:54]
Peter Laursen
If this is the way it is supposed to work than at least it should be more obvious from documentation (emphasized and on top) that only tables (and views) are dumped if no --options are specified. I am uncertain about TRIGGERS as I also find now that there is both a --triggers and a --skip-triggers option (refer: http://dev.mysql.com/doc/refman/5.1/en/mysqldump.html). What is default as regards TRIGGERS if neither is specified? Unclear, isn't it? But updating documentation is not a real fix. RTFM unfortunately sometimes only applies when things went wrong. I am very surprised about this, but it is my fault (and worse the fault of our customer, who lost important code - we did fortunately not advise to use mysqldump) of course. To simply 'backup a database' should in my understanding mean *backup everything stored in the database so that it can be restored to full functionality* I think.
[14 Oct 2010 15:18]
Sveta Smirnova
Thank you for the report. There is --event option for dumping events. Regarding why table mysql.event is not dumped there is verified bug #55587. So this one is duplicate of that one.