アップグレードに関する考慮事項

    アップグレード時に Content Services（非推奨）EAR のデプロイに失敗する

    注意： アドビは、Adobe® LiveCycle® Content Services ES のお客様に、コンテンツリポジトリへの移行をお願いしています。コンテンツリポジトリはモジュール化された最新の CRX アーキテクチャ上に構築されており、この CRX アーキテクチャは、アドビによる Day Software の吸収合併により利用可能になりました。コンテンツリポジトリ は LiveCycle Foundation に付属し、LiveCycle ES3 リリース以降で利用できます。

    LiveCycle へのアップグレード時に、Adobe® LiveCycle® Content Services 9（非推奨）EAR のデプロイメントが失敗し、次の例外メッセージが表示されることがあります。

    SchemaBootstr E org.alfresco.util.LogUtil error Schema auto-update failed org.alfresco.error.AlfrescoRuntimeException: A previous schema upgrade failed or was not completed. Revert to the original database before attempting the upgrade again.

    この問題は、LiveCycle データベースに ALF_BOOTSTRAP_LOCK テーブルが存在している場合に発生します。

    WebSphere のリソース使用率が高いので EAR のデプロイメントに失敗する

    WebSphere Application Server のリソース使用率が高い場合、アップグレード時に Content Services のデプロイメントに失敗することがあります。

    この問題を解決するには、次の手順を実行します。

    バックアップからの lccs_data のコンテンツとデータベースの復元

    1. データベースのバックアップコピーから、alf および avm で始まる名前のテーブルを復元して、元の Content Services データベースに戻します。

    2. バックアップコピーからコンテンツストアのルートにあるコンテンツを復元します。

    合計トランザクション存続時間タイムアウト値の拡張

    1. WebSphere Administrative Console で、Servers／Server Types／WebSphere application servers をクリックし、サーバー名をクリックします。

    2. Container Settings／Container Services／Transaction Service をクリックします。

    3. 「Configuration」タブで、「Total transaction lifetime timeout」設定の値を 900 秒に設定します。

    4. 「Apply」または「OK」をクリックします。

    5. アプリケーションサーバーを再起動します。

    異なる順序での EAR のデプロイ

    もう一度アップグレードを開始します。Configuration Manager で、Content Services EAR をデプロイしてからその他の EAR をデプロイします。

    1. LiveCycle EAR をデプロイ画面で、adobe-contentservices.ear を選択し、「デプロイ」をクリックします。

    2. Content Services EAR が正常にデプロイされたら、adobe-contentservices.ear の選択を解除し、その他の EAR を選択して「デプロイ」をクリックします。

    ALF_BOOTSTRAP_LOCK データベーステーブルが原因で EAR のデプロイメントに失敗する

    LiveCycle データベースに ALF_BOOTSTRAP_LOCK テーブルが存在する場合、アップグレード時に Content Services EAR のデプロイメントに失敗することがあります。

    この問題を解決するには、次の手順を実行します。

    1. バックアップから lccs_data のコンテンツとデータベースを復元します。WebSphere のリソース使用率が高いので EAR のデプロイメントに失敗するを参照してください。

    2. LiveCycle データベースから ALF_BOOTSTRAP_LOCK テーブルを削除し、アップグレードを再度開始します。

    3. Content Services EAR をデプロイしてから、その他の EAR をデプロイします。WebSphere のリソース使用率が高いので EAR のデプロイメントに失敗するを参照してください。

    アップグレード時に Content Services（非推奨）EAR ファイルが一部のノードにしかデプロイされない

    クラスター上の Content Services にアップグレードする場合、Content Services EAR ファイルは最初のノードにデプロイされますが、他のクラスターノードにはデプロイされません。次の 2 つの対処方法でこの問題を解決できますが、それぞれに欠点もあります。内容を確認し、どちらの対処方法が環境に最適かを判断してください。

    • アップグレード時、Configuration Manager を使用して Content Services EAR ファイルを設定するとき、LiveCycle のインデックスルートディレクトリに、以前の LiveCycle バージョンで指定した場所と異なる場所を指定します。この対処方法によって、クラスター内のすべてのノードを起動できます。

      注意： この方法を使用すると、Content Services リポジトリに多数のコンテンツが保存されている場合は、LiveCycle サーバーの起動に時間がかかることがあります。クラスターの各ノードがインデックスの再作成を試行するので、この問題が起こります。

    • EAR ファイルのデプロイ時に、クラスターのノードを 1 つだけ起動させるようにし、アップグレードプロセス全体を通して、そのノードにのみ関連する詳細を指定します。この手順によって、LiveCycle サーバーはインデックスの再作成を行わず、インデックスの更新のみを行うようになります。

      このノードが正常に起動したら、手動でこのノードのインデックスディレクトリをクラスターのその他のノード（Configuration Manager の実行を予定していないノード）にコピーします。コピーしたら、クラスターのその他のノードを起動します。これで、Content Services EAR ファイルはすべてのクラスターノードに正常にデプロイされます。

      注意： この対処方法は実装に時間がかかりますが、起動時のサーバーのダウン時間が最小限に抑えられます。