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

このページでは、レプリケーションの問題のトラブルシューティング方法に関する情報を提供します。

問題 problem

何らかの理由で、レプリケーション(非リバースレプリケーション)が失敗している。

解決方法 resolution

レプリケーションが失敗する理由は様々です。 この記事では、これらの問題を分析する際に取る可能性のあるアプローチについて説明します。

「アクティブ化」ボタンをクリックしたときに、レプリケーションがトリガーされますか。 そうでない場合は、次の操作を行います。

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

レプリケーションはレプリケーションエージェントキューでキューに入っていますか。

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

1 つまたは複数のエージェントキューが停止している場合:

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

  2. キューのステータスが表示されますか。 キューはアクティブ — 保留中数です? 基本的に、レプリケーションジョブは、パブリッシュインスタンスまたは 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. 「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. ジョブの処理がオフになっている可能性があります。 Sling Eventing Tab の Felix Console で確認できます。 「Apache Sling Eventing (JOB PROCESSING が無効になっています。)」と表示されるかどうかを確認します。

    • 有効な場合は、Felix コンソールの「Configuration」タブで「Apache Sling Job Event Handler」をオンにします。 [ ジョブ処理が有効 ] チェックボックスがオフになっている可能性があります。 このオプションをオンにしても「ジョブ処理が無効です」と表示される場合は、ジョブ処理を無効にするオーバーレイが/apps/system/config の下に存在するかどうかを確認します。 boolean 値を true に設定して jobmanager.enabled の osgi:config ノードを作成し、アクティベーションが開始したかどうか、およびキューにジョブがなくなったかどうかを再確認します。
  4. また、DefaultJobManager 構成に一貫性のない状態が発生する場合もあります。 この問題は、ユーザーが OSGiconsole で「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 にアクセスし、Admin でログインします。

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

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

    • ログレベル:DEBUG
    • ログファイルのパス:logs/replication.log
    • カテゴリ:com.day.cq.replication
  4. 問題が何らかの形で sling eventing/jobs に関連していると思われる場合は、この Java™パッケージを categories(org.apache.sling.event) に追加することもできます。

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

オーサーシステムの負荷を減らすために、無効にせずにレプリケーションキューを一時停止するのが適している場合があります。 現在、これは、無効なポートを一時的に設定するハッキングによってのみ可能です。 5.4 以降では、レプリケーションエージェントキューに一時停止ボタンが表示されるようになりましたが、いくつかの制限があります

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

ユーザーアクティベーションでページ権限がレプリケートされません page-permissions-are-not-replicated-on-user-activation

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

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

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

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

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