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

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

問題

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

解像度

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

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

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

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

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

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

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

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

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

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

  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」ボックスに、次のクエリを入力します。 /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. に移動します。 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」をクリックします。

このページ