CDCR概述

跨數(shù)據(jù)中心復制（CDCR）允許您創(chuàng)建多個SolrCloud數(shù)據(jù)中心并使它們保持同步。

該SolrCloud架構設計支持在一個數(shù)據(jù)中心的多個節(jié)點（NRT）上的 Solr 集合附近的實時搜索?！癈DCR”通過將更新從一個數(shù)據(jù)中心的Solr集合轉發(fā)到另一個網絡延遲大于SolrCloud模型的數(shù)據(jù)中心的并行Solr集合來增強此模型。

什么是CDCR？

CDCR支持將數(shù)據(jù)從一個數(shù)據(jù)中心復制到多個數(shù)據(jù)中心。該解決方案的初始版本支持單向方案，即將數(shù)據(jù)更新從源數(shù)據(jù)中心復制到一個或多個目標數(shù)據(jù)中心。

目標數(shù)據(jù)中心不會將更新 (如添加、更新或刪除) 傳播到源數(shù)據(jù)中心，并且不應將更新發(fā)送到任何目標數(shù)據(jù)中心。

在CDCR運行時，源數(shù)據(jù)中心和目標數(shù)據(jù)中心可以提供搜索查詢。由于傳播延遲，目標數(shù)據(jù)中心將滯后于源集群。

只有將源數(shù)據(jù)中心上的數(shù)據(jù)更改保存到磁盤后，才會將其復制到目標數(shù)據(jù)中心。數(shù)據(jù)更改可以近實時地（稍微延遲）被復制，或者可以安排在更長的時間間隔內發(fā)送到目標數(shù)據(jù)中心。CDCR可以將集合“引導”到目標數(shù)據(jù)中心。由于這是整個索引的完整副本，所以應該考慮網絡帶寬。當然，源和目標集合可能是空的開始。

源數(shù)據(jù)中心中的每個分片負責人將負責將其更新復制到目標數(shù)據(jù)中心的相應負責人。當從源數(shù)據(jù)中心接收到更新時，目標數(shù)據(jù)中心中的分片領導將按照正常的SolrCloud更新將更改復制到自己的副本。

此復制模型旨在容忍某些連接性下降，容納有限的帶寬，并支持批量更新以優(yōu)化通信。

復制同時支持新的空索引和預建索引。在源集群中的預構建索引上設置復制并且目標集群上沒有任何內容的情況下，CDCR將把整個索引從源復制到目標。這個功能被添加到Solr 6.2中。

初始實現(xiàn)的單向性意味著從Source集合到Target集合的“push”模型。因此，Source配置必須能夠“查看”目標集群中的ZooKeeper集合。ZooKeeper集合在源solrconfig.xml文件中提供。

CDCR配置為按照逐個集合的方式從源集群中的集合復制到目標集群中的集合。由于CDCR配置在solrconfig.xml（在源和目標群集上），所以可以根據(jù)每個集合的需要量身定制設置。

可以將CDCR配置為從同一集群中的一個集合復制到第二個集合。這是本文檔中沒有涉及的一種特殊情況。

CDCR術語表

本文中使用的術語包括：

• Node
  

  運行Solr的JVM實例；一臺服務器。

• Cluster
  

  由一個ZooKeeper集合管理一個或多個集合的一組Solr節(jié)點。

• Data Center
  

  托管Solr集群的一組網絡服務器。在本文檔中，“Cluster”和“Data Center”這兩個術語是可以互換的，因為我們假設每個Solr群集都駐留在不同的聯(lián)網服務器組中。

• Shard
  

  單個邏輯集合的子索引。這可能分布在群集的多個節(jié)點上。每個分片可以有1-N個副本。

• Leader
  

  每個碎片都有一個副本被確定為其leader。所有屬于分片的文檔的寫入都通過leader傳送。

• Replica
  

  用于故障轉移或負載平衡的碎片副本。包含碎片的副本可以是leader也可以是非leader。

• Follower
  

  對于不是分片leader的副本的便利術語。

• Collection
  

  邏輯索引，由一個或多個碎片組成。一個集群可以有多個集合。

• Update
  

  以任何方式更改集合索引的操作。這可能是添加新文檔，刪除文檔或更改文檔。

• Update Log(s)
  

  由每個節(jié)點維護的寫入操作的追加日志。

CDCR架構

這里是CDCR數(shù)據(jù)流的圖片。

首先將更新和刪除寫入到源群集，然后轉發(fā)到目標群集。數(shù)據(jù)流的順序是：

1. 碎片組長接收由其更新處理器鏈處理的新更新。
2. 數(shù)據(jù)更新首先應用于本地索引。
3. 在本地索引上成功應用數(shù)據(jù)更新后，數(shù)據(jù)更新將被添加到“更新日志”隊列中。
4. 數(shù)據(jù)更新持久化到磁盤后，數(shù)據(jù)更新將發(fā)送到數(shù)據(jù)中心內的副本。
5. 步驟4成功后，CDCR從更新日志讀取數(shù)據(jù)更新并將其推送到目標數(shù)據(jù)中心中的相應集合。為了確保源數(shù)據(jù)中心和目標數(shù)據(jù)中心之間的一致性，這是必要的。
6. 目標數(shù)據(jù)中心的負責人在本地寫入數(shù)據(jù)并將其轉發(fā)給所有追隨者。

步驟1、2、3和4由SolrCloud同步執(zhí)行；步驟5由后臺線程異步執(zhí)行?？紤]到CDCR復制是異步執(zhí)行的，因此可以推送批量更新以最小化網絡通信開銷。此外，如果CDCR無法在給定時間推送更新（例如，由于連接性降低），則以后可以重試，而不會對Source數(shù)據(jù)中心產生任何影響。

這個架構的一個含義是，源集群中的leader必須能夠“看到”目標集群中的leader。由于leader可能在源和目標集合中都發(fā)生變化，這意味著源集群中的所有節(jié)點都必須能夠“查看”目標集群中的所有Solr節(jié)點，因此必須配置防火墻，ACL規(guī)則等以允許這樣做。

如果源簇和目標簇具有相同數(shù)量的碎片，則當前設計最有效。沒有要求源和目標集合中的分片具有相同數(shù)量的副本。

在源和目標集群上有不同數(shù)量的碎片是可能的，但也是“專業(yè)”配置，因為該選項會強加某些約束，并且通常不建議這樣做。通過在每個Solr實例上托管多個碎片，可以更好地完成大多數(shù)具有不同碎片數(shù)量的情況。