Warning "The log was not applied to the intended LSN" should optionally be an error

Bug #1414221 reported by markus_albe on 2015-01-23
12
This bug affects 2 people
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_log_arch_dir)
  srv_start_lsn = log_sys->lsn = recv_sys->recovered_lsn;

 /* Check whether the log is applied enough or not. */
 if ((xtrabackup_incremental
      && srv_start_lsn < incremental_last_lsn)
     ||(!xtrabackup_incremental
        && srv_start_lsn < metadata_last_lsn)) {
  msg(
"xtrabackup: ########################################################\n"
"xtrabackup: # !!WARNING!! #\n"
"xtrabackup: # The transaction log file is corrupted. #\n"
"xtrabackup: # The log was not applied to the intended LSN! #\n"
"xtrabackup: ########################################################\n"
      );
  if (xtrabackup_incremental) {
   msg("xtrabackup: The intended lsn is " LSN_PF "\n",
       incremental_last_lsn);
  } else {
   msg("xtrabackup: The intended lsn is " LSN_PF "\n",
       metadata_last_lsn);
  }
 }

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-log-apply-handle=warning|error would work I guess.

Related branches

tags: added: i50241
Changed in percona-xtrabackup:
status: New → Confirmed
Swany (greenlion) wrote :

Perhaps also print srv_start_lsn and metadata_last_lsn for diagnostic purposes

Alexey Kopytov (akopytov) wrote :

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_checkpoints contains false information.

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PXB-177

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers