環境

Jira Data Center 9.x

要約

This article contains information regarding the upgrade to Jira 9.x in regards to the index

ソリューション

Jira のインデックス健全性に関連する変更

Jira 9.0 では、インデックスの健全性保護の改善に関連するいくつかの変更が導入されました。大部分は内部的なものですが、アップグレード手順およびインデックスに関連する機能の一部に影響します。

すべての課題、コメント、作業ログにおいて、インデックス バージョンの存在を内部的に強制

Jira 9.0 では、課題インデックスにおける下位互換性が無くなりました。以前はオプションだった、課題および関連エンティティのインデックス バージョン (Jira 8.9.0 で初導入) が、課題のライフサイクルの一部として強制適用されます。今後、すべての課題および関連エンティティが、データベースおよびインデックスの両方にインデックス バージョンを持つようになります。

これにより、バージョン化されていないエンティティ (Jira バージョン 8.9.0 以降にアップグレードする前に作成されたもの) を操作するために以前は追加で必要だった一貫性保護対応のコストを削減できます。

注意: これは、内部的な変更のみです (API への影響や、ユーザーおよびベンダーによるが初的な変更の必要性はありません)。ただし、実際的な影響が一部あります。

• Jira 9.0 にアップグレードするにはダウンタイムが必要です。最初のノードの開始時は、完全に完了するまでには長い時間を要する可能性のある操作が実行されます。詳細は、「アップグレード方法」セクションを参照してください。

• 完全なインデックス再作成プロセスの所要時間は若干長くなる可能性があります (当社によるテストでは、課題 1,000,000 件あたり最大 3 分増える可能性があると推定されています）

アップグレード方法

アップグレード手順には、システム内のすべての課題と関連エンティティのバージョンを生成ししてインデックスを再作成する手順が含まれます。これには、時間がかかる可能性がある 2 つのアップグレード タスクを実行する必要があります。これらのタスクは、9.0 へアップグレードするクラスター内の最初のノードの起動時に 1 回のみ実行されます。この間は、他のノードを起動することはできません。

すべての課題/コメント/作業ログの欠落するバージョンを生成する

このステップの所要時間は、データベース内のバージョン化されていないエンティティの数によって異なります。当社の負荷テストでは、以下の所要時間が確認されています。

MS SQL Server 13:

データセット:  課題 1,000,000 件、コメント 55,000,000 件、作業ログ 500,000 件

DB ハードウェア: db.r5.xlarge

すべてのバージョンの生成に要した時間: 9-10 分

MySQL 5.7.34:

データセット:  課題 1,000,000 件、コメント 55,000,000 件、作業ログ 500,000 件

DB ハードウェア: db.r5.xlarge

すべてのバージョンの生成に要した時間: 10 分

Oracle DB 19:

データセット:  課題 1,000,000 件、コメント 55,000,000 件、作業ログ 0 件

DB ハードウェア: db.r5.xlarge

すべてのバージョンの生成に要した時間: 8-9 分

PostgreSQL 10:

データセット: 10,000,000 課題, 101,000,000 コメント, 14,000,000 作業ログ 

DB ハードウェア: db.r5.xlarge

すべてのバージョンの生成に要した時間: 30-35 分

管理者は以下のクエリーを実行することで、欠落したバージョンの数を評価し、この手順にかかる時間を見積もることができます (オブジェクトの総数とアップグレードの期間の関係は比例して変化すると考えられるため、例の半分のサイズのデータでは、上記結果の ~ 0.5 の時間になるはずです)。

--- number of unversioned issues
select count(*)
FROM jiraissue
         LEFT JOIN issue_version ON issue_version.issue_id = jiraissue.id
         WHERE issue_version.issue_id is null;
--- number of unversioned worklogs
SELECT count(*)
FROM worklog
        LEFT JOIN worklog_version on worklog_version.worklog_id = worklog.id
        WHERE worklog_version.worklog_id is null;
--- number of unversioned comments
select count(*)
FROM jiraaction
        LEFT JOIN comment_version ON comment_version.comment_id = jiraaction.id
        WHERE actiontype = 'comment'  AND comment_version.comment_id is null;

インデックスの完全再作成

このステップでは、Jira 9.0 におけるインデックスの新要件に従って、完全なフォアグラウンドのインデックス再作成を実行します。「内部課題インデックスのバージョン」セクションで前述の通り、この操作には、インスタンスの通常時間＋システムに存在する各1,000,000 件の課題につき 3 分の時間がかかります。

その他のインデックス関連のアップグレードへの影響

レガシー インデックス パスの削除

インデックス関連ディレクトリの新たな構造 (New directory structure for indexes and index snapshots 参照) により、アップグレード中に以下のディレクトリがその内容とともに削除されます。

• 8.0 インデックス ディレクトリ

  • クラスターのみ:[sharedhome]/caches/indexesV1

  • [localhome]/caches/indexesV1

• 8.0 より前のインデックス ディレクトリ

  • クラスターのみ:[sharedhome]/caches/indexes

  • [localhome]/caches/indexes

レガシー スナップショットの手動削除が必要

レガシーインデックスパスの削除は、9.0 より前のパスに存在しているインデックス スナップショットには影響しません。

以下のパスに残るスナップショット

• [sharedhome]/export/snapshots

• [sharedhome]/caches/

は、現在のロケーションに残りますが、9.0 におけるすべてのスナップショット関連の操作で無視され、手動での削除が必要です。

注意：これらのスナップショットは、Jira 9.0 のインデックス作成ロジックとの互換性がなく、これらをインデックスの復元に使用すると、パフォーマンスや整合性に深刻な問題が生じる可能性があります。

インデックスとインデックス スナップショットの場所および名称の変更

インデックス ファイルの場所およびインデックス スナップショットの場所の両方が、Jira 9.0 で変更されています。

手動でコピーされたインデックス スナップショット ([sharedhome]/import/indexsnapshots) の復元をトリガーするためにダメージ リカバリ パスで使用されるパスは変更されません。

なお、Jira 9.0 以降、すべてのインデックス スナップショットは、その起源に関係なく、同じパターンに従って命名されています。

IndexSnapshot_[uniqueNumber]_[yyMMdd-HHmmss].[tar.sz|tar|zip]

スナップショット ディレクトリに保存するスナップショットの最大数を設定する新しい方法（オーバーライドの手動移行が必要）

インデックス スナップショット作成終了時に、スナップショット ディレクトリからは古いスナップショットが削除され、3 件の最近のスナップショットのみが残ります。9.0 より前の Jira では、この値は、 Jira インデックス スナップショット サービス では、サービス プロパティを 保持するバックアップ数 の設定によってオーバーライドされる可能性があります。

Jira 9.0 の時点においては、このプロパティはすべてのスナップショットに影響し、そのため、インデックス スナップショット サービスとは独立して、アプリケーション プロパティ jira.index.snapshot.count として設定されます。

この値がオーバーライドされたインスタンスの管理者は、オーバーライドされた値を新しいアプリケーション プロパティに手動で移行する必要があります。

スナップショットを要求されたノードは、インデックスが破損している場合に、スナップショットを生成しなくなりました。

クラスタ内で破損したインデックスが拡がることを防ぐため、ノードはスナップショットの作成をトリガーされるとインデックスのヘルスチェックを実行します。これは、スナップショットが作成されるすべての操作に影響します。

• 管理パネル リクエスト

• スケジュールされたインデックス作成

• クラスターに参加するノードによるリクエスト

詳細は、Indexing inconsistency troubleshootingを参照してください。