Jira Data Center のアップグレード (手動)
このページでは、アーカイブを使用して Jira Data Center (クラスタ) を手動でアップグレードする方法について説明します。
別のアップグレード方法をお探しの場合は、「Jira アプリケーションのアップグレード」を参照してください。
次のセクションにジャンプ
はじめる前に
ステップ 1: Jira ホーム ディレクトリを検索して初期インストール方法を決定する
初めてインストールしたときと同じ方法で Jira をアップグレードすることをお勧めします。方法かわからない場合は、Jira ホーム ディレクトリの場所を検索してください。通常は、これによって Jira を手動でインストールしたか、バイナリ インストーラーからインストールしたかがわかります。詳細については「Jira アプリケーション ホームディレクトリ」をご参照ください。
ステップ 2: アップグレードの準備
アップグレードの準備の手順が完了したことを確認します。これらは必須の前提条件であり、アップグレードをスムーズに進めるためには不可欠です。
ステップ 3: バージョンの選択
最適なバージョンの選択にお悩みの場合、アップグレード マトリクスですべての Jira バージョンの機能、サポート対象のプラットフォーム、およびアップグレードに関する技術的な注意事項を確認できます。
ステップ 4: クラスタの停止
ゼロ ダウンタイムで Jira Data Center をアップグレードする場合、この手順を省略します。
クラスタのすべてのノードで Jira を停止します。アップグレードがすべてのノードで完了するまでは、ロード バランサで Jira からトラフィックをリダイレクトするように設定しておくことをおすすめします。
最初のノードで Jira をアップグレードする
各ノードを個別にアップグレードするのを避けるため、1 つのみをアップグレードしてから、それをテンプレートにします。次に、このテンプレートを残りのノードにコピーします。ここでは任意のノードを選択できます。
ステップ 1. Jira のダウンロード
- アトラシアンの Web サイトからいずれかの Jira アプリケーションをダウンロードします。tar.gz または zip アーカイブを選択します。
- Jira Software
- Jira Service Management (tar.gz アーカイブのみ)
Jira Software と Jira Service Management の両方をアップグレードする場合、Jira Software のみをアップグレードします。Jira Service Management は、個別のインストーラーは使用せず、後ほど Jira で直接アップグレードします。
ステップ 2. ファイルの展開
ダウンロードしたファイルを展開し、アップグレードを開始します。
- ディレクトリ (新しいインストールディレクトリ。既存のインストール ディレクトリとは異なる必要があります) にファイルを展開 (解凍) します。
Jira が 既存の Jira ホーム ディレクトリを指すようにします。
JIRA_HOME環境変数の設定で行うことをおすすめします。この方法の詳細については、「Jira ホーム ディレクトリの設定」を参照してください。
ステップ 3. データベース ドライバのインストール
Oracle または MySQL データベースを使用している場合、新しい JDBC ドライバをダウンロードします。それ以外のデータベースの場合、この手順を省略できます。
ドライバが最新の場合、以前のバージョンからコピーすることもできます。
- 次のドライバのいずれかをダウンロードします。
- Oracle: JDBC ドライバ 19.3 (ojdbc8)
- MySQL: MySQL Connector/J 5.1 ドライバ。
<installation-directory>/libに配置します。
ステップ 4: 任意のカスタム変更を再適用して pool-max-size を増やす
Jira を使用する際、Jira ファイルにカスタム変更を行う場合があります。このような変更には、接続の詳細、メモリ割り当てに関する設定や、他の JVM 引数などが含まれます。通常、次のファイルがカスタム変更を含みます。
server.xmldbconfig.xmljira-config.propertiesweb.xml
詳細については、「Jira の重要なファイル」をご参照ください。
Jira を SSL 経由で実行している場合は、これらのファイルに加えて証明書をトラスト ストアに再インポートする必要があります。手順については、「JVM にパブリック SSL 証明書をインポートする方法」をご参照ください。
バックアップからカスタム変更をそれぞれの新しい Jira ファイルにコピーすることで、それらを再適用します。
古いファイルに含まれる "ネイティブ" 設定が Jira バージョン間で変更されている可能性があるため、単純に古いファイルをコピーしないようにしてください。
Jira の起動時に再度確認が行われ、ユーザーがスキップした可能性があるすべてのファイルのうち、まだコピーされていない変更が含まれるものが表示されます。これをクリックして変更を自動的にコピーできます。
確認は、次の設定ファイルに対してのみ実行される点にご注意ください。
- <jira-home-directory>/atlassian-jira/ directory
- <jira-home-directory>/conf/server.xml
- <jira-home-directory>/bin/setenv.sh
自動転送は ATST プラグイン 1.20.0 以降でのみサポートされます。
変更を自動的に転送するには、変更されたファイルのインストーラーのコピーがアップグレード後のバージョンと同じである必要があります。
「*」が含まれる catalina.sh で JAVA_OPTS を拡張すると Linux の起動が停止するバグにより、バージョン 8.5.48 以降、Tomcat で二重引用符が使用されています。このため、setenv.sh または setenv.bat でパラメーターをアップグレードして設定する際は、以下を確認してください。
- catalina.sh の二重引用符を削除しない
- setenv.sh または setenv.bat に新しい行を使用しないで、すべてのパラメーターを 1 行に設定する
それ以外の場合、Jira の開始時に問題が発生する可能性があります。
pool-max-size
Jira 7.x から 8.x や 9.x などの次のプラットフォーム バージョンにアップグレードする場合は、アップグレード前に dbconfig.xml で pool-max-size パラメーターを 40 に変更することをお勧めします。既定値の 20 のままにしておくと、データベース接続に関連するさまざまな問題が発生する可能性があります。変更の実装に関する詳細については「データベース接続の調節」をご参照ください。
ステップ 5. 自動再インデックスの無効化
このステップは、プラットフォーム バージョン間でアップグレードする際に推奨されます。たとえば、Jira 7.x から 9.x に、または Jira 7.x から 8.x に切り替える際などです。
Jira の機能リリース間ですでにアップグレードしている場合 (たとえば 8.13 から 8.20 に)、このステップを省略できます。
Jira プラットフォームのバージョン 8.x と 9.x 間に導入されたインデックスの変更によって、古い Jira バージョンのインデックスはアップグレード後に互換性がなくなります。
新しいインデックスを作成するために、Jira は起動後に自動再インデックスをトリガーします。自動再インデックスを無効にして準備が整い次第 2 つ目の再インデックスを実行することで、二重に再インデックス (起動後とアプリのアップグレード後) されるのを回避できます。
自動再インデックスを無効にするには、次の手順に従います。
次のファイルを編集または作成 (存在しない場合) します。
<jira-home-directory>/jira-config.properties次の行をこのファイルに追加して変更を保存します。
upgrade.reindex.allowed=false
最初のノードでのアップグレード後の手順
最初のノード (先ほどアップグレードしたもの) でのみ、次のアップグレード後の手順を完了します。残りのノードでは後ほど、共有ディレクトリからアップグレード後のアプリとインデックスをダウンロードします。
ステップ 1. Jira の初回起動
新しい Jira バージョンを起動してデータベースに接続します。
- (インストーラー) アップグレード ウィザードに戻って、Jira を起動します。
(インストーラーおよび手動)<installation-directory>/binに進み、以下のファイルのいずれかを実行して Jira を起動することもできます。- Windows:
start-jira.bat - Linux:
start-jira.sh
- Windows:
- ブラウザで Jira を開きます。
- 画面の指示に従い、セットアップを完了します。
カスタム変更を加えたファイルで、まだコピーされていないものがある場合、ここで変更を自動的にコピーできます。
ファイルの変更の確認は次の設定ファイルに対してのみ実行される点にご注意ください。
- atlassian-jira/ directory
- conf/server.xml
- bin/setenv.sh自動転送は ATST プラグイン 1.20.0 以降でのみサポートされます。
変更を自動的に転送するには、変更されたファイルのインストーラーのコピーがアップグレード後のバージョンと同じである必要があります。変更のコピー後、Jira を再起動するように求められます。
アップグレード後のランディング ページ
アップグレードが完了したら、アップグレード後のランディング ページが表示されます。以下のように、新しいバージョンについての便利な情報も記載されています。
- Need to know: 管理者としての作業に影響を与える可能性がある、新機能の一覧。
- User apps: アップグレード後のアプリのステータス。
- Application links: アプリケーション リンクのステータス。
- Release notes: アップグレード先のバージョンに関する詳細な情報を確認できるリリース ノートへのリンク。
ステップ 2. (オプション) Jira Service Management を更新
Jira Service Management を使用している場合、個別のインストーラをダウンロードせずに UI で直接更新できます。
- [管理] (
) > [アプリケーション] > [バージョンとライセンス] に移動します。 - Jira Service Management を更新します。これによって、Jira Service Management は自動的に互換性のあるバージョンに更新されます。
ステップ 3. アプリ (アドオン) のアップグレード
これで、"Compatible if both upgraded" ステータスのアプリをアップグレードできます。これらのステータスおよびアプリ全般に関する詳細情報が必要な場合、「アップグレードの準備」を参照してください。
- [管理] () > [アプリの管理] > [アプリの管理] に進みます。
- アプリをサポート対象バージョンにアップグレードします。
- アプリがアップグレードされたら、それを有効化できます。
DC クラスタでのアプリのアップグレード
アプリをアップグレードする際に、各ノードは再起動時に共有ホームから最後に変更されたアプリ jar ファイルをプルします。
ファイル バージョンを確認するために、Jira は atlassian-plugin.xml. 内の <version> 値を使用します。複数の <version> 値がある場合、Jira は java.lang.String#compareTo を使用してこの異なる値を比較します。
ステップ 4. インデックスの再構築
インデックスを再作成するために Jira を再インデックスします。課題とアプリの数に応じて、このステップには時間がかかる可能性があります。
- [管理] () > [インデックス] に移動して、Jira をロックしてインデックスを再構築を実行します。
ステップ 5. アップグレード済みの Jira をテンプレートとしてコピー
このステップでは、これまでに実行したすべての変更を含む新しいインストール ディレクトリをコピーします。これによりテンプレートが作成され、後で他のノードにコピーすることができます。
- 新しいインストール ディレクトリを別の場所にコピーします。これがテンプレートになります。
残りのノードをアップグレードする
Jira テンプレートの準備が整い、共有ディレクトリでアップグレード済みのアドオンとインデックス データが利用できるようになりました。このステップでは、テンプレートを別のノードにコピーし、1 つずつ起動します。
- テンプレートのインストール ディレクトリを新しいノードにコピーします。
- このノードでローカル ホーム ディレクトリへのパスが異なる場合、
setenv.bat/setenv.shファイルでそれを更新します。 - このノードで Jira を起動します。
- 繰り返し: 次のノードでこれらのステップを繰り返します。
クラスタへの参加
[管理] () > [システム] > [システム情報] に移動し、[クラスタ ノード] セクションにスクロールして、アップグレード後のノードがクラスタに参加しているかどうかを確認できます。
おつかれさまでした
Jira が新しいバージョンにアップグレードされました。