Incorrect handling of FTS optimize thread in xtrabackup_56

[Alexey Kopytov]

xtrabackup_56 implements an incorrect logic with respect to the FTS optimize thread and --apply-log-only.

The thread is always started on XtraBackup recovery innobase_start_or_create_for_mysql(). But for some reasons innodb56.patch does a proper shutdown only when --apply-log-only is not specified:

 if (!srv_read_only_mode && !srv_apply_log_only) {
  /* Shutdown the FTS optimize sub system. */
  fts_optimize_start_shutdown();

  fts_optimize_end();
 }

The code in fts_optimize_thread() relies on the fact that by the time it has to shutdown the FTS_MSG_STOP message has already been received (so exit_event is initialized), i.e. fts_optimize_start_shutdown() has been called. Which is not the case when srv_apply_log_only is set.

[Vlad Lesin (vlad-lesin)]

Actually FTS optimize thread is started not always. It is not started if srv_archive_recovery is off. See the following code in innobase_start_or_create_for_mysql():

                recv_recovery_from_checkpoint_finish();

                if (srv_apply_log_only) {
                        goto skip_processes;
                }

So this is "apply archived logs" specific bug because it does not skip fts initialization.

[Vlad Lesin (vlad-lesin)]

The misprint in the previous comment.

"It is not started if srv_archive_recovery is off." should be read as "It is not started if srv_archive_recovery is ON."

[Alexey Kopytov (akopytov)]

OK, so the problem does not apply to any released version and should be fixed in the archived logs branch only. Thanks for investigating.

[Shahriyar Rzayev (rzayev-sehriyar)]

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