Q：我现在要部署es集群，最少需要配置几台es服务器？如果配置3台es服务器，一台用于主节点，一台用于客户端节点，一台用于数据节点，怎么配置分片数和副本分片数？ >部署 ES 集群的节点数量并没有硬性的规定，而是要根据业务需求和实际情况来设计。通常，为了确保数据的高可用性和性能，建议运行至少三个节点的集群。一般来说，使用以下的安排来部署这三个节点： - 两个节点用作数据节点，存储索引的数据和搜索操作。 - 另一个节点可以配置为主节点和客户端节点，负责集群和元数据的管理。 因此，如果你有三台服务器可以使用，可以根据以下方式来部署 ES 集群： - 将两个节点配置为数据节点。 - 将第三个节点配置为主节点和客户端节点。 关于分片和副本的配置，具体取决于你的使用情况。在一般情况下，以下是分片和副本的一些建议设置： - 索引分片数（Primary Shards）：通常建议将索引分片数设置为 5 或更多，具体数量可以根据数据量、查询并发数、存储性能和可用性等因素调整。 - 副本分片数（Replica Shards）：建议将副本分片数设置为 1 或更多，以确保高度可用性和数据的备份。通常建议将副本数量设置为更高的奇数，例如 1、3 或 5。这是因为当节点故障时，集群可以保持节点数量的奇偶性，并避免出现数据不一致的情况。 在实际部署时，必须将分片和副本的配置考虑在内。你可以在创建索引时进行设置，也可以在之后单独更改分片和副本参数。可以使用 Elasticsearch 的控制台或 API 进行这些操作。 Q：我现在要部署es集群，需要配置3台es服务器，一台用于主节点，一台用于客户端节点，一台用于数据节点，请问需要分别购买几核几G的服务器，请推荐一个配置？ > 为了配置一个满足这种情况的ES集群，需要好好考虑下面几点，来决定服务器的硬件： 1.主节点（Master Node）：主节点仅管理群集状态和Master-eligible Node中的集群元数据。在功能上对CPU、存储和内存消耗都非常低，关键在于需要保证节点的高可用性。因此，对于主节点, 我们可以选择较低配的服务器来实现主节点的高可用性。例如，4核8线程，8GB存的服务器就已经足够。 2.客户端节点（Client Node）：客户端节点作为代理来处理路由，协调请求和将请求转发到正确的节点合适，用于负责web或类似的操作和向上公共api的客户端请求。 对于客户端节点而言，存和CPU相对于主节点是更重要的, 因为它们需要处理来自外部web客户端或者客户端软件的请求。我们荐选择8核16线程，16GB内存的中高端级别的服务器。 3.数据节点 (Data Node): 数据节点用于存储数据和执行查询操作。在存储和处理数据时，我们需要考虑服务器的性能和存储容量。对于数据节点, 我们推荐选择16核32线程，128GB内存，至少4TB存储容量（如果你使用二级别存储则可以满足需求）。对于数据节点，硬盘性能是流式操作的瓶颈，因此使用SSD或NVMe硬盘将会有很大的帮助。 结合上面的介绍，如果预算允许，我的建议是，选用一台16核32线程，128GB内存的服务器作为数据节点, 还需要统计你应用的请求量确定客户端节点和有多少个master-eligible Node。还需要注意公网IP的数量, 特别是对于客户端节点因为他们是提供给外部客户端请求数据的入口。同时建议采用云厂商提供的弹性伸缩服务根据需求动态价集群数量。 Q：部署集群的话，索引数据只需要同步到数据节点？还是说主节点和客户端节点也需要？ > 在一个ES集群中，数据索引是被存储在数据节点上的，并且主节点和客户节点不需要存储实际的数据索引。具体来说，主节点仅管理集群状态和Metadata（元数据），客户端节点仅与客户端相关操作和路由请求，将其转发到相应的节点。而数据节点则承担着存储索引数据并处理搜索操作的任务。 当客户端发送一个请求时，请求被发送到客户端节点，客户端节点再将请求转发到最适合处理该请求的数据节点。数据节点在其本地请求，返回结果并将结果发送回客户端节点，客户端节点再结果发送回到客户端。因此，像查询和写入索引的任务都是在数据节点上执行的，而并不需要主节点和客户端节点存储索引数据。 需要注意的是，所有的节点都需要知道集群状态和元数据信息，因此主节点和客户端节点需要与数据节点保持通信以获取元数据和集群信息。但是，这些信息的大小相对较小，不像索引数据占用那么多硬空间。 Q：如果只是索引数据存在数据节点上的话，那如何保证数据的高可用性？es集群是否有自己的数据同步策略，将数据同步到主节点和客户端节点上？ > 确保数据的高可用性是ES集群中最基本的要求之一。为了确保数据的高可用性，ES采用了一些机制： 1.副本机制：在ES集群中，数据可以分片，许多数据分片可以存放在不同的数据节点上。针对每一个分片，ES允许你分配零个或多个副本。副本是分片的精确的复制品并存储在其他的节点上。当主分片的数据节点故障时，集群会从一个副本分片中选择一个新的主分片。这种机制确保只要至少有一个副本分片没有故障，数据就不会丢失。 2.主节点优化（Master Node Failure Detection）: 主节点负责在集群中协调元数据和状态，但主节点故障后可能导致集群不可用，因此集群必须为主节点的失败提供容错。ES 通过使用超时和心跳等机制来监视主节点，并选举新的主节点。因此，即使主节点故障，集群也可以继续工作。 3.数据同步：虽然数据在存储和查询时只存放在数据节点上，但数据同步也是很重要的。ES会自动将新创建的索引分片和副本分配到不同的数据节点上，以实现负载均衡。当索引分片或副本在一个节点上失败时，其他节点会接管这个分片或副本。这种机制确保数据在整个集群中是均衡和可用的。 因此，ES集群确实有自己的自动数据同步策略和机制来确保数据的高可用性。ES将使用副本、主节点优化和数据同步等机制来确保集群中的数据总是可用和一致的。虽然数据只存储在数据节点上，但所有节点都有元数据和状态的副本，以确保状态在整个集群中是一致的。 Q：集群的元数据是指什么？ > 在 Elasticsearch 中，元数据（Metadata）是指用于管理集群和节点信息的数据。它们包含有关索引和映射的信息，用于跟踪节点和集群状态，并支持 Elasticsearch 的自我管理和自我维护。以下是一些常见的元数据类型： - 索引元数据：用于跟踪索引和它们一些属性，例如索引分片和副本的数量、索引设置和映射。这些元数据包含在集群的主节点中，可以协调集群中的所有节点并管理索引的创建和删除等操作。 - 节点元数据：用于跟踪节点状态、硬件配置和节点标识符等信息。这些元数据包含在节点本身中，并且可以通过主节点查询和管理。 - 集群元数据：用于跟踪集群状态和节点对等体信息，以及集群级别设置和配置等信息。这些元数据存储在主节点中，可以预算和管理整个集群的状态。 数据在 Elasticsearch 中起着重要的作用，因为它们允许 Elasticsearch 自我维护和自我管理，从而提高了系统的可用性和性能。在集群中，元数据被复制和分发到每个节点，以便在任何节点发生故障时都可以维护整个系统的连通性。此外，元数据还为像索引的自动扩展、自动故障转移和系统监视等自动化功能提供支持。 Q：一台服务器怎么同时部署主节点和客户端节点？ > 在 Elasticsearch 中，主节点和客户端节点默认是可以在同一台服务器上部署的。在这种情况下，Elasticsearch 需要在同一节点上运行两个角色：主节点来管理集群和元数据，客户端节点作为查询接口和跟踪索引状态的功能。要将一台服务器配置为同时担任主节点和客户端节点角色，请按照以下步骤操作： 1. 在 Elasticsearch 的配置文件中设置 node 和 node.data 的参数都为 true，同时设置 node.client 参数也为 true。这样可以启动 Elasticserch 节点以担任这两个角色。 2. 启动 Elasticsearch 服务，等待 Elasticsearch 将主节点和客户端色启用在同一节点上。这样，Elasticsearch 将同时接受自其他节点的查询请求，并维护整个集群的状态和元数据。 需要注意的是，如果你将主节点和客户端节点部署在同一个服务器上，可能会影响查询性能，并且增加了由于服务器故障而导致数据不可用的风险。因此，在可行的情况下，应将主节点和客户端节点分别部署在不同的服务器上确保更好的性能和高可用性。 Q：如果es集群里有2台数据节点服务器，这时候我需要分别将数据同步到这2台数据节点服务器上？还是说我只要同步到一台上，es就会帮我自动帮我同步到另外一台上？ > 当 Elasticsearch 集群中有多个数据节点时，Elasticsearch会自动在所有数据节点之间同步数据，这意味着你只需要先将数据同步到一个节点上，Elasticsearch 就会自动同步数据到其他数据节点。你无需在复制数据到每个节点，Elasticsearch 会自动负责数据的复制和分布。 所有Elasticsearch节点都是对等的，不像传统的主从复制模式，它们都是等价的。这也就意味着您一旦将数据和索引提交到一个节点，这些数据和索引将会自动同步到集群中的其它数据节点上。这个机制叫做数据自动分片（sharding）和副本（replica）。 当你在操作一个节点时，集群将自动地索引和数据复制到其它几个节点上。如果因为某种原因其中一个节点停机了，那么集群将自动选择另一个节点来接管正在执行的任务，这个机制叫做主节点选举。这也就是说当一个节点磁盘严重损坏或其他硬件故障时，Index数据不会丢失，系统会通过副本机制保护数据安全性。 因此，您只需要将数据同步到第一个数据节点上，该节点将自动将数据同步到其他节点。不需要额外的同步配置或操作。 Q：es是怎么实现负载均衡的，例如有哪些策略？需要配置吗？如何配置？ >ES（Elasticsearch）通过分发和处理集群中不同节点上请求的方式实现负载均衡，具体实现方式为采用一致性哈希算法，将每个请求路由到不同的节点上，从而达到负载均衡的效果。 cluster.routing.allocation.balance.type: round_robin // 默认的负载均衡策略，如果在Elasticsearch集群上没有手动更改负载均衡策略，它将默认使用轮询策略来分配请求。通过使用_cat/allocation?v API，可以查看Elasticsearch集群当前的节点分配状态和负载均衡策略。 ES中有多种负载均衡策略，例如： >1. Round Robin（轮询）：ES在每个节点之间轮流分配请求，均衡地将请求分配到不同的节点。 >2. Least Connections（最少连接数）：ES在节点之间均匀地分配请求，但是只将请求分配给当前连接数最少的节点。 >3. Random（随机）：ES将每个请求随机地分配给节点，从而实现负载均衡。 Q：那我如何知道当前查询请求是在哪一个节点处理的？ > 在Elasticsearch中，您可以使用 `_cat` API 来查询、监控和管理节点和集群状态。 通过使用 `_cat` API 并指定适当的参数，您可以查看与负载均衡相关的各种信息。 其中，您可以使用 `_cat/shards` API 来查看索引的副本和碎片在不同节点上的分配情况。 例如，以下命令将显示对 `my_index` 索引进行查询时碎片所在位置的信息： ``` GET _cat/shards/my_index?v ``` 命令返回值中的 `shard` 和 `node` 字段可以用来查看在哪个节点上处理了当前请求。 除了这个API之外，您还可以使用Elasticsearch自带的 `_cat/nodes` API 查看节点的相关信息，包括节点的状态、名称、IP地址等。例如，以下命令将显示Elasticsearch所有节点的当前信息和状态： ``` GET _cat/nodes?v ``` 命令返回值中的 `name` 和 `ip` 帮助您知道当前请求是在哪个节点处理的。 更多的Elasticsearch `_cat` API，包括`_cat/indices`、`_cat/aliases`、`_cat/tasks`等，都可以让您更好地跟踪监控和管理Elasticsearch集群中的不同状态。