レプリケーションのトラブルシューティング troubleshooting-replication
このページでは、レプリケーションに関する問題のトラブルシューティング方法について説明します。
問題 problem
レプリケーション（順方向のレプリケーション）が何らかの原因で失敗する
解決方法 resolution
レプリケーションが失敗するのには様々な原因があります。 ここでは、これらの問題を分析する際に採用できるアプローチについて説明します。
「アクティベート」ボタンをクリックすると、レプリケーションがトリガーされますか？ トリガーされない場合は、次の操作を行います。
- /crx/de/index.jspに移動し、管理者としてログインします。
- ノード /bin/replicate または /bin/replicate.json が存在するかを確認します。 ノードが存在する場合は、削除して保存します。
レプリケーションがレプリケーションエージェントのキュー内で待機している状態ですか？
確認するには、/etc/replication/agents.author.html に移動し、レプリケーションエージェントをクリックします。
1 つまたは複数のエージェントキューが停止している場合：
-
キューのステータスには「blocked」と示されていますか？ その場合、パブリッシュインスタンスが実行していないか、完全に応答しない状態になっていますか？ パブリッシュインスタンスを確認し、何が問題かを調査します。 例えば、ログをチェックして、OutOfMemory エラーなどの問題が発生していないかを確認します。 単に一般的な遅延が発生している場合は、スレッドダンプを取得して分析します。
-
キューのステータスは「Queue is active - # pending」と示されていますか？ 基本的に、レプリケーションジョブはソケット読み取りにおいて、パブリッシュインスタンスまたは Dispatcher の応答待ちで停止する可能性があります。 この場合、パブリッシュインスタンスまたは Dispatcher が高負荷の状態か、ロックによって停止状態になる可能性があります。 そのような場合は、オーサーまたはパブリッシュでスレッドダンプを取得します。
- スレッドダンプアナライザーでオーサーのスレッドダンプを開き、レプリケーションエージェントの sling イベントジョブが socketRead で停止していないかを確認します。
- スレッドダンプアナライザーでパブリッシュのスレッドダンプを開き、パブリッシュインスタンスが応答しない原因を分析します。 オーサーからレプリケーションを受信するスレッドである POST /bin/receive という名前のスレッドを確認します。
すべてのエージェントキューが停止している場合
-
リポジトリの破損やその他の問題により、特定のコンテンツを/var/replication/dataでシリアル化できない可能性があります。 関連するエラーについては、logs/error.logを参照してください。 無効なレプリケーション項目をクリアするには、次の操作を行います。
- https:// : /crx/de にアクセスし、管理者ユーザーでログインします。
- トップメニューから「ツール」をクリックします。
- 虫眼鏡ボタンをクリックします。
- 種類として「XPath」を選択します。
- 「クエリ」ボックスに、@slingevent:createdによる/jcr:root/var/eventing/jobs//element （*,slingevent:Job）の順序を入力します
- 「検索」をクリックします。
- 検索結果の上位の項目が、最新の Sling イベントジョブです。 各ジョブをクリックして、キューの一番上に表示されるものと同じ、動きのないレプリケーションを見つけます。
replication.log の作成
すべてのレプリケーションログを、個別のログファイルに DEBUG レベルで追加するように設定すると役に立つことがあります。 次の手順を実行します。
-
https://host:port/system/console/configMgrに移動し、管理者としてログインします。
-
Apache Sling Logging Logger Configurationを見つけ、ファクトリ設定の右側にある「+」ボタンをクリックしてインスタンスを作成します。 新しいログロガーが作成されます。
-
次のように設定します。
- ログレベル：DEBUG
- ログファイル：logs/replication.log
- ロガー：com.day.cq.replication
-
何らかの形でsling イベント/ジョブに関連する問題であると疑われる場合は、このJava™ パッケージをcategories:org.apache.sling.eventに追加することもできます
レプリケーションエージェントキューの一時停止 pausing-replication-agent-queue
オーサーシステムの負荷を軽減するために、レプリケーションキューを無効にせずに一時停止することが適している場合があります。 現在、これを行う唯一の方法は、無効なポートを一時的に設定することです。 5.4 以降は、レプリケーションエージェントキューに一時停止ボタンが表示されますが、一部の制限があります。
- 状態が永続化されません。そのため、サーバーまたはレプリケーションバンドルを再起動すると、実行中の状態に戻ります。
- 一時停止は短い期間（他のスレッドによるレプリケーションを含むアクティビティがなくなってから 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権限を持っています。 次のようにして権限を付与できます。
- CRX/DE（
https://localhost:4502/crx/de/index.jsp）に管理者としてログインします。 - 「アクセス制御」タブをクリックします。
- 「リポジトリ」を選択します。
- 「エントリを追加」（プラスアイコン）をクリックします。
- ユーザーの名前を入力します。
- 権限リストから
jcr:namespaceManagementを選択します。 - 「OK」をクリックします。