ElasticSearch cluster
8.1. Cluster concepts
8.1.1. Why cluster
- Single node failure
- Support high concurrency
- Mass data storage
8.1.2.ES node type
By default, elasticsearch each cluster node has become eligible to master node, also store data, but also provide consulting services. In a production environment, if you do not modify the role information elasticsearch nodes, brain prone to cracking and other problems at high data volume and high concurrent scenes clusters. These functions are controlled by two properties. node.master and node.data default values of these two attributes of the case are true.
| Configuration | value | Explanation |
|---|---|---|
| node.master | true | Whether it is the primary node |
| node.data | true | Whether to store data |
-
The master node master
node.master = true, on behalf of the successful node-based qualifications, the main responsibility is the master node and cluster operations-related content, such as creating or deleting indexes, tracking which nodes are part of the cluster, and decide which slice allocated to the relevant node . Usually separate data node and the master node will, node.master = true, node.data = false
-
Data node data
node.data = true, the main node is node data store index data, mainly document CRUD operations, the polymerization operation and the like, the data node CPU, IO, high memory requirements, optimization needs to be done when a node status monitoring, node expansion to do when insufficient resources. Configuration: mode.master = false, mode.data = true
-
Load balancing client node
When the master node and the data node configuration is set to false when, the node can handle routing request, the search processing, distribution index operation , etc. In essence, the client node performance intelligent load balancer. Configuration: mode.master = false, mode.data = false
Best Practices
In a production cluster, we can divide responsibilities for these nodes, the cluster is recommended to set three or more nodes as a master node, these nodes are only responsible becomes the master node, the maintenance status of the entire cluster. Then set the number of data nodes based on the amount of data, these nodes are only responsible for storing data, the latter providing indexing and query index of service, so if a user requests more frequent, the pressure of these nodes will be relatively large, it is proposed again in the cluster set a number of client nodes (node.master: false node.data: false), these nodes are only responsible for processing user requests, forwarding the request to achieve load balancing and other functions.
8.2.ES cluster understanding
8.2.1.shard & replica mechanism
-
comprising a plurality of shard index, a shard is the smallest unit of work, the data storage section, and the complete indexing process capability index
-
primary shard and its replica shard can not be placed on the same node (or node goes down, primary shard and replica are lost, would not achieve the role of fault-tolerant), but other primary shard of replica shard on the same node
-
When changes in the node, shard will automatically load balancing nodes in
Two main Shard, 2 slaves Shard, 3 th Node -> 2 main Shard, 2 slaves Shard, 4 th Node
[Image dump the chain fails, the source station may have security chain mechanism, it is recommended to save the picture down uploaded directly (img-6KEG3nJm-1581164302084) (images / image-20191115145540717.png)]
-
primary shard and replica shard, each document must exist only a certain primary shard and its corresponding replica shard in, can not exist in a plurality of primary shard
-
replica shard is a copy of the primary shard, responsible for fault tolerance (spare tire, prepare new master), and bear the load of a read request - separate read and write
-
The number of primary shard in the creation of the index is fixed, and the number of replica shard can be modified at any time
-
The default primary shard number is 5, replica is 1 by default, default 10 has shard, 5 th primary shard, 5 th replica shard
8.2.2. Shard illustrates distribution
a. Create a single-node environment index
Single-node environment, create an index, there are three primary shard, 3 Ge replica shard
[Image dump the chain fails, the source station may have security chain mechanism, it is recommended to save the picture down uploaded directly (img-LnWnrevQ-1581164302086) (images / image-20191115150151306.png)]
- This time, three primary shard will only be assigned to only one node up, the other three replica shard is not allocated
- Cluster status is yellow
- Clusters can work, but once the node goes down occurs, all the data is lost, but the cluster is unavailable, you can not undertake any request
b. Create index under two node environment
The next two node environment, create an index, 3 Ge primary shard, 3 Ge replica shard
[Image dump the chain fails, the source station may have security chain mechanism, it is recommended to save the picture down uploaded directly (img-30Drxzsq-1581164302087) (images / image-20191115150344097.png)]
c. limit expansion, improve fault tolerance
How to achieve better performance?
- Each Node fewer Shard, Shard each with plenty of resources, higher performance
- Expansion limit: 6 shard (3 primary, 3 replica), expandable to up to six machines, each shard can take up all the resources of a single server, the best performance
- Expansion exceeds the limit, the number of dynamic modification Replica, 9 th shard (3primary, 6 replica), 9 to expansion machines, machines than 3, has three times the read throughput
8.2.3. Fault Tolerance -Master election
-
master node goes down, automatic master election, - Red
When a PrimaryShard (master slice) goes down, a ReplicShard this PrimaryShard of (prepared slices) will be elected to become PrimaryShard.
-
Replica fault tolerance: the replica to be the new primary shard, - yellow
After the election of a new master slice is successful, to ensure the integrity of the main fragment, but one less slice preparation, the state became a yellow
-
Restart node goes down: will generate new ReplicShard, if there is data before downtime, data before will first restore and then copy the new data from PrimaryShard, the benefits of doing so are: 1. recovery performance, 2. avoid data synchronization delay data loss caused by (at the moment of downtime, some data is not synchronized to ReplicShard, may result in loss of data)
8.3. Cluster Setup
8.3.1. Environmental preparation
Real environment
| NodeName | Web port, the client port |
|---|---|
| node-1 | 172.168.1.1:9200 172.168.1.1:9300 |
| node-2 | 172.168.1.2:9200 172.168.1.2:9300 |
| node-3 | 172.168.1.3:9200 172.168.1.3:9300 |
Simulation environment
| NodeName | Web port, the client port |
|---|---|
| node-1 | 127.0.0.1:9201 127.0.0.1:9301 |
| node-2 | 127.0.0.1:9202 127.0.0.1:9302 |
| node-3 | 127.0.0.1:9203 127.0.0.1:9303 |
Note: You need to prepare three ES (copy), and then delete the data directory, if the computer is not enough memory, memory can be set in piecemeal jvm.properties
8.3.2. Configuration instructions
- cluster.name
集群名，自定义集群名，默认为elasticsearch，建议修改，因为低版本多播模式下同一网段下相同集群名会自动加入同一集群，如生产环境这样易造成数据运维紊乱。
- node.name
节点名，同一集群下要求每个节点的节点名不一致，起到区分节点和辨认节点作用
- node.master
是否为主节点，选项为true或false，当为true时在集群启动时该节点为主节点，在宕机或任务挂掉之后会选举新的主节点，恢复后该节点依然为主节点
- node.data
是否处理数据，选项为true或false。负责数据的相关操作
- path.data
默认数据路径，可用逗号分隔多个路径
- path.logs
默认日志路径
- bootstrap.mlockall
内存锁，选项为true或false，用来确保用户在es-jvm中设置的ES_HEAP_SIZE参数内存可以使用一半以上而又不溢出
- network.host
对外暴露的host，0.0.0.0时暴露给外网
- http.port
对外访问的端口号，默认为9200，所以外界访问该节点一般为http://ip:9200/
- transport.tcp.port
集群间通信的端口号，默认为9300
- discovery.zen.ping.unicast.hosts
集群的ip集合，可指定端口，默认为9300，如 ["192.168.1.101","192.168.1.102"]
- discovery.zen.minimum_master_nodes
最少的主节点个数
- discovery.zen.ping_timeout
主节点选举超时时间设置
- gateway.recover_after_nodes
值为n，网关控制在n个节点启动之后才恢复整个集群
- node.max_local_storage_nodes
值为n，一个系统中最多启用节点个数为n
- action.destructive_requires_name
选项为true或false，删除indices是否需要现实名字
8.3.3. Modify ES configuration
- Node1- Configuration
# 统一的集群名
cluster.name: my-ealsticsearch
# 当前节点名
node.name: node-1
# 对外暴露端口使外网访问
network.host: 127.0.0.1
# 对外暴露端口
http.port: 9201
#集群间通讯端口号
transport.tcp.port: 9301
#集群的ip集合，可指定端口，默认为9300
discovery.zen.ping.unicast.hosts: ["127.0.0.1:9301","127.0.0.1:9302","127.0.0.1:9303"]
- Node2- Configuration
# 统一的集群名
cluster.name: my-ealsticsearch
# 当前节点名
node.name: node-2
# 对外暴露端口使外网访问
network.host: 127.0.0.1
# 对外暴露端口
http.port: 9202
#集群间通讯端口号
transport.tcp.port: 9302
#集群的ip集合，可指定端口，默认为9300
discovery.zen.ping.unicast.hosts: ["127.0.0.1:9301","127.0.0.1:9302","127.0.0.1:9303"]
- Node3- Configuration
# 统一的集群名
cluster.name: my-ealsticsearch
# 当前节点名
node.name: node-3
# 对外暴露端口使外网访问
network.host: 127.0.0.1
# 对外暴露端口
http.port: 9203
#集群间通讯端口号
transport.tcp.port: 9303
#集群的ip集合，可指定端口，默认为9300
discovery.zen.ping.unicast.hosts: ["127.0.0.1:9301","127.0.0.1:9302","127.0.0.1:9303"]
ES were started three nodes, visit: http: //127.0.0.1: 9201 /
8.4 Connecting clusters
8.4.1. Modify configuration kibana
elasticsearch.url: "http://localhost:9201"
Wherein a connection node connected to the entire cluster can be natural, then start Kibana
8.4.2. Cluster View command
Creating an index
PUT shopping
{
"settings":{
"number_of_shards":5,
"number_of_replicas":1
}
}
- ? GET _cat / nodes v: View Node
- GET _cat / indices v:? View index database
- GET / _cat / shards v:? View fragmentation
- GET / _cat / shards / {index}: an index where fragmentation view library
