修改Clone机器的ip并重启网络
因为我们是Clone的,所以两台机器的IP地址是一样的,所以我们需要修改
然后修改IPADDR这个参数即可
重启网络
之后我们就只需要分别取配置一下我们两台虚拟机中ES的elasticsearch.yml文件即可.
192.168.94.128:
192.168.94.129:
这里面还有一个主意点就是需要 打开我们刚才创建的数据以及日志目录的权限,否则是不能用的
切换到root用户执行下面的命令即可:
chmod 777 /opt/es/data #这个目录需要匹配你自己定义的数据目录 chmod 777 /opt/es/logs #这个目录需要匹配你自己定义的日志目录
之后我们重新启动我们的ES即可.
两台机器的ES都已经成功启动,但是这不能证明这两台机器就真的就已经在一个集群里面了,这时候我们还需要通过一个管理ES节点的工具Cerebro来检测,这个东西能帮助我们检查节点是否真的已经在一个集群里面了.软件我也分享出来
链接:https://pan.baidu.com/s/1QdQrcD19EfHm6esLWXYzJw
提取码:qilh
下载之后解压,以管理员身份运行该文件即可.
运行完成之后我们便可以看到这样一个界面:
之后我们访问该地址:http://localhost:9000/
之后填写我们的ES地址就可以管理我们的ES集群了:
可以看到的确已经构成了集群,并且es-1即为我们的主节点.
4.ES设置开机自启动
因为这里我这里并不是在云服务器上面搭建的ES集群,所以每次都需要我自己打开虚拟机之后自己手动开启elasticSearch,试了几天之后发现,这样太烦了,还是配置一下elasticSearch的开机自启动吧.
设置开机自启动的步骤之前我们在讲分布式文件系统的时候就已经讲过了,主要就是下面这几个步骤:
编写开机自启动脚本
我们在/etc/init.d目录下面添加elasticSearch的开机脚本
cd /etc/init.d vi elasticsearch
之后粘贴这段脚本即可,但是要 注意下面我注释标注的三个地方!!!!!
#chkconfig: 345 63 37 #description: elasticsearch #processname: elasticsearch-6.3.1 #这里需要填写你自己ES的安装目录,不一样的话记得修改 export ES_HOME=/opt/es/elasticsearch-6.3.1 case $1 in start) #这里的用户需要填写你自己的ES启动用户,不是es的话,需要修改 su es<<! cd $ES_HOME ./bin/elasticsearch -d -p pid exit ! echo "elasticsearch is started" ;; stop) pid=`cat $ES_HOME/pid` kill -9 $pid echo "elasticsearch is stopped" ;; restart) pid=`cat $ES_HOME/pid` kill -9 $pid echo "elasticsearch is stopped" sleep 1 #这里的用户需要填写你自己的ES启动用户,不是es的话,需要修改 su es<<! cd $ES_HOME ./bin/elasticsearch -d -p pid exit ! echo "elasticsearch is started" ;; *) echo "start|stop|restart" ;; esac exit 0
赋予开机脚本权限
保存退出之后,我们需要输入下面的命令:
chmod 777 elasticsearch
添加到开机服务里面同时开启开机自启
chkconfig --add elasticsearch chkconfig elasticsearch on
这样我们关于ES的开机自启动就已经完成了.不仅如此,我们还可以直接通过下面的命令启动,重启,关闭es服务
#启动es服务 service elasticsearch start #关闭es服务 service elasticsearch stop #重启es服务 service elasticsearch restart
5.ES集群工作原理(对比Mysql集群)
在说ES集群的工作原理之前,我们先来了解一下Mysql集群的工作原理.
Mysql集群的工作原理主要就是 主从复制,意思就是主数据库发生改变,从数据库就会想应该的发生改变.并且当主数据库崩溃之后会由从数据库代替主数据库,继续承担责任.
可以看到Mysql的解决方案主要就是采用了复制的概念,但是这有几个问题,一旦几台机器出了问题,那么很显然就是直接几台机器的数据完全就没了,导致后续所有数据的并发量全部都打到剩下的机器上.如下图所示:
性能肯定会有所降低.
其次就是可能还有一种情况就是在其它几台主数据库崩溃之前正在执行多次的查询,修改的操作,假设刚好这些操作从数据库还没有执行完毕即复制过程还没有结束,主数据库就突然崩溃了,那么很显然这部分的数据就没有同步号,那么很显然之后的数据就会产生差异,就如下图所示:
这个主要就是造成了 数据的不统一.
既然这样,我们再来看看ES集群是怎么做的?
ES集群所采用的的方案则是这样的 分片+复制,
其实分片+复制的概念我们已经在上面分片+副本的集群基本概念里面讲过了.
主要就是ES集群并不像Mysql集群一样一开始就是将数据存储在一台服务器上的,相反的他是将所有的数据存储在多个分片上,并且这些分片是分散的存储在所有的节点上面的.
并且他的复制过程就和我们上面所说的副本的概念是一样的.他并不像Mysql集群一样,所有从数据库都需要与主数据库进行通信,每台从数据库都需要复制主数据库的数据.ES集群则是这样,只需要每个分片与他的副本之间进行复制即可.
正是因为上述两点原因使得 ES的数据容错性非常高 ,注意虽然是非常高,但是仍然还是会出现瘫痪的.