| 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: | |
| 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: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.
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.