Combined: Archiving issues and reindexing outside of the cluster

ユーザーのダウンタイムを最小化するため、課題をアーカイブしてインデックスから除外することによってインデックスのサイズを削減し、本番環境クラスタの外部でインデックスを作成します。動作するインデックスを用意して、Jira をユーザーに開放できます。後ほど、実行中の Jira で、すべてのアーカイブ済みの課題を復元して再インデックスします。

概要

このアプローチでは、課題のアーカイブと本番環境クラスタ外部での再インデックスを組み合わせます。

はじめる前に

アーカイブする課題の特定

このステップでは、アップグレード直後は不要な課題を特定します。

課題をアーカイブするための SQL クエリの作成

アーカイブする課題を特定したら、それらをアーカイブする SQL クエリを作成する必要があります。弊社で用意したサンプル クエリをいくつか紹介します (PostgreSQL データベースを使用)。

update jiraissue 
	set 
		archived='Y', 
		archivedby='admin', 
		archiveddate=current_timestamp 
	where id in (
		select 
			i.id 
		from jiraissue i 
		where i.created < timestamp '2019-01-01'	
);

update jiraissue 
	set 
		archived='Y', 
		archivedby='admin', 
		archiveddate=current_timestamp 
	where id in (
		select 
			i.id 
		from jiraissue i 
		where i.updated < (current_timestamp - interval '2 year')	
);

update jiraissue 
	set 
		archived='Y', 
		archivedby='admin', 
		archiveddate=current_timestamp 
	where id in (
		select 
			i.id 
		from jiraissue i 
		inner join project p on i.project = p.id
		inner join label l on l.issue = i.id
		where UPPER(p.pkey) = 'JIRA' 
			and l.label = 'archive'
			and i.created  between timestamp '2019-01-01' and timestamp '2019-10-01'	
);

データベースの書き換え

ダウンタイムを最小化するため、稼動中のデータベースで次のステップを実行できます。

これらのステップはデータベース スキームを書き換え、課題のアーカイブに必要なコラムを含めるようにします。

1. 課題のアーカイブをサポートするようにデータベース スキームを書き換えます。次の SQL クエリは、jiraissue  テーブルに 3 つの新しいコラムを追加します。 

   • PostgreSQL

     alter table jiraissue
             add archived char default null,
             add archivedby varchar(255) default null,
             add archiveddate timestamp with time zone default null;

   • Oracle

     alter table jiraissue add (
         archived CHAR default null,
         archivedby varchar2(255) default null,
         archiveddate date default null);

2. 新しいコラムが追加されたら、すべての課題のステータスを "not archived" に設定する別の SQL クエリを実行します。 

   update jiraissue set archived='N', archivedby=null, archiveddate=null;

3. 念のため、Jira を開き、新しい課題をいくつか作成して、すべてが正常に動作していることを確認します。

4. 選択した課題をアーカイブする SQL クエリを実行します。これは「課題をアーカイブするための SQL クエリを作成する」で用意したものです。ソース バージョンの 7.x では、"archived" 課題が変更されることはありません。

クラスタ外部でインデックスを作成

データベースのコピーを作成し、Jira 8.5 をそれに接続します。これにより、本番環境クラスタの外部で Jira 8 との互換性を持つインデックスを作成できます。

1. NodeIndexCounter テーブルのコピー

• データベースで NodeIndexCounter テーブルのコピーを作成します。

この操作が必要な理由

NodeIndexCounter テーブルは、個々のノードからそれらのインデックスのコピーに適用された変更を記録します。このタイミングでコピーし、元のデータベースにあとから (アップグレード中に) 復元することで、この時点でユーザーが行った可能性があるすべての変更をアップグレードされたノードに含めることができます。

2. データベースのコピー

• 稼動中のデータベースのコピーを作成します。あとから元のデータベースに切り替えるため、ユーザーによる新規データの追加について心配する必要はありません。

3. データベースのコピーを Jira 8.5 に接続

データベースのコピーを接続する、別の Jira 8.5 環境が必要です。この環境の要件は次のとおりです。

• Jira 8.5 である必要があります。

• 本番環境インスタンスと同じプラグインを持っている必要があります (プラグインはカスタム フィールドからの値を保持していたり、再インデックス中にインデックスにデータを追加したりしている可能性があります)。

