MySQL Bugs: #40305: Backup: Bad feedback when BACKUP/RESTORE operation aborted.

Bug #40305	Backup: Bad feedback when BACKUP/RESTORE operation aborted.
Submitted:	24 Oct 2008 13:21	Modified:	11 Feb 2009 3:29
Reporter:	Rafal Somla	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Backup	Severity:	S3 (Non-critical)
Version:	6.0-backup	OS:	Any
Assigned to:	Rafal Somla	CPU Architecture:	Any

Description:
At the end of BACKUP/RESTORE operation, message like "Backup completed" is logged in the logs. This is confusing in case an error was detected and operation aborted and the user still sees "Backup completed" in the logs.

How to repeat:
Execute backup_errors test and examine contents of var/log/master.err. You should see e.g.

  [Note] Backup: Backing up selected databases
  [ERROR] Backup: Database 'mysql' cannot be included in a backup
  [Note] Backup: Backup completed

Suggested fix:
ssue "Backup/Restore completed" message only if the operation has indeed been completed. In all other cases issue a warning "Operation has been aborted". In the above example the feedback should be:

  [Note] Backup: Backing up selected databases
  [ERROR] Backup: Database 'mysql' cannot be included in a backup
  [Warning] Backup: Operation aborted

Note: Fixing this bug will help solving BUG#35079 by providing better feedback in case of an interruption.

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/61038

2734 Rafal Somla	2008-12-09
      Bug #40305 - Backup: Bad feedback when BACKUP/RESTORE operation aborted.
      
      This patch refactors the code reporting termination of BACKUP/RESTORE statement. 
      After the changes "Backup/Restore completed" is shown only if operation has been 
      completed. In case of abnormal termination (error, interruption) a warning 
      "Operation aborted" or "Operation aborted - data might be corrupted" is logged. 
      The latter is in the case of RESTORE operation which has modified some data in 
      the server.
      
      The main changes are:
      - Adding new methods to backup::Logger for reporting successful completion of an 
        operation and the fact that data has been modified.
      - Slightly change semantics of report_stop() which now does not report state 
        changes - it is done in appropriate report_completed() or report_error().
      - Make sure that report_stop() is always called - now it is done in 
        Backup_restore_ctx::close() which is called from the destructor.
      - Change the logic for removing backup file (in case BACKUP operation is not 
        completed). Before this was guarded by explicit m_remove_loc flag. Now we can 
        directly check if BACKUP operation has been completed successfully (i.e. 
        report_completed() was called) or not.
      
      Note: the new functionality is covered by existing test cases.

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/61076

2734 Rafal Somla	2008-12-09
      Bug #40305 - Backup: Bad feedback when BACKUP/RESTORE operation aborted.
      
      This patch refactors the code reporting termination of BACKUP/RESTORE statement. 
      After the changes "Backup/Restore completed" is shown only if operation has been 
      completed. In case of abnormal termination (error, interruption) a warning 
      "Operation aborted" or "Operation aborted - data might be corrupted" is logged. 
      The latter is in the case of RESTORE operation which has modified some data in 
      the server.
      
      The main changes are:
      - Adding new methods to backup::Logger for reporting successful completion of an 
        operation and the fact that data has been modified.
      - Slightly change semantics of report_stop() which now does not report state 
        changes - it is done in appropriate report_completed() or report_error().
      - Make sure that report_stop() is always called - now it is done in 
        Backup_restore_ctx::close() which is called from the destructor.
      - Change the logic for removing backup file (in case BACKUP operation is not 
        completed). Before this was guarded by explicit m_remove_loc flag. Now we can 
        directly check if BACKUP operation has been completed successfully (i.e. 
        report_completed() was called) or not.
      
      Note: the new functionality is covered by existing test cases.

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/61844

