現在表示中:

このページでは、レプリケーションに関する問題のトラブルシューティング方法について説明します。

問題

レプリケーション(順方向のレプリケーション)が何らかの原因で失敗する

解決方法

レプリケーションが失敗するのには様々な原因があります。ここでは、これらの問題を分析する際に採用できるアプローチについて説明します。

「アクティベート」ボタンをクリックすると、レプリケーションがトリガーされますか。トリガーされない場合は、次の操作をおこないます。

  1. /crx/explorer(CQ5.5)に移動し、管理者としてログインします。
  2. 「Content Explorer」を開きます。
  3. ノード /bin/replicate または /bin/replicate.json が存在するかを確認します。ノードが存在する場合は、削除して保存します。

レプリケーションがレプリケーションエージェントのキュー内で待機している状態ですか。

確認するには、/etc/replication/agents.author.html に移動し、レプリケーションエージェントをクリックします。

1 つまたは複数のエージェントキューで動きがない場合:

  1. キューのステータスには「ブロック」と示されていますか。その場合に、パブリッシュインスタンスは実行されていないか、完全に応答しない状態ですか。パブリッシュインスタンスを確認し、何が問題かを調査します。例えば、ログをチェックして、OutOfMemory エラーなどの問題が発生していないかを確認します。単に一般的な遅延が発生している場合は、スレッドダンプを取得して分析します。
  2. キューのステータスは「Queue is active - # pending」と示されていますか。基本的に、レプリケーションジョブはソケット読み取りにおいて、パブリッシュインスタンスまたは Dispatcher の応答待ちで動かなくなる可能性があります。この場合、パブリッシュインスタンスまたは Dispatcher が高負荷の状態か、ロックによって動かない状態になっている可能性があります。そのような場合は、オーサーまたはパブリッシュでスレッドダンプを取得してください。
    • スレッドダンプアナライザーでオーサーのスレッドダンプを開き、レプリケーションエージェントの sling イベントジョブが socketRead で動かなくなっていないかを確認します。
    • スレッドダンプアナライザーでパブリッシュのスレッドダンプを開き、パブリッシュインスタンスが応答しない原因を分析します。オーサーからレプリケーションを受信するスレッドである POST /bin/receive という名前のスレッドを確認します。

すべてのエージェントキューに動きがない場合

  1. リポジトリの破損などの問題があり、コンテンツの特定の部分を /var/replication/datadue にシリアライズできない可能性があります。logs/error.log で、関連するエラーがないか確認してください。不正なレプリケーション項目を除去するには、次の操作をおこないます。
    1. http://<host>:<port>/crx にアクセスし、管理者ユーザーでログインします。CQ5.5 では、http://<host>:<port>/crx/explorer にアクセスします。
    2. 「Content Explorer」をクリックします。
    3. Content Explorer ウィンドウの右上にある虫眼鏡ボタンをクリックすると、検索ダイアログがポップアップします。
    4. 「XPath」ラジオボタンを選択します。
    5. 「クエリ」ボックスに、「/jcr:root/var/eventing/jobs//element(*,slingevent:Job) order by @slingevent:created」というクエリを入力します。
    6. 「検索」をクリックします。
    7. 検索結果の上位の項目が、最新の Sling イベントジョブです。各ジョブをクリックして、キューの一番上に表示されるものと同じ、動きのないレプリケーションを見つけます。
  2. Sling イベントフレームワークジョブのキューに問題が発生している可能性があります。/system/console の org.apache.sling.event バンドルを再起動してみます。
  3. ジョブの処理が完全に無効になっている可能性があります。Felix コンソールの「Sling Eventing」タブで確認できます。Apache Sling Eventing (JOB PROCESSING IS DISABLED!) と表示されるか確認します。
    • 表示される場合は、Felix コンソールの「Configuration」タブで Apache Sling Job Event Handler を確認します。「Job processing Enabled」チェックボックスがチェックされていない場合があります。このチェックボックスがチェックされているのに「job processing is disabled」と表示される場合は、ジョブの処理を無効にしているオーバーレイが /apps/system/config にないか確認します。osgi:config ノードを作成し、jobmanager.enabled のブール値を true にして、アクティベートを開始したらキューにジョブが残っていないかを再確認します。
  4. また、DefaultJobManager 設定に不整合がある状態になる場合もあります。OSGi コンソール経由で「Apache Sling Job Event Handler」を手動で変更したユーザーがいる場合にこのような事態になります(例えば、「Job Processing Enabled」プロパティを無効にした後に再度有効にして、設定を保存した場合)。 
    • この時点で、crx-quickstart/launchpad/config/org/apache/sling/event/impl/jobs/DefaultJobManager.config に保存されている DefaultJobManager 設定に不整合がある状態になります。さらに、「Apache Sling Job Event Handler」プロパティで「Job Processing Enabled」がチェックされた状態でも、いずれかのユーザーが「Sling Eventing」タブに移動すると、「JOB PROCESSING IS DISABLED」というメッセージが表示され、レプリケーションが動作しません。
    • この問題を解決するには、OSGi コンソールの Configuration ページに移動して、「Apache Sling Job Event Handler」設定を削除する必要があります。次に、クラスターのマスターノードを再起動して、設定を整合性のある状態に戻します。この操作によって問題が修正され、レプリケーションが再び動作を開始します。

