Package com.atlassian.jira.index.ha

Interface IndexRecoveryManager

All Superinterfaces:
Sized
All Known Implementing Classes:
DefaultIndexRecoveryManager
public interface IndexRecoveryManager extends Sized
Manager to recover an index from a previous index backup
Since:
v6.2

  • Field Details

  • Method Details

    • safeRecoverIndexFromBackup

      IndexCommandResult safeRecoverIndexFromBackup(File recoveryFile, TaskProgressSink taskProgressSink) throws IndexException
      Recovers an index from an index backup. This method throws and stops processing if it's not able to calculate the duration where catch up needs to be applied.
      Parameters:
      recoveryFile - The backup file
      taskProgressSink - The sink to report progress back.
      Throws:
      IndexException - If we are unable to recover the index or catch up after recovery is successful

    • recoverIndexFromBackup

      IndexCommandResult recoverIndexFromBackup(File recoveryFile, TaskProgressSink taskProgressSink) throws IndexException
      Recovers an index from an index backup. Unlike the safeRecoverIndexFromBackup(java.io.File, com.atlassian.jira.task.TaskProgressSink) this method won't throw exception when not being able to to calculate the duration where catch up needs to be applied. It will skip the catch up and continue with other steps.
      Parameters:
      recoveryFile - The backup file
      taskProgressSink -
      Throws:
      IndexException - If we are unable to recover the index or catch up after recovery is successful

    • getDurationToCatchUpUsingVersions

      com.atlassian.core.util.DateUtils.DateRange getDurationToCatchUpUsingVersions()
      Gets the updated date range for issues that need to be re-indexed because the latest updates are missing from the index. The range is
      from
      Latest date in the index
      to
      Latest date in the database
      The range can actually be negative, indicating there are indexed updates which do not belong and so may need to be removed.
      Note: the latest db date is based on the issue_version table. If no versions are present, we fall back to the issues table (although deletes will not be reflected here).
      Returns:
      Date range of issues that need to be re-indexed.
      Since:
      v6.4

    • reindexWithVersionCheckEntitiesUpdatedInTheLast

      IndexRecoveryResult reindexWithVersionCheckEntitiesUpdatedInTheLast(Duration duration, TaskProgressSink taskProgressSink) throws IndexException, SearchException
      This method uses versioning to short-circuit building documents when the index version is already up-to-date with what's in the db.

      Ensures that issues which have been modified between now and duration ago are up-to-date in the index. They are reindexed/deindexed as needed to achieve this.

      Parameters:
      duration - specifies how far back (from present time) to look for updated issues
      taskProgressSink - A progress sink.
      Returns:
      Report how much time the operation took and how many issues were affected
      Throws:
      IndexException
      SearchException
      Since:
      8.10

    • deindexEntitiesDeletedInTheLast

      IndexRecoveryResult deindexEntitiesDeletedInTheLast(Duration duration, TaskProgressSink taskProgressSink) throws IndexException
      Applies de-index based on the versioning table (delete column.* Why this method may be needed? It is possible in Jira (both server and DC) that a late "update" will override a "delete". To handle this problem, Jira has to replay de-index operations after "some time". See: EntityVersioningManager) See: VersioningDao See: NodeReindexService See: DefaultServerIndexRepairService
      Parameters:
      duration - specifies how far back (from present time) to look for deleted issues
      taskProgressSink - A progress sink.
      Returns:
      result of de-indexing
      Throws:
      IndexException
      Since:
      8.14