Warning "The log was not applied to the intended LSN" should optionally be an error
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| Percona XtraBackup moved to https://jira.percona.com/projects/PXB |
Fix Released
|
Medium
|
Sergei Glushchenko | |
| 2.2 |
Fix Released
|
Medium
|
Sergei Glushchenko | |
| 2.3 |
Fix Released
|
Medium
|
Sergei Glushchenko |
Bug Description
xtrabackup: #######
xtrabackup: # !!WARNING!! #
xtrabackup: # The transaction log file is corrupted. #
xtrabackup: # The log was not applied to the intended LSN! #
xtrabackup: #######
From xtrabackup.cc (2.2.8) starting at line line 6032
if (innobase_
srv_start_lsn = log_sys->lsn = recv_sys-
/* Check whether the log is applied enough or not. */
if ((xtrabackup_
&& srv_start_lsn < incremental_
||
&& srv_start_lsn < metadata_last_lsn)) {
msg(
"xtrabackup: #######
"xtrabackup: # !!WARNING!! #\n"
"xtrabackup: # The transaction log file is corrupted. #\n"
"xtrabackup: # The log was not applied to the intended LSN! #\n"
"xtrabackup: #######
);
if (xtrabackup_
msg("xtrabackup: The intended lsn is " LSN_PF "\n",
} else {
msg("xtrabackup: The intended lsn is " LSN_PF "\n",
}
}
Besides the possible bug that caused this, we should consider an option to make this event either a warning or an error, so innobackupex will not return 0 as it does now, because the backup could in fact be corrupt.
I'm not entirely sure what an option name could be, but something like --too-short-
Related branches
- Alexey Kopytov (community): Needs Information on 2015-02-09
-
Diff: 63 lines (+36/-1)2 files modifiedstorage/innobase/xtrabackup/src/xtrabackup.cc (+4/-1)
storage/innobase/xtrabackup/test/t/bug1414221.sh (+32/-0)
- Alexey Kopytov (community): Needs Information on 2015-02-09
-
Diff: 63 lines (+36/-1)2 files modifiedstorage/innobase/xtrabackup/src/xtrabackup.cc (+4/-1)
storage/innobase/xtrabackup/test/t/bug1414221.sh (+32/-0)
tags: | added: i50241 |
Changed in percona-xtrabackup: | |
status: | New → Confirmed |
Swany (greenlion) wrote : | #1 |
Alexey Kopytov (akopytov) wrote : | #2 |
Well, if the redo log has not been applied fully, the back IS in fact corrupt. Why don't we make it an unconditional error, rather than an optional one?
Ok. Lets make it unconditional error. But I think that user still has a chance to end up with useful full prepared backup. In fact we don't know whether the redo log is corrupt or xtrabackup_
Shahriyar Rzayev (rzayev-sehriyar) wrote : | #5 |
Percona now uses JIRA for bug reports so this bug report is migrated to: https:/
Perhaps also print srv_start_lsn and metadata_last_lsn for diagnostic purposes