replication.log の作成

すべてのレプリケーションログを、個別のログファイルに DEBUG レベルで追加するように設定すると、場合によっては非常に便利です。次の手順を実行します。

  1. http://host:port/system/console/configMgr にアクセスし、管理者でログインします。
  2. Apache Sling Logging Logger ファクトリを探して、ファクトリ設定の右側の「+」ボタンをクリックしてインスタンスを作成します。新しいログロガーが作成されます。
  3. 次のように設定します。
    • ログレベル:DEBUG
    • ログファイルのパス:(CQ5.4、5.3)../logs/replication.log(CQ5.5)logs/replication.log
    • カテゴリ:com.day.cq.replication
  4. 問題が何らかの形で Sling イベントまたはジョブに関連する疑いがある場合は、この Java パッケージをカテゴリ org.apache.sling.event に追加することもできます。

レプリケーションエージェントキューの一時停止

オーサーシステムの負荷を軽減するために、レプリケーションキューを無効にせずに一時停止することが適している場合があります。現在、これをおこなう唯一の方法は、無効なポートを一時的に設定することです。5.4 以降は、レプリケーションエージェントキューに一時停止ボタンが表示されますが、一部の制限があります。

  1. 状態が永続化されません。そのため、サーバーまたはレプリケーションバンドルを再起動すると、実行中の状態に戻ります。
  2. 一時停止は短い期間(他のスレッドによるレプリケーションを含むアクティビティがなくなってから 1 時間)アイドル状態になりますが、長い期間は不可能です。スレッドのアイドル状態を防ぐ機能が Sling にあるからです。基本的には、ジョブキュースレッドが長い期間未使用の状態であるかを確認し、そうである場合はクリーンアップサイクルを開始します。クリーンアップサイクルによってスレッドが停止するので、一時停止されている設定が消失します。ジョブは永続化されるので、新しいスレッドを開始してキューを処理します。このキューには、一時停止設定の詳細情報がありません。そのため、キューが実行状態になります。

ユーザーのアクティベート時にページ権限がレプリケートされない

ページ権限は、ユーザーに付与されるのではなく、アクセス権が付与されるノードに保存されるので、レプリケートされません。

ページ権限は一般的にオーサーからパブリッシュにレプリケートするべきではなく、デフォルトではレプリケートされません。これは、これらの 2 つの環境でアクセス権が異なる必要があるためです。そのため、パブリッシュではオーサーとは別に ACL を設定することが推奨されます。

本作品は Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License によってライセンス許可を受けています。  Twitter™ および Facebook の投稿には、Creative Commons の規約内容は適用されません。

法律上の注意   |   プライバシーポリシー