Bug #39924 Not possible to use backup logs after BACKUP has been interrupted.
Submitted: 8 Oct 2008 9:31 Modified: 28 Jun 2009 0:16
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: Chuck Bell CPU Architecture:Any

[8 Oct 2008 9:31] Rafal Somla
Description:
BACKUP/RESTORE commands give feedback by writing entries in the backup log tables (mysql.backup_progress and mysql.backup_history). However, if user interrupts ongoing BACKUP operation (by hitting Ctrl+C), it will be not possible to add any new entries to these logs and thus not possible to give him any feedback about the interruption.

Note: this issue doesn't directly hit a user, it rather hits us, online backup developers, as we can't use backup logs after command interruption. I consider it an issue with the implementation of backup logging mechanism.

How to repeat:
Do the following modification of the tree:

--- sql/backup/kernel.cc        2008-09-30 07:51:48 +0000
+++ sql/backup/kernel.cc        2008-10-08 09:23:02 +0000
@@ -176,6 +176,7 @@ execute_backup_command(THD *thd, LEX *le
       DBUG_RETURN(send_error(context, ER_BACKUP_BACKUP_PREPARE));
 
     DEBUG_SYNC(thd, "after_backup_start_backup");
+    context.report_state(BUP_ERRORS);
 
     // select objects to backup

It makes the BACKUP command to *always* insert an "error" entry to the backup logs. Now execute the following test script which runs BACKUP and kills it from another connection:
********
--disable_abort_on_error
--connect (killer,localhost,root,,)
--connection default

let $id=`select connection_id()`;

CREATE DATABASE intr;
USE intr;

CREATE TABLE t1(a int);
INSERT INTO  t1 VALUES (1),(2),(3);

SET DEBUG_SYNC='after_backup_start_backup SIGNAL here WAIT_FOR go';
send BACKUP DATABASE intr TO 'intr.bkp';

--connection killer
SET DEBUG_SYNC='now WAIT_FOR here';

eval KILL QUERY $id;

SET DEBUG_SYNC='now SIGNAL go';

--connection default
reap;
SHOW WARNINGS;
SELECT * FROM mysql.backup_progress;
********

If the "eval KILL QUERY $id" statement is commented out, one can sees these entries in the backup_progress log:

SELECT * FROM mysql.backup_progress;
backup_id       object  start_time      stop_time       total_bytes     progress        error_num       notes
252     backup kernel   0000-00-00 00:00:00     0000-00-00 00:00:00     0       0       0       starting
252     backup kernel   0000-00-00 00:00:00     0000-00-00 00:00:00     0       0       0       running
252     backup kernel   0000-00-00 00:00:00     0000-00-00 00:00:00     0       0       0       error
252     backup kernel   0000-00-00 00:00:00     0000-00-00 00:00:00     0       0       0       validity point
252     backup kernel   2008-10-08 09:26:48     0000-00-00 00:00:00     0       0       0       vp time
252     backup kernel   0000-00-00 00:00:00     0000-00-00 00:00:00     0       0       0       running
252     backup kernel   0000-00-00 00:00:00     0000-00-00 00:00:00     0       0       0       complete

Note the "error" entry inserted after "running". Now if KILL QUERY is executed then the log looks as follows:

SELECT * FROM mysql.backup_progress;
backup_id       object  start_time      stop_time       total_bytes     progress        error_num       notes
252     backup kernel   0000-00-00 00:00:00     0000-00-00 00:00:00     0       0       0       starting
252     backup kernel   0000-00-00 00:00:00     0000-00-00 00:00:00     0       0       0       running

This is bad, because "error" entry does not appear in the log, even though it is inserted with "context.report_state(BUP_ERRORS);" and this statement will be executed even in case BACKUP is killed.
[8 Oct 2008 9:37] Rafal Somla
Looking at the implementation of the backup logging mechanism in sql/log.cc one can see where the problem lies. E.g., in Log_to_csv_event_handler::log_backup_progress(...) the mysql.backup_progress table is opened with open_performance_schema_table(...). But if BACKUP connection received Ctrl+C then thd->killed is non-zero and open_performance_schema_table(...) will fail, thus nothing will be written to the log.
[8 Oct 2008 16:38] Sveta Smirnova
Thank you for the report.

Verified as described.
[1 May 2009 0:16] 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/73232

2703 Chuck Bell	2009-04-30
      BUG#39924 : Not possible to use backup logs after BACKUP has been interrupted
      
      This patch corrects the problem of not being able to write
      to the backup logs when a backup or restore is killed.
      modified:
        mysql-test/suite/backup/r/backup_logs.result
        mysql-test/suite/backup/t/backup_logs.test
        sql/backup/kernel.cc
        sql/log.cc
[5 May 2009 7:23] Jørgen Løland
Good to push.
[5 May 2009 13:16] Ingo Strüwing
Back to "in progress". Please find my small change requests in email.
[5 May 2009 21:33] 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/73443

2803 Chuck Bell	2009-05-05
      BUG#39924 : Not possible to use backup logs after BACKUP has been interrupted
      
      When a backup or restore was cancelled or interrupted and the thread
      was killed, the backup logs were left in an undefined state. This was
      because they were opened using a method that detects a killed thread
      and fails if the thread is in a killed state.
      
      This patch includes an override in the table open method that allows
      the backup logs to be written if the thread is in a killed state.
      
      Before the patch the logs were incomplete with the error condition
      missing from the progress log and the history log entry either 
      incomplete or not written at all. 
      
      This patch ensures the log entries will be written in the event the 
      thread is killed (backup or restore is cancelled in some unusual
      manner).
      modified:
        mysql-test/suite/backup/r/backup_intr_errors.result
        mysql-test/suite/backup/r/backup_logs.result
        mysql-test/suite/backup/t/backup_logs.test
        mysql-test/suite/backup_engines/include/backup_restore_interrupt.inc
        mysql-test/suite/backup_engines/r/backup_interruption.result
        mysql-test/suite/backup_engines/t/backup_interruption.test
        sql/backup/kernel.cc
        sql/log.cc
[7 May 2009 1:45] 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/73549

2807 Chuck Bell	2009-05-06
      BUG#39924 : Not possible to use backup logs after BACKUP has been interrupted
      
      When a backup or restore was cancelled or interrupted and the thread
      was killed, the backup logs were left in an undefined state. This was
      because they were opened using a method that detects a killed thread
      and fails if the thread is in a killed state.
      
      This patch includes an override in the table open method that allows
      the backup logs to be written if the thread is in a killed state.
      
      Before the patch the logs were incomplete with the error condition
      missing from the progress log and the history log entry either 
      incomplete or not written at all. 
      
      This patch ensures the log entries will be written in the event the 
      thread is killed (backup or restore is cancelled in some unusual
      manner).
      modified:
        mysql-test/suite/backup/r/backup_intr_errors.result
        mysql-test/suite/backup/r/backup_logs.result
        mysql-test/suite/backup/t/backup_logs.test
        mysql-test/suite/backup_engines/include/backup_restore_interrupt.inc
        mysql-test/suite/backup_engines/r/backup_interruption.result
        mysql-test/suite/backup_engines/t/backup_interruption.test
        sql/backup/kernel.cc
        sql/log.cc
[7 May 2009 1:46] Chuck Bell
Pushed to mysql-6.0-backup at 6.0.11-alpha.
[3 Jun 2009 7:12] Jørgen Løland
Merged to azalea June 2
[28 Jun 2009 0:16] Paul DuBois
Noted in 6.0.11 changelog.

The backup logs became unusable if a BACKUP DATABASE operation was
interrupted.