在本篇文章中，咱们来讲述 Elasrticsearch 集群中重要的一个概念 replication，也即仿制。
了解 Elasticsearch 中的分片仿制
默认情况下，索引由单个分片组成，可是假如存储分片的节点呈现毛病（例如磁盘毛病）会怎样？ 数据丢掉是由于咱们没有它的副本。 这是一个严重的问题，由于硬件毛病随时可能产生。 用于运转集群的硬盘驱动器越多，失败的可能性就越高。 因而，保证容错和毛病搬运机制至关重要。
走运的是，Elasticsearch 原生支撑分片仿制，默认启用，无需任何装备。 这十分酷，由于许多数据库都有复杂的仿制设置。
可是 Elasticsearch 中的仿制是怎样作业的呢？
仿制在 Elasticsearch 中的作业原理
索引将其数据存储在多个分片中，这些分片可能存储在多个节点上。 相同，仿制也是在索引等级装备的。 仿制经过在索引中创立每个分片的副原本作业。 这些副本称为副本或副本分片。 已被仿制一次或屡次的分片称为主分片。 主分片及其副本分片统称为仿制组。
副本分片是分片的完好副本，能够为查找恳求供给服务，类似于主分片。 在创立索引时，咱们能够挑选每个分片有多少个副本，默认值为一个。 需要注意的是，副本数量越多，冗余和容错等级就越高。
假如主分片呈现毛病，副本分片将接收并持续为查找恳求供给服务。 Elasticsearch 主动协调查询的履行方位和并行化。 Elasticsearch 会主动挑选履行给定查询的分片，这取决于咱们稍后会讲到的许多要素。
值得一提的是，Elasticsearch 只为具有多个节点的集群增加副本分片，由于仿制仅在此类集群中有含义。 假如你的集群只要一个节点，假如该节点产生毛病，仿制将杯水车薪。 因而，有必要在出产设置中至少有两个节点以避免数据丢掉。
在 Elasticsearch 中运用副本分片的优点
除了避免数据丢掉外，仿制还能够增加给定索引的吞吐量。 在这种情况下，副本分片自身便是一个功用完全的索引，就像主分片相同。 这意味着能够一起查询两个副本分片。 任何不到 10 年前史的 CPU 都有多个内核，一般至少有四个内核。 这使 CPU 能够经过运用线程在每个内核上一起运转使命。 因而，保管两个副本分片的节点能够在每个分片上并行运转查找查询，然后增加索引的吞吐量。
挑选抱负的副本分片数量取决于你的设置的重要性。 一般，你能够运用一个或两个副本，但要害系统应该仿制它们两次或更屡次。 例如，运用 Elasticsearch 为你的个人 WordPress 博客供给查找功用，你可能会承受这种十分小的危险。 另一方面，Elasticsearch 用于医院内的要害事物将需要更多副本以保证容错和毛病搬运机制。
因而，索引包括分片，而分片又可能包括副本分片。 在此示例中，一个索引已拆分为两个主分片，每个主分片有两个副本分片。 因而，该索引包括两个仿制组。
太好了，所以咱们有每个分片的物理副本，可是假如整个磁盘停止作业而且咱们丢掉了一切数据，这有什么协助呢？ 为避免这种情况产生，副本分片永久不会与其主分片存储在同一节点上。
这意味着假如一个节点消失了，总会有至少一个分片数据的副本在另一个节点上可用。
将留下多少副本取决于为索引装备了多少个副本以及集群包括多少个节点。 在图中，你能够看到副本分片与它们所属的主分片放置在不同的节点上。
仿制只对包括多个节点的集群有含义，否则假如仅有可用的节点产生毛病，仿制将杯水车薪。 因而，Elasticsearch 只会为具有多个节点的集群增加副本分片。
你仍然能够将索引装备为包括每个分片的一个或多个副本，但在增加其他节点之前它不会有任何影响。
让咱们经过一个示例来了解 Elasticsearch 集群中的仿制是怎样作业的。 为了简略起见，假定咱们在集群中只要两个索引，而且两个索引都运用默认装备。
咱们从一个由单个节点组成的集群开端。 每个索引只包括一个分片，因而节点将包括一共两个分片。 即使索引被装备为仿制每个分片一次，副本分片也将被取消分配，由于咱们只要一个节点在运转。
这关于开发环境来说很好，由于只要在咱们丢掉数据时才会带来不便。 可是，关于出产环境，咱们真的不想冒丢掉数据的危险，因而咱们决定向集群增加一个额定的节点。
请记住，这些节点根本不需要很强壮； 它们只需要在独立的硬件上运转，这样就不会有单点毛病。
一旦 Elasticsearch 识别出咱们增加了一个额定的节点，它将启用仿制，这意味着将分配副本分片。
假如咱们随后向集群增加一个额定的节点，咱们会看到副本分片会分散开来进一步进步可用性。 在那种情况下，即使两个节点一起宕机，咱们也不会丢掉任何数据。
挑选副本分片的数量
抱负的副本分片数量是多少？ 一般，你能够运用一个或两个副本，但这取决于你的设置有多重要。
假如两个节点一起产生毛病，你是否能够从另一个数据源（例如联系数据库）康复存储在它们上的数据？ 康复数据时数据不可用是否能够承受？
假如你运用 Elasticsearch 为你的个人 WordPress 博客供给查找功用，你可能会承受这个十分小的危险。
另一方面，假如你在医院内运用 Elasticsearch 处理一些重要的事情，你可能承担不起这种危险。
依据经历，你应该仿制分片一次，关于要害系统，你应该仿制它们两次或更屡次。 这也意味着关于出产设置，你将需要至少两个节点来保护自己免受数据丢掉。
当咱们谈论避免数据丢掉时，我想简略地提一下，Elasticsearch 也支撑拍照快照（snapshot），就像许多数据库相同。
快照供给了一种备份方式，以便你能够将数据康复到某个时刻点。 你能够对特定索引或整个集群进行快照。
那么，假如咱们能够拍照快照（snapshot），为什么还需要仿制呢？
仿制确实是一种避免数据丢掉的方法，但仿制只适用于实时数据。 这实质上意味着仿制保证你不会丢掉给定索引在当时时刻点存储的数据。
另一方面，快照使你能够将集群的当时状况或特定索引导出到文件中。 然后能够运用此文件将集群或索引的状况康复到该状况。
例如，假定咱们的使命是重组数百万文档在索引中的存储方式。
当然，咱们信任它会起作用，而且咱们现已在咱们的开发环境中对其进行了测试。
为了保证咱们能够从任何问题中康复，咱们在运转任何查询之前拍照索引快照。
运转查询时，事情没有按计划进行，可能是由于咱们的测试文档与存储在实时索引中的文档不同。 不管是什么原因，文档都弄乱了，咱们需要复原更改以使事情康复到作业状况。
仿制对此无能为力，由于仿制只能保证咱们不会丢掉最新数据，这些数据已在本例中进行了修改。 相反，咱们需要将索引的状况康复到咱们拍照的快照。 经过这样做，咱们应该一切顺利，并预备好在修正一切错误后再次尝试。
希望你了解快照和仿制之间的区别。
快照一般用于日常备份，而且能够在对数据应用更改之前拍照手动快照，仅仅为了保证在呈现问题时有方法回滚更改。
怎样在不增加节点的情况下进步索引吞吐量？
仿制保证索引能够从节点毛病中康复并持续为恳求供给服务，就好像什么也没产生相同。
除了避免数据丢掉外，仿制还能够增加给定索引的吞吐量。
例如，让咱们考虑一个网上商店，其间产品存储在名为 products 的索引中。 最受欢迎的产品显现在首页上，当用户查找产品时，会针对索引运转查询。 不用说，这个索引经常被查询。
索引装备为只要一个分片，由于咱们没有很多文档，但咱们对索引运转了很多查询。 副本计数也设置为 0。
咱们开端遇到在高峰时段针对索引运转的查询的功用瓶颈，因而咱们需要找到一种方法来处理它。
开始的主意可能是向这个集群增加一个额定的节点，该集群现在由两个节点组成。 可是，只要一个主分片和一个副本分片杯水车薪，由于无论怎样咱们都不能将它们散布在两个以上的节点上。
要运用额定的节点，咱们必须增加分片的数量或副本分片的数量。 咱们真的不需要另一个节点，咱们也不想增加成本。 相反，咱们能够将副本分片的数量增加一个或咱们需要的任何数量。
由于咱们只要两个节点，咱们并没有真实增加索引的可用性，而是增加了索引的吞吐量。 可是为什么呢？
还记得我是怎样告知你的，副本分片自身便是一个功用完全的索引，就像分片相同吗？ 这意味着能够一起查询两个副本分片。 这是可能的，由于两件事：
- Elasticsearch 主动协调查询的履行方位和并行化。 Elasticsearch 会主动挑选履行给定查询的分片，这取决于咱们稍后会讲到的许多要素。
- 任何不到十年的 CPU 都有多个内核，一般至少有四个内核。 这使 CPU 能够经过运用线程在每个内核上一起运转使命。
在此示例中，这意味着保管两个副本分片的节点能够在每个分片上并行运转查找查询，然后增加索引的吞吐量。
当然，只要在节点的硬件资源还没有被充分运用的情况下，增加更多的副本分片才会对功用有优点。
在咱们的示例中便是这种情况，由于负载在咱们的索引中散布不均。 假如节点现已忙于处理对其他索引的恳求，咱们几乎看不到增加额定副本分片的影响。
除此之外，咱们还需要额定的磁盘空间来存储副本分片，由于它是主分片的完好副本。
正如我坚信你现在现已看到的那样，有很多变量会影响最佳节点、分片和副本分片的数量。
这仅仅一个怎样运用仿制来增加索引吞吐量的示例。
因而，总而言之，仿制有两个目的：
- 增加可用性。
- 增加索引的吞吐量。
在 Kibana 中探索集群健康和仿制
让咱们暂时转到 Kibana，由于我想向你展现一些东西。
首先，让咱们创立一个新索引。 这十分容易。 咱们只需指定 PUT 动词，后跟咱们要创立的索引的称号，比方：
PUT /pages
太好了，咱们的索引现已创立。
由于咱们没有指定任何设置，它是运用默认设置创立的，即一个主分片和一个副本分片。
让咱们再次查看集群。
因而，让咱们从查看集群的健康状况开端：
GET /_cluster/health
请注意集群的运转状况怎样从绿色变为黄色。 那么，这是怎样回事？
让咱们列出咱们的集群包括的索引以获取头绪：
GET /_cat/indices?v
在这里咱们能够看到咱们新创立的索引的状况设置为黄色（yellow）。 原因是索引包括一个副本分片，但该分片没有分配给任何节点。
如你所知，副本分片永久不会分配到与其主分片相同的节点。 由于咱们的集群只包括一个节点，Elasticsearch 无处可分配副本分片。
因而，副本分片正在等待分配，这便是咱们的集群和索引处于黄色状况的原因。
该索引功用完全，但假如节点呈现毛病，你将面对数据丢掉的危险。 黄色状况是对此的警告。
现在，让咱们列出集群中的一切分片并查看它们的分配方位。 为此，咱们能够运用 _cat API 及其分片指令：
GET /_cat/shards?v
成果显现每个分片的列表以及关于它的各种信息，包括它属于哪个索引。 在顶部，咱们能够看到新创立的索引有两个分片，一个是主分片，一个是副本分片。
这是在 preirep 列中指定的，其间 p 对应于主分片，r 对应于副本分片。 下一列指定每个分片的状况。 正如咱们所见，主分片的状况为 STARTED，这意味着它是一个功用完全的分片而且能够用于恳求。 另一方面，副本分片的状况为 UNASSIGNED，这是由于咱们需要向集群增加另一个节点才能使仿制生效。
现在你知道了咱们的集群处于黄色状况的原因，让咱们再次查看索引列表，由于我想向你展现最后一件事。
你是否注意到 Kibana 索引（.kibana*）装备为一个分片和零个副本？ 一个分片是有含义的，由于这些索引将存储十分少数的数据，而且查询吞吐量将受到限制。
可是没有副本分片不会让咱们面对丢掉数据的危险吗？ 是的，确实如此。 不要被这些零所迷惑，由于假如咱们向集群中增加另一个节点，这些零会增加到一。 怎样？ 由于 Kibana 索引装备了值为 0-1 的设置 auto_expand_replicas。
此设置的作用是依据集群包括的节点数动态更改副本数。
当咱们只要一个节点时，将有零个副本，而关于多个节点，将有一个副本。 你很快就会看到这个动作，所以我仅仅想指出它以防你想知道。
