使用者管理的索引複製

使用者管理的索引複製將領導者索引的完整副本分發到一個或多個追隨者副本。領導者繼續管理對索引的更新。所有查詢都由追隨者處理。這種分工使 Solr 能夠擴展，以針對大量搜尋量提供足夠的查詢回應能力。

下圖顯示使用索引複製的 Solr 設定。領導者伺服器的索引會在追隨者上複製。

user managed replication
圖 1. Solr 索引可以跨多個追隨者伺服器複製，然後由這些伺服器處理請求。

Solr 中的索引複製

Solr 包含透過 HTTP 運作的索引複製功能

  • 影響複製的設定由單一檔案 solrconfig.xml 控制。

  • 支援複製設定檔以及索引檔。

  • 在具有相同設定的平台上運作。

  • 不依賴於作業系統相關的檔案系統功能（例如，硬連結）。

  • 與 Solr 緊密整合；管理頁面提供對複製各個方面的精細控制。

  • 基於 Java 的複製功能實作為請求處理器。因此，設定複製類似於任何正常的請求處理器。

SolrCloud 中的複製

儘管在 SolrCloud 叢集中沒有明確的領導者或追隨者節點概念，但此頁面討論的 ReplicationHandler 仍然由 SolrCloud 根據需要使用，以支援「分片復原」 – 但這是以對等方式完成的。

使用 SolrCloud 時，ReplicationHandler 必須透過 /replication 路徑提供。Solr 會隱式執行此操作，除非在您的 solrconfig.xml 中明確覆寫。如果您希望覆寫預設行為，請務必不要設定下面提到的任何「領導者」或「追隨者」設定選項，否則它們會干擾正常的 SolrCloud 運作。

設定 ReplicationHandler

除了下面描述的特定於領導者和追隨者角色的 ReplicationHandler 設定選項之外，還有一些通常支援的特殊設定選項（即使在使用 SolrCloud 時）。

  • maxNumberOfBackups 一個整數值，指示此節點在接收 backup 命令時將在磁碟上保留的最大備份數量。

  • 與 Solr 中的大多數其他請求處理器類似，您可以設定一組 defaults, invariants, and/or appends 參數，這些參數對應於 ReplicationHandler 在 處理命令 時支援的任何請求參數。

設定領導者伺服器

在執行複製之前，您應該在處理器的初始化時設定以下參數

replicateAfter

選用

預設值：無

字串，指定應在執行哪個動作後進行複製。有效值為

  • commit：每當在領導者索引上執行提交時，觸發複製。

  • optimize：每當領導者索引最佳化時，觸發複製。

  • startup：每當領導者索引啟動時，觸發複製。

此參數可以有多個值，如下所示

+

<str name="replicateAfter">startup</str>
<str name="replicateAfter">commit</str>
<str name="replicateAfter">optimize</str>

+ 如果您使用 startup，您也應該有一個 commit 和/或 optimize 條目，以便在未來提交或最佳化時觸發複製。

backupAfter

選用

預設值：無

字串，指定應在執行哪個動作後進行備份。有效值為 commit、optimize 或 startup。此參數可以有多個值。它不是複製所必需的，它只是建立備份。

maxNumberOfBackups

選用

預設值：無

整數，指定要保留的備份數量。這可用於刪除除最近的 N 個備份之外的所有備份。

confFiles

選用

預設值：無

要複製到追隨者的設定檔，以逗號分隔。這些應該是諸如架構、停用字詞和類似的設定檔，這些檔案可能會在領導者上變更，並且需要在追隨者上更新，以便在提供查詢時使用。

如果應該複製 solrconfig.xml，則需要特別注意，以確保領導者的設定不會覆蓋追隨者的設定。像下面這樣的行將確保本機設定 solrconfig_follower.xml 將作為 solrconfig.xml 保存在追隨者上

<str name="confFiles">solrconfig_follower.xml:solrconfig.xml,managed-schema.xml,stopwords.txt</str>

在領導者伺服器上，追隨者設定檔的檔案名稱可以是任何名稱，只要該名稱在 confFiles 字串中正確識別即可；然後它將以冒號 ':' 後面的任何檔案名稱保存。在上面的範例中，所有其他檔案都將以其原始名稱保存。

commitReserveDuration

選用

預設值：00:00:10

如果您的提交非常頻繁且網路速度較慢，您可以調整此參數以增加預期傳輸資料所需的時間。預設值為 00:00:10，即 10 秒。

下面的範例顯示了 ReplicationHandler 的可能「領導者」設定，包括固定數量的備份和 maxWriteMBPerSec 請求參數的不變設定，以防止追隨者飽和其網路介面

