ElasticSearch6 学习(八) 集群安装以及分片处理

骑猪看日落 2021-10-23 22:46 329阅读 0赞

前言:

学习路径:https://www.bilibili.com/video/av45584656  码家学院的视频

这次是记录ElasticSearch6 集群安装和分片处理

--------------------

**目录**

1.集群配置

2.数据清除

3.集群启动

4.分片配置

5.重启服务

--------------------

# 1.集群配置 #

配置三台服务器，和单机版的配置属性一致。

我将其设置ip为

192.168.137.133
    192.168.137.135
    192.168.137.136

然后三台服务器修改elasticsearch.yml 文件

vi elasticsearch.yml
    cluster.name: yourClusterName  ###保证三台服务器节点集群名称相同
    node.name: node-1 #### 每个节点名称不一样 其他两台为node-2 ,node-3
    network.host: 192.168.137.xxx #### 实际服务器ip地址
    discovery.zen.ping.unicast.hosts: ["192.168.133.133", "192.168.137.135","192.168.137.136"]##多个服务集群ip
    discovery.zen.minimum_master_nodes: 1  #主节点个数

默认底层开启9300 集群,都是通过9300去连接的

# 2.数据清除 #

注意克隆data文件会导致数据不同步

报该错误解决办法

failed to send join request to master

因为克隆导致data文件也克隆呢，直接清除每台服务器data文件。

**首先保证服务里面没有数据**

**如果有 ，去data文件删除掉数据，否则启动集群的时候会报错**

![20190816170743195.png][]

# 3.集群启动 #

非root用户启动

#进入elasticsearch的bin目录下
    cd ..../bin
    
    ./elasticsearch

可以看到后台日志是添加成功了nodes

![20190816171305465.png][]

![20190816171326534.png][]

说明是成功的，我们通过命令去看看

http://192.168.137.133:9200/_cat/nodes?pretty

![20190816171419522.png][]

可以看到目前主节点是136上的。（\*代表主节点 - 代表副节点）

# 4.分片配置 #

分片简述：

每一个主分片用来处理高可用，并且可以进行一个负载（使用到备份）。但是默认的分片呢是不理想的，会有数据丢失的情况，所以需要我们自己去重新配置分片数量

cluster ：集群
    shards：分片
    replicas：备份
    recovery：指的就是一个索引的分片分配到另外一个节点的过程

下面是个原理图：

主分片的数量在主机数量的1.5-3倍左右是比较好的。

并且每个节点是在每个服务器上都要平均分配

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI4MTk4MTgx_size_16_color_FFFFFF_t_70][]

比如：

http://192.168.137.133:9200/_cat/shards

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI4MTk4MTgx_size_16_color_FFFFFF_t_70 1][]

这样分配下来是比较好的

**注意：**

**每个节点的分片数量保持在低于每1GB堆内存对应集群的分片在20-25之间。**

**内存和分片数要控制好 分片大小为50GB通常被界定为适用于各种用例的限制。 数据量达到50G了就适合分片了**

配置一个索引的分片：

PUT /index
    {
      "settings": {
        "number_of_shards": 3, #设置分片
        "number_of_replicas": 2 # 设置备份
      }
    }

举个例子:

配置一个guodagou的索引 分片3个，2个备份

PUT http://192.168.137.133/sanzhigou
    {
      "settings": {
        "number_of_shards":3,
        "number_of_replicas": 2
      }
    }

然后查询一下：

![20190816173556835.png][]

可以看出每个服务器都有三个 一个主节点2个备份，这样就没有哪台服务器有多的或者少的。可以避免数据丢失

# 5.重启服务 #

重启服务是否影响数据丢失？

不会 因为 节点会自动同步数据 如果主节点挂掉。那么副节点会升级为主节点，以前主节点恢复后自动成为副节点 并同步数据：

举个例子：

我将node03断开

![2019081617384334.png][]

断开后：node02变成了主节点

![2019081617391759.png][]

我们在主节点添加一点数据

![20190816174630583.png][]

查询到后

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI4MTk4MTgx_size_16_color_FFFFFF_t_70 2][]

我们把停掉的节点重启

可以看到节点自动回去了 并成为了副节点

![2019081617482568.png][]

我们通过刚才重启的那个节点去查询数据，看是否能查询到

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI4MTk4MTgx_size_16_color_FFFFFF_t_70 3][]

说明数据是自动同步了的。

暂时记录到这里

还有el的日志查询没有记录

[20190816170743195.png]: /images/20211023/8bce97ad4c2f4140b68510341d1342e1.png
[20190816171305465.png]: /images/20211023/54f523dc4ffe40b3a73fea408da88a45.png
[20190816171326534.png]: /images/20211023/421a0aa8ad414490b666e19e23ef18b9.png
[20190816171419522.png]: /images/20211023/069f5a7dbb064b679992e6f09d2bc3f4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI4MTk4MTgx_size_16_color_FFFFFF_t_70]: /images/20211023/edab3616d0994bb0addbd38054e1a2fd.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI4MTk4MTgx_size_16_color_FFFFFF_t_70 1]: /images/20211023/f9e0529c3f6d4d17bb2a6539ecf60627.png
[20190816173556835.png]: /images/20211023/88c93e2093b24005ac8104622c24ab84.png
[2019081617384334.png]: /images/20211023/78de8cc910ea4009a7bc39af8060f003.png
[2019081617391759.png]: /images/20211023/67affb1cf6e947d7ba9d88c2680e0cc0.png
[20190816174630583.png]: /images/20211023/2b4b9d582aa64be7a81749ee4b85131b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI4MTk4MTgx_size_16_color_FFFFFF_t_70 2]: /images/20211023/b9539d8000c241e39440dce5fc5a7ec9.png
[2019081617482568.png]: /images/20211023/002d5a9d1e72408d8d49c616491b5f16.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI4MTk4MTgx_size_16_color_FFFFFF_t_70 3]: /images/20211023/378220715b74433cab6185d44286ffb0.png