CDCR概述

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

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

什么是CDCR？

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

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

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

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

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

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

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

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

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

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

CDCR術(shù)語(yǔ)表

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

• Node
  

  運(yùn)行Solr的JVM實(shí)例；一臺(tái)服務(wù)器。

• Cluster
  

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

• Data Center
  

  托管Solr集群的一組網(wǎng)絡(luò)服務(wù)器。在本文檔中，“Cluster”和“Data Center”這兩個(gè)術(shù)語(yǔ)是可以互換的，因?yàn)槲覀兗僭O(shè)每個(gè)Solr群集都駐留在不同的聯(lián)網(wǎng)服務(wù)器組中。

• Shard
  

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

• Leader
  

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

• Replica
  

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

• Follower
  

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

• Collection
  

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

• Update
  

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

• Update Log(s)
  

  由每個(gè)節(jié)點(diǎn)維護(hù)的寫入操作的追加日志。

CDCR架構(gòu)

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

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

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

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

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

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

在源和目標(biāo)集群上有不同數(shù)量的碎片是可能的，但也是“專業(yè)”配置，因?yàn)樵撨x項(xiàng)會(huì)強(qiáng)加某些約束，并且通常不建議這樣做。通過(guò)在每個(gè)Solr實(shí)例上托管多個(gè)碎片，可以更好地完成大多數(shù)具有不同碎片數(shù)量的情況。