<requestHandler name="/replication" class="solr.ReplicationHandler">
  <lst name="leader">
    <str name="replicateAfter">optimize</str>
    <str name="backupAfter">optimize</str>
    <str name="confFiles">schema.xml,stopwords.txt,elevate.xml</str>
  </lst>
  <int name="maxNumberOfBackups">2</int>
  <str name="commitReserveDuration">00:00:10</str>
  <lst name="invariants">
    <str name="maxWriteMBPerSec">16</str>
  </lst>
</requestHandler>

設定追隨者伺服器

追隨者設定需要與領導者不同，因為在此方法中，追隨者會啟動向領導者請求更新索引和其他檔案的要求。

我們使用以下參數

leaderUrl

選用

預設值：無

領導者的複製處理器的完整 URL。

必須定義此參數，以便從領導者擷取新的索引和設定檔，但它不需要在 solrconfig.xml 中定義。它可以作為 fetchindex 命令的請求參數傳遞。

pollInterval

選用

預設值：無

追隨者應輪詢領導者的間隔。格式為 HH:mm:ss。如果此參數不存在，則追隨者不會自動輪詢。

如果未設定，則可以從管理 UI 或 HTTP API 觸發 fetchindex。

compression

選用

預設值：無

在傳輸索引檔案時啟用壓縮。可能的值為 internal 或 external。如果值為 external，請確保您的領導者 Solr 具有接受 Accept-Encoding 標頭的設定。如果將其設定為 internal，則所有內容都會自動處理。

雖然此參數對於一般使用似乎是個好主意，但通常只有在領導者和追隨者節點之間的頻寬持續偏低時才需要。

httpConnTimeout

選用

預設值：5000

等待連線到領導者的時間（以毫秒為單位）。除非頻寬極低或延遲極高，否則通常可以將其保留為預設值。

httpReadTimeout

選用

預設值：10000

等待讀取索引檔案的時間（以毫秒為單位）。與 httpConnTimeout 類似，除非頻寬極低或延遲極高，否則通常可以將其保留為預設值。

httpBasicAuthUser

選用

預設值：無

如果領導者已設定 HTTP 基本身分驗證，則要使用的使用者名稱。

httpBasicAuthPassword

選用

預設值：無

如果領導者已設定 HTTP 基本身分驗證，則要使用的密碼。

以下範例顯示了追隨者上的 ReplicationHandler 設定

<requestHandler name="/replication" class="solr.ReplicationHandler">
  <lst name="follower">
    <str name="leaderUrl">http://remote_host:port/solr/core_name/replication</str>
    <str name="pollInterval">00:00:20</str>

    <!-- THE FOLLOWING PARAMETERS ARE USUALLY NOT REQUIRED-->
    <str name="compression">internal</str>
    <str name="httpConnTimeout">5000</str>
    <str name="httpReadTimeout">10000</str>
    <str name="httpBasicAuthUser">username</str>
    <str name="httpBasicAuthPassword">password</str>
  </lst>
</requestHandler>

使用 ReplicationHandler 設定轉發器

領導者可能只能為一定數量的追隨者提供服務，而不會影響效能。有些組織已在多個資料中心部署追隨者伺服器。如果每個追隨者都從遠端資料中心下載索引，則產生的下載可能會消耗過多的網路頻寬。為了避免這種情況下的效能下降，您可以將一個或多個追隨者設定為轉發器。轉發器只是一個同時充當領導者和追隨者的節點。

若要將伺服器設定為轉發器，則 solrconfig.xml 檔案中複製 requestHandler 的定義必須包含領導者和追隨者都使用的檔案清單。

請務必將 replicateAfter 參數設定為 commit，即使 replicateAfter 在主要領導者上設定為 optimize 也一樣。這是因為在轉發器（或任何追隨者）上，提交只會在下載索引後呼叫。最佳化命令永遠不會在追隨者上呼叫。

或者，可以透過 compression 參數設定轉發器以從領導者擷取壓縮檔案，以減少索引下載時間。

以下是轉發器的 ReplicationHandler 設定範例

<requestHandler name="/replication" class="solr.ReplicationHandler">
  <lst name="leader">
    <str name="replicateAfter">commit</str>
    <str name="confFiles">schema.xml,stopwords.txt,synonyms.txt</str>
  </lst>
  <lst name="follower">
    <str name="leaderUrl">http://leader.solr.company.com:8983/solr/core_name/replication</str>
    <str name="pollInterval">00:00:60</str>
  </lst>
</requestHandler>

複製畫面

複製畫面會顯示您指定的索引核心目前的複製狀態。

只有當您未在 SolrCloud 模式下執行 Solr 時，才會顯示此畫面。

如果您正在使用領導者-追隨者索引複製，則可以使用此畫面執行下列操作

  1. 檢視可複製的索引狀態（在領導者節點上）

  2. 檢視目前的複製狀態（在追隨者節點上）

  3. 停用複製（在領導者節點上）

