CDCR的主要組成部分

CDCR架構(gòu)中有許多關鍵特性和組件：

CDCR配置

為了配置CDCR，源數(shù)據(jù)中心需要與目標數(shù)據(jù)中心關聯(lián)的ZooKeeper集群的主機地址。ZooKeeper主機地址是CDCR實例化與Target Solr集群通信所需的唯一信息。因此，源群集上solrconfig.xml文件的CDCR配置部分將包含一個ZooKeeper主機列表。solrconfig.xml的CDCR的配置部分還可能包含輔助/可選配置，例如CDC Replicator線程的數(shù)量，批量更新相關設置等。

CDCR初始化

CDCR支持對新的或現(xiàn)有的集合進行增量更新。CDCR可能無法跟上極高的volume更新，特別是在數(shù)據(jù)中心之間由于“pipe”緩慢而導致通信延遲嚴重的情況下。某些情況下：

• 有一個語料庫的初始批量加載，然后是較低的volume增量更新。在這種情況下，可以執(zhí)行初始批量加載，然后啟用CDCR。有關更多信息，請參閱初始啟動部分。
• 該索引從頭開始建立，沒有明顯的初始批量負荷。CDCR可以設置在空集合上，并從頭開始保持同步。
• 索引總是被更新的數(shù)量太高，CDCR無法不上。在源數(shù)據(jù)中心和目標數(shù)據(jù)中心之間的連接較差的情況下，這尤其有可能。這種情況不適用于目前的CDCR格式。

數(shù)據(jù)中心間通信

CDCR REST API是管理命令的最終用戶通信的主要形式。SolrJ客戶端在內(nèi)部用于CDCR操作。SolrJ客戶端從solrconfig.xml文件中獲取配置信息。CDCR的用戶不會直接與內(nèi)部的SolrJ實現(xiàn)進行交互，只會通過REST API與CDCR進行交互。

更新Tracking和Pushing

CDCR通過利用更新日志將數(shù)據(jù)更新從源復制到目標數(shù)據(jù)中心。

后臺線程定期檢查更新日志中的新條目，然后將其轉(zhuǎn)發(fā)到目標數(shù)據(jù)中心。因此，線程需要保持一個檢查點的形式，指向在更新日志中成功處理的最后一個更新。目標數(shù)據(jù)中心確認更新已成功處理后，更新日志指針將更新以反映當前檢查點。

此指針必須在所有副本之間同步。在leader失敗并選出新leader的情況下，新leader將能夠通過使用該同步指針從最后更新恢復復制。下面將解釋在副本之間同步這樣一個指針的策略。

如果由于某種原因，目標數(shù)據(jù)中心處于離線狀態(tài)或未能處理更新，則線程將定期嘗試聯(lián)系目標數(shù)據(jù)中心，并在緩存源群集上的更新時推送更新。其中一個含義是應該定期監(jiān)視源更新日志目錄，因為更新將繼續(xù)積累，直到與目標數(shù)據(jù)中心的連接恢復，amd才會被清除。

更新檢查點的同步

碎片引導程序和碎片副本之間更新檢查點的可靠同步對于避免引入源數(shù)據(jù)中心和目標數(shù)據(jù)中心之間的不一致至關重要。另一個重要的要求是必須以最小的網(wǎng)絡流量來執(zhí)行同步，以最大限度地提高可伸縮性。

為了實現(xiàn)這一目標，戰(zhàn)略是：

• 唯一標識每個更新操作。這個唯一的標識符將作為指針。
• 依賴于兩個存儲器：Source shard leader上的臨時存儲和目標集群上的持久存儲。

源集群中的分片頭將負責為每個更新操作生成唯一的標識符，并將最后一次處理的更新的標識符的副本保留在內(nèi)存中。標識符將作為更新請求的一部分發(fā)送到目標群集。在目標數(shù)據(jù)中心方面，分片頭將接收更新請求，并將其與更新日志中的唯一標識符一起存儲，并將其復制到其他碎片。

SolrCloud已經(jīng)為每個更新操作提供了一個唯一的標識符，即“版本號”。該版本號是使用基于時間的導入時鐘生成的，該時鐘對于每次發(fā)送的更新操作都是遞增的。這提供了更新操作的“發(fā)生之前”排序，這將在（1）源集群上的更新檢查點的初始化以及（2）更新日志的維護策略中利用。

