Bug #48059 Backup operation does not error out backup_history.log file is deleted
Submitted: 14 Oct 2009 20:53 Modified: 18 Mar 2010 18:56
Reporter: Hema Sridharan Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Backup Severity:S3 (Non-critical)
Version:6.0-backup OS:Any
Assigned to: Ritheesh Vedire CPU Architecture:Any

[14 Oct 2009 20:53] Hema Sridharan
Description:
Set global log_backup_output='FILE';
Create database db1;
Backup database db1 to 'db1.bak';
Restore from 'db1.bak' overwrite;
Check the backup_history.log file from var/mysqld.1/data/
Verify that all the column values are reported properly
Now remove the backup_history.log file from var/mysqld.1/data/ directory.
Perform backup / restore operation again and it succeeds.

This behaviour is not expected as per design. Backup operation should either fail or create a new log file.

Generally when log_backup_output is set to 'TABLE', and if we delete the mysql.backup_history table, then backup operation will fail by giving the error
"ERROR 1691 (HY000): Can't open the backup logs as tables. Check 'mysql.backup_history' and 'mysql.backup_progress' or run mysql_upgrade to repair"

This shows that behaviour changes when log backup output is set to 'FILE' and 'TABLE'. 

How to repeat:
Please see the description
[11 Dec 2009 14:51] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/93707

2906 Ritheesh Vedire	2009-12-11
      BUG#48059:Backup operation does not error out 
                backup_history.log file is deleted.
      
      If server initialised  backup log files are deleted when the
      server is still up, backup logging to files does not take place.
      
      This patch checks for the accessablity of those files everytime,
      before a write is made.If not accessable, new files are created 
      and error is reported to the server's error log.
     @ sql/log.cc
        If the file is not accessable, the file is closed and opened again.
        This function is very similar to reopen_file().
[12 Dec 2009 13:01] Ingo Strüwing
Not approved yet. Please see comments by emails.
[14 Dec 2009 12:10] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/93900

2906 Ritheesh Vedire	2009-12-14
      BUG#48059: Backup operation does not error out 
      backup_history.log file is deleted.
      
      
      Backup log files are initialised by the server. If they are 
      subsequently deleted when the server is still running, nothing is logged.
      
      This patch checks to see if a  backup log file is  
      accessible before each write. If not accessible, a new  log file 
      is created and a warning is reported to the server's error log.
     @ sql/log.cc
        Added a new method check_file(). If my_access() fails, reopen_file()
        is called. reopen_file() acquires LOCK_log before closing and opening the file.So, a note is added in the function header.
     @ sql/log.h
        check_file() header and the  note.
[14 Dec 2009 17:02] Chuck Bell
Approved pending changes. Trust is extended here whereby all spelling and spacing issues will be fixed prior to pushing the patch.
[14 Dec 2009 17:19] Ingo Strüwing
Approved pending changes. Please see email for required changes.
[15 Dec 2009 11:06] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/94102

2906 Ritheesh Vedire	2009-12-15
      BUG#48059: Backup operation does not error out 
      backup_history.log file is deleted.
      
      Backup log files are initialized by the server. If they are 
      subsequently deleted when the server is still running, nothing is logged.
      
      This patch checks to see if a backup log file is
      accessible before each write. If not accessible, a new log file
      is created and a warning is reported to the server's error log.
     @ sql/log.cc
        Added a new method check_file(). If my_access() fails, reopen_file()
        is called. reopen_file() acquires LOCK_log before closing and opening the file.
        So, a note is added in the comments.
     @ sql/log.h
        Added check_file() header.
[15 Dec 2009 11:17] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/94105

2907 Ritheesh Vedire	2009-12-15 [merge]
      Local merge before push of BUG#48059
[15 Dec 2009 20:59] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/94285

2915 Chuck Bell	2009-12-15
      BUG#48059: Backup operation does not error out 
                 backup_history.log file is deleted.
      
      Backup log files are initialized by the server. If they are 
      subsequently deleted when the server is still running, nothing is logged.
      
      This patch checks to see if a backup log file is
      accessible before each write. If not accessible, a new log file
      is created and a warning is reported to the server's error log.
     @ sql/log.cc
        Added a new method check_file(). If my_access() fails, reopen_file()
        is called. reopen_file() acquires LOCK_log before closing and opening the file.
        So, a note is added in the comments.
     @ sql/log.h
        Added check_file() header.
[20 Feb 2010 9:18] Bugs System
Pushed into 6.0.14-alpha (revid:ingo.struewing@sun.com-20100218152520-s4v1ld76bif06eqn) (version source revid:ingo.struewing@sun.com-20100119103538-wtp5alpz4p2jayl5) (merge vers: 6.0.14-alpha) (pib:16)
[18 Mar 2010 18:56] Paul DuBois
Noted in 6.0.14 changelog.

The backup logging to the FILE destination enabled, the server did
not check whether the log files were missing and create them as 
necessary.