image

追隨者複製

領導者完全不知道追隨者。

追隨者會持續輪詢領導者（取決於 pollInterval 參數），以檢查領導者的目前索引版本。如果追隨者發現領導者具有較新版本的索引，則會啟動複製程序。

步驟如下

  • 追隨者會發出 filelist 命令以取得檔案清單。此命令會傳回檔案的名稱以及一些中繼資料（例如，大小、上次修改時間戳記、別名等）。

  • 追隨者會檢查本機索引中是否有這些檔案。然後，它會執行 filecontent 命令以下載遺失的檔案。這會使用自訂格式（類似於 HTTP 分塊編碼）來下載完整內容或每個檔案的一部分。如果連線在中間中斷，則下載會從失敗點繼續。在任何時間點，追隨者都會嘗試 5 次，然後才會完全放棄複製。

  • 檔案會下載到臨時目錄，因此如果在下載過程中追隨者或領導者當機，則不會損壞任何檔案。相反地，目前的複製會簡單地中止。

  • 下載完成後，新檔案會移至即時索引目錄，而檔案的時間戳記與領導者上的對應檔案相同。

  • 追隨者的 ReplicationHandler 會在追隨者上發出提交命令，並載入新的索引。

複製設定檔

若要複製設定檔，請使用 confFiles 參數定義它們。只會複製領導者 Solr 執行個體 conf 目錄中找到的檔案。

只有在複製索引本身時，Solr 才會複製設定檔。這表示即使設定檔在領導者上變更，也只有在領導者的索引上執行新的提交或最佳化之後，才會複製該檔案。

與索引檔案不同，索引檔案的時間戳記足以判斷它們是否相同，設定檔會根據其總和檢查碼進行比較。如果架構檔（在領導者和追隨者上）的總和檢查碼相同，則會判斷它們相同。

在複製設定檔時，為了預防起見，Solr 會先將設定檔複製到臨時目錄，然後再將它們移至 conf 目錄中的最終位置。然後，舊的設定檔會重新命名並保留在相同的 conf/ 目錄中。ReplicationHandler 不會自動清除這些舊檔案。

如果複製涉及下載至少一個設定檔，則 ReplicationHandler 會發出核心重新載入命令，而不是提交命令。

解決追隨者伺服器上的損毀問題

如果將文件新增至追隨者，則追隨者不再與其領導者同步。但是，追隨者不會採取任何動作來使其自身同步，直到領導者具有新的索引資料為止。

當在領導者上執行提交操作時，領導者的索引版本會與追隨者的索引版本不同。然後，追隨者會擷取檔案清單，並發現領導者上存在的某些檔案也存在於本機索引中，但大小和時間戳記不同。這表示領導者和追隨者的索引不相容。

為了更正此問題，追隨者會將所有索引檔案從領導者複製到新的索引目錄，並要求核心從新的目錄載入新的索引。

ReplicationHandler 的 HTTP API 命令

您可以使用以下 HTTP 命令來控制 ReplicationHandler 的操作。

enablereplication

為所有追隨者在「領導者」上啟用複製。

http://_leader_host:port_/solr/_core_name_/replication?command=enablereplication
disablereplication

為所有追隨者在領導者上停用複製。

http://_leader_host:port_/solr/_core_name_/replication?command=disablereplication
indexversion

傳回指定領導者或追隨者上最新可複製索引的版本。

V1 API

http://_host:port_/solr/_core_name_/replication?command=indexversion

V2 API

http://_host:port_/api/cores/_core_name_/replication/indexversion
fetchindex

強制指定的追隨者從其領導者擷取索引的副本。

http://_follower_host:port_/solr/_core_name_/replication?command=fetchindex

您可以傳遞額外的屬性，例如 leaderUrl 或 compression（或 設定追隨者伺服器 中描述的任何其他參數），以執行從領導者進行一次性複製。這消除了在追隨者設定中硬式編碼領導者 URL 的需要。

abortfetch

中止將索引從領導者複製到指定的追隨者。

http://_follower_host:port_/solr/_core_name_/replication?command=abortfetch
enablepoll

允許指定的追隨者輪詢領導者上的變更。

http://_follower_host:port_/solr/_core_name_/replication?command=enablepoll
disablepoll

禁止指定的追隨者輪詢領導者上的變更。

http://_follower_host:port_/solr/_core_name_/replication?command=disablepoll
details

擷取設定詳細資料和目前狀態。

http://_follower_host:port_/solr/_core_name_/replication?command=details
filelist

擷取指定主機索引中存在的 Lucene 檔案清單。

V1 API

http://_host:port_/solr/_core_name_/replication?command=filelist&generation=<_generation-number_>

V2 API

http://_host:port_/api/cores/_core_name_/replication/files?generation=<_generation-number_>

