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

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

問題

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

解像度

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

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

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

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

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

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

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

  2. キューのステータスに「キューはアクティブです — #保留中」と表示されますか。基本的に、レプリケーションジョブは、発行インスタンスまたはディスパッチャーが応答するのを待つ読み取りソケットで停止する可能性があります。これは、発行インスタンスまたはディスパッチャーが高い読み込み下にあるか、ロック状態にあることを意味する可能性があります。この場合、作成者からスレッドダンプを取得し、発行します。

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

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

  1. リポジトリの破損やその他の問題が原因で、/var/replication/dataの下で特定のコンテンツ部分をシリアライズできない可能性があります。logs/error.logを参照して、関連するエラーがないか確認します。不正なレプリケーションアイテムを消去するには、次の手順を実行します。

    1. https://<host>:<port>/crxに移動し、管理者ユーザーとしてログインします。 CQ5.5では、代わりにhttps://<ホスト>:<ポート>/crx/explorerに移動します。
    2. 「Content Explorer」をクリックします。
    3. Content Explorer ウィンドウの右上にある虫眼鏡ボタンをクリックすると、検索ダイアログがポップアップします。
    4. 「XPath」ラジオボタンを選択します。
    5. 「クエリ」ボックスに、@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ジョブイベントハンドラ」の設定を削除する必要があります。次に、クラスターのマスターノードを再起動して、設定を一貫した状態に戻します。この問題は修正され、レプリケーションは再び機能します。

replication.log の作成

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

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

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

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

    • ログレベル：DEBUG
    • Log File Path:（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権限がないためです。 この問題を回避するには、次のことを確認してください。

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

このページ