2741 Rafal Somla	2008-12-17
      Bug #40305 - Backup: Bad feedback when BACKUP/RESTORE operation aborted.
      
      This patch refactors the code reporting termination of BACKUP/RESTORE statement. 
      After the changes "Backup/Restore completed" is shown only if operation has been 
      completed. In case of abnormal termination (error, interruption) a warning 
      "Operation aborted" or "Operation aborted - data might be corrupted" is logged. 
      The latter is in the case of RESTORE operation which has modified some data in 
      the server.
      
      The main changes are:
      - Function backup::Logger::report_stop() is replaced by 2 new functions: 
        report_completed() and report_aborted() to differentiate the feedback given in 
        the two situations.
      - Make sure that a call to report_completed() or report_aborted() always matches 
        a previous call to report_start(). This is done in Backup_restore_ctx::close() 
        which is called from the destructor.
      - Change the logic for removing backup file (in case BACKUP operation is not 
        completed). Before this was guarded by explicit m_remove_loc flag. Now we can 
        directly check if BACKUP operation has been completed successfully (i.e. 
        report_completed() was called) or not.
      
      Note: the new functionality is covered by existing test cases.

Patch approved pending completion of requests.

REQUESTS
--------
1. The backup_errors test fails on Windows.
2. The patch fails to apply to latest tree. Please resolve as the kernel.cc code has changed a bit.

Approved.

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/62678

2741 Rafal Somla	2009-01-08
      Bug #40305 - Backup: Bad feedback when BACKUP/RESTORE operation aborted.
      
      This patch refactors the code reporting termination of BACKUP/RESTORE statement. 
      After the changes "Backup/Restore completed" is shown only if operation has been 
      completed. In case of abnormal termination (error, interruption) a warning 
      "Operation aborted" or "Operation aborted - data might be corrupted" is logged. 
      The latter is in the case of RESTORE operation which has modified some data in 
      the server.
      
      The main changes are:
      - Function backup::Logger::report_stop() is replaced by 2 new functions: 
        report_completed() and report_aborted() to differentiate the feedback given in 
        the two situations.
      - Make sure that a call to report_completed() or report_aborted() always matches 
        a previous call to report_start(). This is done in Backup_restore_ctx::close() 
        which is called from the destructor.
      - Change the logic for removing backup file (in case BACKUP operation is not 
        completed). Before this was guarded by explicit m_remove_loc flag. Now we can 
        directly check if BACKUP operation has been completed successfully (i.e. 
        report_completed() was called) or not.
      
      Note: the new functionality is covered by existing test cases.

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/62701

2748 Rafal Somla	2009-01-08
      Bug #40305 - Backup: Bad feedback when BACKUP/RESTORE operation aborted.
      
      This patch refactors the code reporting termination of BACKUP/RESTORE statement. 
      After the changes "Backup/Restore completed" is shown only if operation has been 
      completed. In case of abnormal termination (error, interruption) a warning 
      "Operation aborted" or "Operation aborted - data might be corrupted" is logged. 
      The latter is in the case of RESTORE operation which has modified some data in 
      the server.
      
      The main changes are:
      - Function backup::Logger::report_stop() is replaced by 2 new functions: 
        report_completed() and report_aborted() to differentiate the feedback given in 
        the two situations.
      - Make sure that a call to report_completed() or report_aborted() always matches 
        a previous call to report_start(). This is done in Backup_restore_ctx::close() 
        which is called from the destructor.
      - Change the logic for removing backup file (in case BACKUP operation is not 
        completed). Before this was guarded by explicit m_remove_loc flag. Now we can 
        directly check if BACKUP operation has been completed successfully (i.e. 
        report_completed() was called) or not.
      
      Note: the new functionality is covered by existing test cases.

Pushed to mysql-6.0-backup tree.

Pushed into 6.0.10-alpha (revid:sergefp@mysql.com-20090202090240-dlkxhmc1asrar5rl) (version source revid:sergefp@mysql.com-20090129100938-qvke7a9krg24l8pl) (merge vers: 6.0.10-alpha) (pib:6)

Noted in 6.0.10 changelog.

"Backup completed" was logged for non-successful BACKUP DATABASE
operations. "Restore completed" was logged for non-successful RESTORE
operations.