目標群集上的持久性存儲僅在選擇源群集上的新分片頭時使用。如果一個碎片leader在源群集上向下移動并選出一個新的leader，新leader將聯(lián)系目標集群來檢索最后的更新檢查點并實例化其短暫指針。在這樣的請求中，目標集群將檢索在所有分片中收到的最新標識符，并將其發(fā)送回源集群。為了檢索最新的標識符，每個分片leader將在其更新日志中查找第一個條目的標識符并將其發(fā)送回協(xié)調(diào)器。協(xié)調(diào)器將不得不選擇其中最高的。

這種策略不需要任何額外的網(wǎng)絡流量，并確保了可靠的指針同步。一致性主要通過利用SolrCloud來實現(xiàn)。SolrCloud的更新工作流確保每一個更新都被應用到leader以及任何副本。如果leader不可用，就選一個新的leader。在leader選擇期間，將在新leader與其他副本之間執(zhí)行同步。這確保了新的leader與前l(fā)eader有一致的更新日志。擁有一致的更新日志意味著：

• 在源集群上，更新檢查點可以被新的leader重用。
• 在目標群集上，更新檢查點將在先前和新的leader之間保持一致。這確保了由新選出的leader從目標集群發(fā)送的更新檢查點的正確性。

維護更新日志

CDCR復制邏輯需要修改源數(shù)據(jù)中心上更新日志的維護邏輯。最初，“更新日志”用作固定大小的隊列，默認限制為100個更新條目。在CDCR方案中，更新日志必須充當可變大小的隊列，因為它們需要跟蹤目標數(shù)據(jù)中心的最后一次處理更新來跟蹤所有更新。更新日志中的條目只有在所有指針（每個目標數(shù)據(jù)中心一個指針）位于其后面時才會被刪除。

如果與其中一個目標數(shù)據(jù)中心的通信速度較慢，則源數(shù)據(jù)中心上的更新日志可能會增長到相當大的規(guī)模。在這種情況下，更新日志必須能夠根據(jù)其標識符有效地找到給定的更新操作。鑒于其標識符是一個增量編號，有可能實現(xiàn)一個有效的搜索策略。每個事務日志文件都包含第一個元素的版本號作為其文件名的一部分。這用于快速遍歷所有事務日志文件，并查找包含一個特定版本號的事務日志文件。

監(jiān)控

CDCR通過復制操作提供以下監(jiān)視功能：

• 通過源節(jié)點和目標節(jié)點及其狀態(tài)等信息監(jiān)視傳出和傳入的復制
• 有關復制的統(tǒng)計信息，例如每秒的操作（添加/刪除）、隊列中的文檔數(shù)量等信息。

有關生命周期和統(tǒng)計數(shù)據(jù)的信息將由CDC Replicator線程以分片的形式提供。然后，CDCR API可以將這些信息匯總為一個集合級別。

CDC Replicator

CDC Replicator是一個后臺線程，負責將源數(shù)據(jù)中心的更新復制到一個或多個目標數(shù)據(jù)中心。它負責在每個碎片基礎上提供監(jiān)測信息。由于集群中可能有大量集合和分片，因此我們將使用固定大小的CDC Replicator線程池，這些線程將在分片之間共享。

CDCR限制

目前的CDCR設計有一定的局限性。CDCR將會隨著時間的推移而不斷發(fā)展，這些限制中的許多將被解決。其中包括：

• 對于更新速率較高的批量負載情況，CDCR不太可能令人滿意，尤其是在源群集和目標群集之間的帶寬受到限制的情況下。在這種情況下，應執(zhí)行初始批量加載，同步源數(shù)據(jù)中心和目標數(shù)據(jù)中心，并使用CDCR進行增量更新。
• CDCR目前只是單向的；數(shù)據(jù)被從源集群推送到目標集群。在這方面正在開展積極的工作來消除這一限制。
• CDCR 的工作原理與源和目標集合中的碎片數(shù)量相同。兩個集合中的碎片可能有不同數(shù)量的副本。
• 目前不支持使用HDFS上的索引運行CDCR，請參閱Solr CDCR over HDFS JIRA問題。
• 源和目標群集之間的配置文件(solrconfig.xml, schema 等)不會自動同步。這意味著當源模式或solrconfig.xml文件發(fā)生更改時，必須手動將這些更改復制到目標群集。這包括通過Schema API或托管資源添加字段，以及手動編輯這些文件。