レプリケーションのトラブルシューティング

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

問題

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

解決方法

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

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

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

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

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

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

  1. キューに​blocked​ステータスが表示されますか。その場合、パブリッシュインスタンスは実行されていないか、完全に応答しないか。パブリッシュインスタンスを調べて、問題を調べます（例：ログを確認し、OutOfMemoryエラーまたはその他の問題があるかどうかを確認します）。通常は遅い場合は、スレッドダンプを取り、それらを分析します。

  2. キューのステータスに「Queue is active - # pending」と表示されますか。基本的に、レプリケーションジョブは、パブリッシュインスタンスまたはDispatcherが応答するのを待つソケット読み取りで停止する可能性があります。これは、パブリッシュインスタンスまたはDispatcherが高負荷になっているか、ロック状態になっている可能性があります。この場合、オーサーとパブリッシュからスレッドダンプを取得します。

    • スレッドダンプアナライザーでオーサーのスレッドダンプを開き、レプリケーションエージェントの sling イベントジョブが socketRead で動かなくなっていないかを確認します。
    • スレッドダンプアナライザーで発行のスレッドダンプを開き、発行インスタンスが応答しない原因を分析します。名前にPOST/bin/receiveを持つスレッド（作成者からレプリケーションを受け取るスレッド）が表示されます。

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

  1. リポジトリの破損やその他の問題が原因で、特定のコンテンツを/var/replication/dataの下にシリアル化できない可能性があります。logs/error.logで関連するエラーを確認します。不正なレプリケーション項目を消去するには、次の操作を行います。

    1. https://<host>:<port>/crxに移動し、管理者ユーザーとしてログインします。 CQ5.5で、代わりにhttps://<host>:<port>/crx/explorerに移動します。
    2. 「Content Explorer」をクリックします。
    3. Content Explorer ウィンドウの右上にある虫眼鏡ボタンをクリックすると、検索ダイアログがポップアップします。
    4. 「XPath」ラジオボタンを選択します。
    5. 「Query」ボックスに、@slingevent:createdの順序で/jcr:root/var/eventing/jobs//element(&ast;,slingevent:Job)を入力します。
    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コンソールの設定ページに移動し、「Apache Sling Job Event Handler」設定を削除する必要があります。次に、クラスターのマスターノードを再起動して、構成を一貫性のある状態に戻します。これにより問題が解決し、レプリケーションが再び機能し始めます。

replication.log の作成

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

  1. https://host:port/system/console/configMgrに移動し、管理者としてログインします。

  2. Apache Sling Logging Loggerファクトリを探し、ファクトリ設定の右側にある​+​ボタンをクリックしてインスタンスを作成します。これにより、新しいログロガーが作成されます。

  3. 次のように設定します。

    • ログレベル：デバッグ
    • ログファイルのパス：（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 を設定することが推奨されます。

オーサーからパブリッシュに名前空間情報をレプリケーションするときにレプリケーションキューがブロックされました

場合によっては、オーサーインスタンスからパブリッシュインスタンスに名前空間情報をレプリケーションしようとすると、レプリケーションキューがブロックされます。これは、レプリケーションユーザーにjcr:namespaceManagement権限がないために発生します。 この問題を回避するには、次のことを確認してください。

  • レプリケーションユーザー（「トランスポート」タブの「ユーザー」で設定）もパブリッシュインスタンスに存在します。
  • ユーザーは、コンテンツがインストールされているパスで読み取りおよび書き込み権限を持っています。
  • ユーザーは、リポジトリレベルでjcr:namespaceManagement権限を持っています。 次のようにして権限を付与できます。
  1. CRX/DE(http://localhost:4502/crx/de/index.jsp)に管理者としてログインします。
  2. 「アクセス制御」タブをクリックします。
  3. 「リポジトリ」を選択します。
  4. 「エントリを追加」（プラスアイコン）をクリックします。
  5. ユーザーの名前を入力します。
  6. 権限リストからjcr:namespaceManagementを選択します。
  7. 「OK」をクリックします。

このページ