複製故障排除

本頁提供了有關如何排除複製問題的資訊。

問題

複製(非反向複製)因某些原因而失敗。

解析度

複製失敗有各種原因。 本文就這些問題的分析作了說明。

按一下「激活」按鈕時,複製是否會觸發?如果為NOT,請執行下列動作:

  1. 前往/crx/explorer並以管理員身分登入。
  2. 開啟「內容總管」
  3. 查看節點/bin/replicate或/bin/replicate.json是否存在。 如果節點存在,請刪除它並保存。

複製是否在複製代理隊列中排隊?

請前往/etc/replication/agents.author.html,然後按一下複製代理以檢查,以檢查此項。

如果一個代理隊列或幾個代理隊列被卡住:

  1. 佇列是否顯示​blocked​狀態? 如果是,則發佈執行個體是否未執行或完全沒有回應? 檢查發佈實例以查看其中有什麼問題(例如,檢查日誌,並查看是否存在OutOfMemory錯誤或其他問題。 然後,如果執行緒轉儲通常很慢,請提取線程轉儲並分析它們。

  2. 隊列狀態是否顯示​隊列處於活動狀態- # pending? 基本上,復製作業可能會卡在套接字讀取中,等待pubilsh實例或調度程式作出響應。 這可能表示發佈實例或調度程式處於高負載狀態或卡在鎖中。 從作者處取出執行緒轉儲,並在此案例中發佈。

    • 線上程轉儲分析器中從author開啟線程轉儲,檢查它是否顯示複製代理的sling事件作業卡在套接字讀取中。
    • 線上程轉儲分析器中從發佈開啟線程轉儲,分析可能導致發佈實例不響應的原因。 您應該看到一個名稱中包含/bin/receivePOST的線程,即從作者處接收複製的線程。

如果所有代理隊列都被卡住

  1. 由於儲存庫損壞或某些其他問題,某段內容可能無法在/var/replication/data下序列化。 檢查logs/error.log中是否有相關錯誤。 要清除錯誤的複製項,請執行以下操作:

    1. 前往https://<host>:<port>/crx/de,並以管理員使用者身分登入。
    2. 按一下頂端選單中的「工具」。
    3. 按一下放大鏡按鈕。
    4. 選擇「XPath」作為「類型」。
    5. 在「查詢」方塊中,輸入@slingevent:created的查詢/jcr:root/var/eventing/jobs//element(*,slingevent:Job)順序
    6. 按一下「搜尋」
    7. 在結果中,排名最前的項目是最新的sling事件工作。 按一下每個複製,查找與隊列頂部顯示的副本匹配的停滯複製。
  2. sling事件架構工作佇列可能有問題。 嘗試在/system/console中重新啟動org.apache.sling.event套件。

  3. 可能是工作處理完全關閉。 您可以在Felix Console的Sling Eventing Tab下檢查此項目。 檢查是否顯示- Apache Sling Eventing(JOB PROCESSING IS DISABLED!)

    • 如果是,請在Felix Console的「設定」標籤下檢查Apache Sling Job Event Handler。 可能是未勾選「作業處理已啟用」核取方塊。 如果已勾選,但仍顯示「作業處理已停用」,則請檢查/apps/system/config下是否有任何覆蓋正在停用作業處理。 嘗試為jobmanager.enabled建立一個osgi:config節點,將布爾值設定為true,然後重新檢查啟動是否開始以及隊列中沒有更多作業。
  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主控台的「設定」頁面,並刪除「Apache Sling Job Event Handler」設定。 然後重新啟動群集的主節點,使配置恢復到一致狀態。 這應該會修正問題,複製將重新開始運作。

建立replication.log

有時,將所有複製記錄設定為在DEBUG級別的單獨日誌檔案中添加,會非常有用。 要執行此操作:

  1. 前往https://host:port/system/console/configMgr,以管理員身分登入。

  2. 尋找Apache Sling Logging Logger工廠,並按一下工廠設定右側的​+​按鈕建立例項。 This will create a new logging logger.

  3. 將配置設定為如下:

    • 記錄層級:除錯
    • 日誌檔案路徑:logs/replication.log
    • 類別:com.day.cq.replication
  4. 如果您懷疑問題與sling eventing/jobs有任何關聯,則您也可以將此java套件新增至categories:org.apache.sling.event

暫停複製代理隊列

有時,可以暫停複製隊列以減少作者系統上的負載,而不禁用它。 目前,只有通過臨時配置無效埠的攻擊才能做到這一點。 從5.4開始,您可以在複製代理隊列中看到暫停按鈕,它有一些限制

  1. 狀態不會持續存在,這表示如果重新啟動伺服器或複製捆綁包被循環使用,它將返回運行狀態。
  2. 暫停在較短的時間段(OOB在沒有其他線程複製的活動後1小時)內處於空閒狀態,而不是在較長的時間內。 因為吊具中有可避免閒置線程的功能。 基本上,檢查作業隊列線程是否已被使用較長時間,如果這樣,它將啟動清理週期。 由於清理週期,它會停止線程,因此暫停的設定將丟失。 由於作業是持續的,因此會啟動新線程來處理沒有暫停配置詳細資訊的隊列。 由於此隊列變為運行狀態。

使用者啟動時不會複製頁面權限

頁面權限不會複製,因為這些權限會儲存在授予存取權的節點下,而不是儲存在使用者下。

一般而言,頁面權限不應從作者複製以發佈,而且預設不會複製。 這是因為這兩種環境中的存取權限應該不同。 因此,建議在發佈時與作者分開配置ACL。

從「作者」複製命名空間資訊到「發佈」時,複製隊列被阻止

在某些情況下,當嘗試將命名空間資訊從作者實例複製到發佈實例時,複製隊列會被阻止。 這是因為複製用戶沒有jcr:namespaceManagement權限。 若要避免此問題,請確定:

  • 複製用戶(如Transport頁籤> User下配置)也存在於Publish實例中。
  • 用戶在安裝內容的路徑上具有讀寫權限。
  • 用戶在儲存庫級別具有jcr:namespaceManagement權限。 您可以按如下方式授予權限:
  1. 以管理員身份登錄到CRX/DE(https://localhost:4502/crx/de/index.jsp)。
  2. 按一下​Access Control​頁籤。
  3. 選擇​儲存庫
  4. 按一下「添加條目」(加號表徵圖)。
  5. 輸入用戶的名稱。
  6. 從權限清單中選擇jcr:namespaceManagement
  7. 按一下「確定」。

本頁內容

Adobe Summit Banner

A virtual event April 27-28.

Expand your skills and get inspired.

Register for free
Adobe Summit Banner

A virtual event April 27-28.

Expand your skills and get inspired.

Register for free
Adobe Maker Awards Banner

Time to shine!

Apply now for the 2021 Adobe Experience Maker Awards.

Apply now
Adobe Maker Awards Banner

Time to shine!

Apply now for the 2021 Adobe Experience Maker Awards.

Apply now