疑難排解復寫

本頁面提供如何疑難排解復寫問題的資訊。

問題

復寫（非反向復寫）因某些原因而失敗。

解析度

複製失敗有多種原因。 本文說明分析這些問題時可能採取的方法。

按一下「激活」按鈕時，複製是否完全觸發？若非，則執行下列動作：

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

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

請前往/etc/replication/agents.author，然後按一下復寫代理以檢查，以檢查此項目。

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

  1. 隊列是否顯示​blocked​狀態？ 如果是，則發佈執行個體是否未執行或完全停止回應？ 檢查發佈執行個體以查看其有何錯誤（亦即檢查記錄，並查看是否有OutOfMemory錯誤或其他問題）。 如果速度通常很慢，請提取線程轉儲並分析它們。

  2. 隊列狀態是否顯示​隊列處於活動狀態 — # pending? 基本上，復寫工作可能卡在通訊端讀取中，等待發佈執行個體或調度程式回應。 這可能表示發佈執行個體或調度程式負載高或卡在鎖中。 從作者取用執行緒轉儲，並在此情況下發佈。

    • 在執行緒傾印分析器中，從作者開啟執行緒傾印，檢查是否顯示復寫代理的sling事件工作卡在socketRead中。
    • 在執行緒傾印分析器中從發佈開啟執行緒傾印，分析可能導致發佈執行個體未回應的原因。 您應該會看到名稱中包含/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. 可能是作業處理完全關閉。 您可以在Sling事件標籤的Felix Console底下查看。 檢查是否顯示 — Apache Sling事件（已停用作業處理！）

    • 如果是，請在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」屬性顯示「已啟用作業處理」為已勾選狀態，當您導覽至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工廠，然後按一下工廠設定右側的​+​按鈕以建立執行個體。 這將建立新的記錄器。

  3. 以下列方式設定設定：

    • 記錄層級：除錯
    • 日誌檔案路徑：logs/replication.log
    • 類別：com.day.cq.replication

  4. 如果您懷疑問題與sling事件/工作有任何關係，您也可以在categories:org.apache.sling.event下新增此java套件

暫停複製代理隊列

有時候，暫停復寫佇列以減少製作系統的負載，而不停用它可能比較合適。 目前，只有通過臨時配置無效埠的駭客攻擊才能做到這一點。 從5.4開始，您可以在復寫代理佇列中看到暫停按鈕，但有一些限制

  1. 狀態不會持續，這表示如果重新啟動伺服器或復寫套件組合已循環，則會回復為執行狀態。
  2. 暫停的空閒時間較短（在沒有其他線程進行複製的活動後1小時，OOB），而不是更長的時間。 因為Sling中有可避免閒置執行緒的功能。 基本上，檢查作業隊列線程是否已被長時間未使用，如果這樣，它將啟動清理週期。 由於清理週期，它會停止線程，因此暫停的設定會丟失。 由於作業持續存在，它會啟動一個新線程來處理隊列，該隊列沒有暫停配置的詳細資訊。 由於此佇列會變成執行狀態。

用戶激活時不複製頁面權限

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

一般頁面權限不應從作者複製到發佈，且預設不會。 這是因為這兩個環境中的存取權限應該不同。 因此，建議您在發佈時與作者分開設定ACL。

將命名空間資訊從作者複製到發佈時，復寫佇列遭封鎖

在某些情況下，嘗試將命名空間資訊從製作例項複製到發佈例項時，復寫佇列會遭到封鎖。 發生此情況是因為複製用戶沒有jcr:namespaceManagement權限。 若要避免此問題，請確定：

  • 復寫使用者（如Transport標籤>User下所設定）也存在於發佈執行個體上。
  • 用戶在安裝內容的路徑上具有讀寫權限。
  • 用戶在儲存庫級別具有jcr:namespaceManagement權限。 您可以依照下列方式授予權限：
  1. 以管理員身分登入CRX/DE(https://localhost:4502/crx/de/index.jsp)。
  2. 按一下​Access Control​頁簽。
  3. 選擇​儲存庫。
  4. 按一下「新增項目」（加號圖示）。
  5. 輸入使用者名稱。
  6. 從權限清單中選擇jcr:namespaceManagement。
  7. 按一下「確定」。

本頁內容