CDCR概述

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

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

什么是CDCR？

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

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

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

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

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

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

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

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

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

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

CDCR術(shù)語表

本文中使用的術(shù)語包括：

• Node
  

  運行Solr的JVM實例；一臺服務(wù)器。

• Cluster
  

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

• Data Center
  

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

• Shard
  

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

• Leader
  

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

• Replica
  

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

• Follower
  

  對于不是分片leader的副本的便利術(shù)語。

• Collection
  

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

• Update
  

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

• Update Log(s)
  

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

CDCR架構(gòu)

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

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

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

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

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

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

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