• Data Center ライセンスを使用している必要があります (Server 版では課題のアーカイブが認識されません)。ただし、シングル ノード構成を使用できます。

この環境をセットアップするもっとも簡単な方法は、次のステップを完了することです。

1. 「Jira Data Center のアップグレード」の「最初のノードで Jira をアップグレードする」の手順に従います。Jira 8.5 を構成する際は、ここまでのステップで作成したデータベースのコピーに接続するようにします。

2. 「Jira Data Center のアップグレード」の「最初のノードでのアップグレード後の手順」の手順に従います。 

結果

手動の再インデックスを完了したら、データベースのコピーの情報に基づいた Jira 8 インデックスを用意できます。コピーの作成後に元のデータベースに加えられた情報は含まれませんが、不足している変更エントリのノードでの追加は、インデックス全体をゼロから作成するよりも簡単に行えます。

インデックスをノードにコピー

Jira 8 のインデックスは既存のクラスタに影響しないよう、古いバージョンとは別のディレクトリに保管されます。新しいインデックスを各ノードにコピーし、ノードでのダウンロードを不要にできます。

1. Jira 8 のインデックスを各ノードの次のディレクトリにコピーします。 

   <local-home-directory>/caches/indexesV1

Jira Data Center のアップグレード

最初のノードのアップグレード

Jira Data Center のアップグレードでは時間の削減のため、1 つのノードを選択してそれをアップグレードし、インストール ディレクトリをほかのノードにコピーすることをおすすめします。ここでは任意のノードを選択できます。

1. クラスタを停止します。

2. この手順の最初にコピーした NodeIndexCounter テーブルを元のデータベースに復元します。これにより、アップグレードの開始後に元のデータベースに追加されたすべての情報について、ノードでエントリが作成されます。

3. 最初のノードをアップグレードします。「Jira Data Center のアップグレード」の「最初のノードで Jira をアップグレードする」の手順に従います。作業を開始する前に次のメモをご確認ください。 

   自動再インデックスの無効化

   リンク先の手順の最後のステップには、自動再インデックスを無効化する旨の説明があります (ステップ 5: 自動再インデックスの無効化)。この手順を確実に完了するようにします。未完了の場合、Jira で自動再インデックスが開始され、この手順の目的を果たすことができません。

4. 最初のノードでアップグレード後の手順を完了します。「Jira Data Center のアップグレード」の「最初のノードでのアップグレード後の手順」の手順に従います。 

   ステップの 1 つでインデックスを再インデックスするように促されます。このステップは除外するようにします。インデックスはクラスタ外部で作成済みのため、再作成する必要はありません。

実行される内容について

最初のノードの開始後、データベースがアップグレードされます。次のステップとして、ノードはインデックスの状態を確認し、必要に応じて再インデックスします。ただし、互換性のあるインデックスをすでにコピー済みであるため、ノードはこれを検出し、不足している変更のエントリ (元のデータベースと、Jira 8 インデックスを作成するために使用したクローンされたデータベースとの違い) の追加のみを行います。ノードの観点では、短期間オフラインになっていたのと同じ状況と見なされます。

オプション: インデックスのスナップショットのリクエスト

このオプションのステップでは、ノードでデータベースの更新を処理するのではなく、最初のノードのインデックスのスナップショットをダウンロードします。

残りのノードのアップグレード

これで、インストール ディレクトリを残りのノードにコピーしてそれらをアップグレードできます。

1. 残りのノードをアップグレードします。「Jira Data Center のアップグレード」の「残りのノードのアップグレード」の手順に従います。

アーカイブされた課題の復元と再インデックス

Jira Data Center のアップグレードが完了し、機能していることを確認したら、アーカイブされた課題を復元して再びインデックスを作成します。再インデックスは 1 つのノードで行われるため、ユーザーは引き続き Jira を利用できます。

1. アーカイブされた課題のステータスを "not archived" に変更する、逆の SQL クエリを実行します。次のクエリを使用してすべての課題のステータスを変更できます。

2. 再インデックスを実行します。

   1. > [システム] > [再インデックス] に移動します ("." を押して検索できます)。

   2. [完全な再インデックス] を選択します。 

再インデックスの完了には時間がかかりますが、ユーザーは引き続き Jira を利用できます。完了後、新しいインデックスが残りのノードに自動的に配布されます。