ドキュメントAEM 6.5ユーザーガイド

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

最終更新日： 2026年6月9日
  • 適用対象：
  • Experience Manager 6.5

作成対象：

  • Admin

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

問題 problem

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

解決方法 resolution

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

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

  1. /crx/explorerに移動し、adminとしてログインします。
  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/deに移動し、管理者ユーザーとしてログインします。
    2. トップメニューから「ツール」をクリックします。
    3. 虫眼鏡ボタンをクリックします。
    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 を確認します。 「ジョブ処理有効」チェックボックスのチェックを外すことができます。 これがチェックされ、それでも「ジョブ処理が無効になっています」と表示される場合は、ジョブ処理を無効にしている/apps/system/configの下にオーバーレイがあるかどうかを確認します。 ブール値trueのjobmanager.enabledにosgi:config ノードを作成し、アクティブ化が開始され、キューにジョブが追加されていないかどうかを再確認してください。

  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. 次のように設定します。

    • ログレベル：DEBUG
    • ログ ファイルのパス：logs/replication.log
    • カテゴリ：com.day.cq.replication

  4. 何らかの形でsling イベント/ジョブに関連する問題であると疑われる場合は、このJava; パッケージをcategories:org.apache.sling.eventの下に追加することもできます。

レプリケーションエージェントキューの一時停止 pausing-replication-agent-queue

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

  1. 状態は保持されません。 つまり、サーバーを再起動するか、レプリケーションバンドルがリサイクルされると、実行状態に戻ります。
  2. 一時停止は、短い期間（他のスレッドによるレプリケーションを伴うアクティビティがない場合は1時間）アイドル状態になります。 これは、Slingにアイドルスレッドを回避する機能があるためです。 ジョブキュースレッドが長い間使用されていないかどうかを確認します。 そうすると、クリーンアップサイクルが開始されます。 クリーンアップサイクルにより、スレッドが停止し、一時停止した設定が失われます。 ジョブは永続化されるので、キューを処理するために新しいスレッドが開始されます。このスレッドには、一時停止された設定の詳細はありません。 これにより、キューは実行中の状態になります。

ユーザーのアクティベート時にページ権限がレプリケートされない page-permissions-are-not-replicated-on-user-activation

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

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

オーサーからパブリッシュに名前空間情報をレプリケーションするときにレプリケーションキューがブロックされました replication-queue-blocked-when-replicating-namespace-information-from-author-to-publish

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

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