2.1 解压
2.2 修改配置文件kibana.yml，文件位置在解压后的文件夹下config下
修改内容，主要是 server.port、server.host、elasticsearch.url、kibana.index。
2.3 启动
启此搏动成功后在浏览器输入 http://192.168.110.27:5601 即可访问
打开Dev Tools
3.1 获取所有数据
3.2 新增数据
3.3 查询某条数据
原文地址： https://blog.csdn.net/qq_28323595/article/details/110917051
更多 *** 作请看这里：败握 https://www.cnblogs.com/liuqijia/p/11507494.html
elasticsearch默认开启两个端口：9200，用于ES节点和外部通讯；9300，用于ES节点之间通讯
报错： org.elasticsearch.bootstrap.StartupException: java.lang.RuntimeException: can not run elasticsearch as root ，不能以root用户的身份运行elasticsearch
解决方法：新建用户组和用户，并赋予其elasticsearch文件夹的权限
再次运行
WARN： java.lang.UnsupportedOperationException: seccomp unavailable: CONFIG_SECCOMP not compiled into kernel, CONFIG_SECCOMP and CONFIG_SECCOMP_FILTER are needed ，使用新的linux版本即可，不影响使用
启动失败，出现上面四个错误，一一解决
ERROR[1]：无法创建本地文件问题，用户最大可创建文件数太小
解决方法：切换到root用户，编辑limits.conf配置文件
ERROR[2]：无法创建本地线程问题，用户最大可创建线程数太小
解决方法：切换到root用户，进入limits.d目录下，修改90-nproc.conf 配置文件
ERROR[3]：最大虚拟内存太小
解决方法：切换到root用户下，修改配置文件sysctl.conf
ERROR[4]：这是在因为Centos6不支持SecComp，而ES5.2.0默认bootstrap.system_call_filter为true进行检测，所以导致检测失败，失败后直接导致ES不能启动
解决方法：在elasticsearch.yml中郑简配置bootstrap.system_call_filter为false
解决完成后，重新启动，启动成功
如果要在后台运行，使用 ./bin/elasticsearch -d 启动
访问 http://192.168.1.200:9200/，返回数据
现在启动elasticsearch，提示jar包冲突
现在启动elasticsearch，没有异常，我们测扒哪试一下hanlp分词插件有没有生效
访问： http://192.168.1.200:9200/_analyze?text=%E4%B8%AD%E5%9B%BD%E7%9A%84%E5%86%9B%E4%BA%8B%E5%AE%9E%E5%8A%9B%E4%B8%8E%E6%97%A5%E4%BF%B1%E5%A2%9E&analyzer=hanlp
elasticsearch报错并且退出运行
看上去是权限的问题，这就用到hanlp目录下的 plugin-security.policy 文件，修改 /elasticsearch/config/jvm.options 文件，在末尾添加
继续测试上面的链接，提示找不到hanlp.properties，hanlp无法加载词典，elasticsearch退出运行，解决方喊此裤法：修改 /elasticsearch/bin/elasticsearch.in.sh 文件，将ES_CLASSPATH修改为：
继续测试上面的链接，访问成功，返回结果
可以看到分词效果比较好，而且停用词也被过滤了，大功告成！
一个 Elasticsearch 集群由一个或多个节点（Node）组成，每个集群都有一个共同的集群名称作为标识。
一个 Elasticsearch 实例即一个 Node，一台机器可以有多个实例，正常使用下每个实例应该会部署在不同的机器上。Elasticsearch 的配置文件中可以通过 node.master、node.data 来设置节点类型。
node.master：表示节点是否具有成为主节点的资格
node.data：表示节点是否存储数据
节点即有成为主节点的资格，又存储数据。这个时候如果某个节点被选举成为了真正的主节点，那么他还要存储数据，这样对于这个节点的压力就比较大了。Elasticsearch 默认每个节点都是这样的配置，在测试环境下这样做没问题。实际工作中建议不要这样设置，这样相当于主节点和数据节点的角色混合到一块了。
节点没有成为主节点的资格，不参与选举，只会存储数据。在集群中需要单独设置几个这样的节点负责存储数据，后期提供存储和查询服务。主要消耗磁盘，内存。
不会存储数据，有成为主节点的资格，可以参与选举，有可能成为真正的主节点。普通服务器即可(CPU、内存消耗一般)。
不会成为主节点，也不会存储数据，主要是针对海量请求的时候可以进行负载均衡。普通服务器即可（如果要进行分组桐猜仿聚合 *** 作的话，建议这个节点内存也分配多一点）
在生产环境下，如果不修改 Elasticsearch 节点的角色信息，在高数据量，高并发的场景下集群容易出现脑裂等问题。
一个集群下可以有多个索引，每个索引是一系列相同格式文档的集合 （Elasticsearch 6.x 已不支持一个索引下多个Type） 。
每个索引有一个或多个分片，每个分片存储不同的数据。分片可分为主分片（局纤 primary shard）和复制分片（replica shard），复制分片是主分片的拷贝。默认每个主分片有一个复制分片（默认一个索引创建后会有5个主分片，即：5主+5复制=10个分片），一个索引的复制分片的数量可以动态地调整，复制分片从不与它的主分片在同一个节点上（防止单点故障）。
复制分片有两个作用：
根据以下说明调整 elasticsearch.yml 对应参数配置，node2、node3 其他配置与node1一致兆梁。
到目前位置，集群的配置就完成了，下面我们分别启动每个实例。
根据配置文件中的注释：
所以我们配置了 discovery.zen.minimum_master_nodes: 2 ，所以必须有两个主节点启动成功，集群才算生效。
进入目录 elasticsearch-6.2.1-1 启动第一个节点，执行命令：bin\elasticsearch.bat。从日志中可以看出并没有成功，因为没发现足够的master节点。
当第二个master节点启动成功时，整个集群状态变为正常。
3个节点全部启动成功，通过 elasticsearch-head 插件查看集群状态，通过集群健康值：green，表示集群一切正常。目前集群内没有任何数据，所以看不出索引与分片的情况。
Elasticsearch 一般会配合 Kibana + X-Pack 对集群数据分析、监控等，官方标配。这里使用了 elasticsearch-head 插件，一个比较小巧的工具。插件的安装方法请看： elasticsearch-head 安装介绍
添加测试数据：
从截图可以看出，目前一共3个节点，一个索引 test，test 索引有5个主分片（边框加粗），5个复制分片（边框不加粗），分片会别均匀的分布到每个节点中。
我们尝试干掉node3，node3 从集群退出之后，集群在短时间内会对分片进行重新分布，当然依赖遵循主、复制分片不会在同一个Node。
如果我们继续把node2干掉，那么整个集群就挂了，集群健康值：未连接。因为当前可用的主节点数 1 <discovery.zen.minimum_master_nodes 设置的 2。
我们尝试把 discovery.zen.minimum_master_nodes 设置成 1，然后重启启动一个节点，会发现有一个 Unassigned 的节点，集群健康值：yellow (5 of 10)。这种情况下代表主分片全部可用，存在不可用的复制分片，5个复制分片没有分配到节点上，不过此时的集群是可用的，我们任何请求都能处理，只是所有的 *** 作都落到主分片上，而且可能引发单点故障。当我们把第二个节点启动后，一切就恢复正常了，主分片的数据会同步到复制分片。
实际生产环境，每个节点可能设置不同的节点类型，我们在3个节点的基础上再增加两个节点，然后调整 node.master 和node.data 的值，最终设置为2个主节点，2个数据节点，1个客户端节点。
node1 和 node2 是具有主节点选举权限的节点，这里 node1 被选举为master节点。node3 和 node4 是数据节点，所以数据分片只会分配在这两个节点上。node5 是客户端节点，最终是对请求起到负载均衡的作用。
如果是Linux环境下，启动可能没有这么顺利，可以参考 Linux 环境下安装 elasticsearch 5.x、6.x 问题汇总 。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）