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

[markus_albe]

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.

[Swany (greenlion)]

Perhaps also print srv_start_lsn and metadata_last_lsn for diagnostic purposes

[Alexey Kopytov (akopytov)]

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?

[Sergei Glushchenko (sergei.glushchenko)]

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.

[Sergei Glushchenko (sergei.glushchenko)]

https://github.com/percona/percona-xtrabackup/pull/3

[Shahriyar Rzayev (rzayev-sehriyar)]

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