您可以使用 indexversion 命令來查詢索引的產生編號。

備份

如果伺服器中有已提交的索引資料，則在領導者節點上建立備份；否則不執行任何動作。

http://_leader_host:port_/solr/_core_name_/replication?command=backup

此命令對於定期備份很有用。它支援多個請求參數。

numberToKeep

除非在處理程序上指定了 maxNumberOfBackups 初始化參數，否則此參數可以與 backup 命令一起使用。在指定 maxNumberOfBackups 的情況下，將始終使用 maxNumberOfBackups，並且嘗試使用 numberToKeep 請求參數將導致錯誤。

name

（可選）備份名稱。快照將在核心的資料目錄中的 snapshot.<name> 目錄下建立。預設情況下，名稱將使用 yyyyMMddHHmmssSSS 格式的日期產生。如果傳遞了 location 參數，則將使用該參數而不是資料目錄。

repository

要使用的備份儲存庫的名稱。如果未指定，則預設為本地檔案系統。

location

備份位置。該值取決於使用的儲存庫。對於檔案系統儲存庫，位置預設為核心的 dataDir (資料目錄)，如果指定了位置，則該位置必須位於 SOLR_HOME、SOLR_DATA_HOME 或由 solr.xml 的 allowPaths 參數指定的路徑內。

restore

從備份儲存庫還原備份。

http://_leader_host:port_/solr/_core_name_/replication?command=restore

此命令用於還原備份。它支援多個請求參數。

name

（可選）備份名稱。要還原的備份索引快照的名稱。如果未提供名稱，它將在位置目錄中尋找具有 snapshot.<timestamp> 格式的備份。在這種情況下，它會選擇最新的時間戳記備份。

repository

備份所在的備份儲存庫的名稱。如果未指定，則預設為本地檔案系統。

location

備份位置。該值取決於使用的儲存庫。對於檔案系統儲存庫，位置預設為核心的 dataDir（資料目錄），如果指定了位置，則該位置必須位於 SOLR_HOME、SOLR_DATA_HOME 或由 solr.xml 的 allowPaths 參數指定的路徑內。

restorestatus

檢查正在執行的還原操作的狀態。

http://_leader_host:port_/solr/_core_name_/replication?command=restorestatus

此命令用於檢查還原操作的狀態。此命令不接受任何參數。

狀態值可以是「In Progress」、「success」或「failed」。如果失敗，則回應中也會傳送「exception」。

deletebackup

刪除使用 backup 命令建立的任何備份。

http://_leader_host:port_ /solr/_core_name_/replication?command=deletebackup

它支援兩個參數

name

快照的名稱。必須存在名稱為 snapshot.name 的快照，否則將傳回錯誤。

location

建立快照的位置。

最佳化分散式索引

最佳化索引通常不是大多數使用者應該擔心的問題 - 但特別是，使用者應該注意在使用 ReplicationHandler 時最佳化索引的影響。

最佳化領導者索引所需的時間可能會差異很大。小型索引可能會在幾分鐘內完成最佳化。非常大的索引可能需要數小時。變數包括索引的大小和硬體的速度。

分散新最佳化的索引可能只需幾分鐘，也可能需要一個小時或更長時間，同樣取決於索引的大小以及網路連線和磁碟的效能。在最佳化期間，機器處於負載狀態，並且無法很好地處理查詢。如果每小時對追隨者執行幾次更新排程，我們無法對每個提交的快照執行最佳化。

複製最佳化的索引意味著在下一次 snappull 期間需要傳輸 **整個** 索引。這是一項很大的開銷，但遠不及在每個地方執行最佳化那麼大。

考慮這個範例：在一個三追隨者一領導者的配置中，分散新最佳化的索引總共大約需要 80 秒。在層級之間滾動變更將需要每台機器（或機器群組）大約十分鐘。如果此最佳化在查詢層級中滾動，並且每個正在最佳化的追隨者節點都被停用且未接收查詢，則滾動將至少需要 20 分鐘，並且可能長達一個半小時。此外，檔案需要同步，以便在最佳化之後，snappull 不會認為獨立最佳化的檔案有任何不同。這也可能導致索引的獨立損毀，而不是每個都是領導者的完美副本。

在領導者節點上進行最佳化允許進行直接的最佳化操作。無需讓任何查詢追隨者停止服務。最佳化的索引可以在背景中分散，同時正常處理查詢。最佳化可以在方便提供索引更新的應用程式的任何時間發生。

雖然最佳化在某些情況下可能有一些好處，但快速變更的索引不會長時間保留這些好處，並且由於最佳化是一個密集過程，因此最好考慮其他選項，例如降低合併因子（在控制段大小部分討論）。

除非您有切實的證據表明最佳化將顯著提高您的搜尋效能，否則請勿選擇最佳化您的索引。