タスクのアップグレードのトラブルシューティング

新しい機能を導入またはアプリに大幅な変更を加える際に、データベースまたはインデックスにある既存のデータを変換または一部のデータの保存方法を変更する必要が生じる場合があります。  

簡単な例を次に示します。データベースの location 列に「オーストラリア、シドニー」を保存したものの、後で都市と国の情報を個別に保存することにした場合は、アップグレード タスクを使用して location 列の既存のデータを取り出し、citycountry 列にそれぞれ「シドニー」「オーストラリア」を分割して保存できます。実際のアップグレード タスクはこれほど単純ではありませんが、基本的な手順は同じです。  

On this page:

バグ修正リリースにはアップグレード タスクを必要とする変更は含まれませんが、機能とプラットフォームの各リリースでは極めて一般的です。ビルド番号が現在のバージョンと異なるかどうかを確認することで、バージョンにアップグレード タスクがあるかどうかを判別できます。 

アップグレード タスクはいつ実行されますか? 

アップグレード タスクのタイプと、アップグレード時のダウンタイムの有無によって異なります。 

ダウンタイムなしのローリング アップグレード

ローリング アップグレードを実行している場合 

  • ノード固有のアップグレード タスクは、そのノードでアプリが起動する直前に行われます。 
  • クラスタ全体のアップグレード タスクは、すべてのノードが新しいバージョンを実行しており、ローリング アップグレード画面で [アップグレード タスクを実行] と [アップグレードを完了] を選択すると実行されます。

ローリング アップグレード中、古い形式と新しい形式の両方のデータが短期間共存する場合があります。クラスタ全体のアップグレード タスクには、データベース内のデータを変換するタスクが含まれます。また、各ノードの共有ホーム ディレクトリとローカル ホーム ディレクトリの変更も含まれます。これらのタスクを実行するには、すべてのノードがアップグレードされている必要があります。

以上の例を使用すると、まだアップグレードされていないノードは location 列に引き続き書き込んで、アップグレードされたノードは新しい city 列と country 列に加えて、古い location 列にも書き込みます (ロールバックが必要な場合にデータが失われることを防ぐため)。すべてのノードをアップグレードした後は、location フィールドにある既存のデータを新しい citycountry の各フィールドに分割しても安全です。これは多くの場合でアップグレード タスクの一部であり、データ量によっては時間がかかることがあります。 

ダウンタイムを伴うアップグレード

クラスタ化されていないデプロイをアップグレードする際は、通常、アップグレード タスクはアップグレード後にアプリが起動する直前に実行されます。

(ローリング アップグレードではなく) ダウンタイムのあるクラスターをアップグレードすると、最初のノードの起動時にクラスター全体のアップグレード タスクが実行されます。

失敗したアップグレード タスクのトラブルシューティング

アップグレード タスクが失敗した場合は、問題を解決するためにいくつかの作業を行う必要があります。 

アプリ ログを確認する

最初のステップでは、アプリ ログを確認します。Confluence をクラスタで実行している場合は、複数のノードでログを確認する必要があることがあります。 

ネットワークのタイムアウト、ローカルまたは共有ホーム ディレクトリのディスク容量不足、データベース ユーザー/Confluence ユーザーのアクションを完了するための権限が不十分であるなど、原因が明らかになることがあります。  

データベース設定を確認する 

アップグレード タスクが失敗する最も一般的な理由には、次のものが含まれます。

  • データベース ユーザーには、必要なアクションを実行するための適切な権限がありません 
  • データベース設定が正しくない (文字セットやエンコーディングなど) 
  • データベースのバージョンまたはエディションがサポートされていない

こうした場合、通常はアプリ ログにデータベース エラーが書き込まれます。特定の問題に関するナレッジベース記事を参照の上、設定がアトラシアンのドキュメントで指定されているデータベース設定と一致しているかどうかをご確認ください。 

アップグレード タスクを再実行する

すべての問題を解決後、アップグレード タスクを再実行する必要があります。この方法は、アップグレード時のダウンタイムの有無によって異なります。 

  • ローリング アップグレードを実行している場合は、障害が発生したノードでアプリを再起動したあとに [アップグレード タスクの再実行] と [アップグレードを完了] を選択します。
  • ダウンタイムありでアップグレードする場合は、アプリを再起動します。アップグレード タスクは、アプリを起動する前に実行されます。  

アプリをアップグレード モードのままにしないでください

ローリング アップグレードを実行する場合は、クラスターを必要以上に長くアップグレード モードのままにしないことが重要です。これは、最終的なアップグレード タスクが実行されるまで、複数の方法で処理する必要があるデータが存在する場合があるためです。 

 既知の問題

  • Microsoft SQL Server の一部の Enterprise エディション以外では、オンラインのインデックス作成がサポートされていないものもあります。アップグレード タスクで排他的なテーブル ロックを取得する必要がある場合は、パフォーマンスの低下やダウンタイムが発生することがあります。データベースのエディションによって影響を受ける可能性があることが検知された場合は、警告します。 
最終更新日 2024 年 4 月 2 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.