三、Elasticsearch集群
ElasticSerach集群安装
l 修改配置文件elasticserach.yml
vim /elasticsearch.yml
cluster.name: aubin-cluster #必须相同
# 集群名称（不能重复）
node.name: els1（必须不同）
# 节点名称，仅仅是描述名称，用于在日志中区分（自定义）
#指定了该节点可能成为 master 节点，还可以是数据节点
node.master: true
node.data: true
path.data: /opt/data
# 数据的默认存放路径（自定义）
path.logs: /opt/logs
# 日志的默认存放路径
network.host: 192.168.0.1
# 当前节点的IP地址
http.port: 9200
# 对外提供服务的端口
transport.tcp.port: 9300
#9300为集群服务的端口
discovery.zen.ping.unicast.hosts: ["172.18.68.11", "172.18.68.12","172.18.68.13"]
# 集群个节点IP地址，也可以使用域名，需要各节点能够解析
discovery.zen.minimum_master_nodes: 2
# 为了避免脑裂，集群节点数最少为 半数+1
注意：清空data和logs数据
192.168.14.12:9200/_cat/nodes?v
3.2、安装head插件
l 下载head插件
wget https://github.com/mobz/elasticsearch-head/archive/elasticsearch-head-master.zip
也可以用git下载，前提yum install git
unzip elasticsearch-head-master.zip
l 安装node.js
wget https://npm.taobao.org/mirrors/node/latest-v4.x/node-v4.4.7-linux-x64.tar.gz
tar -zxvf node-v9.9.0-linux-x64.tar.gz
l 添加node.js到环境变量
source /etc/profile
l 测试
node -v
npm -v
l 安装grunt（grunt是一个很方便的构建工具，可以进行打包压缩、测试、执行等等的工作）
进入到elasticsearch-head-master
npm install -g grunt-cli
npm install
(npm install -g cnpm --registry=https://registry.npm.taobao.org)
l 修改Elasticsearch配置文件
编辑elasticsearch-6.3.1/config/elasticsearch.yml,加入以下内容：
http.cors.enabled: true
http.cors.allow-origin: "*"
打开elasticsearch-head-master/Gruntfile.js，找到下面connect属性，新增hostname:’*’:
connect: {
server: {
options: {
hostname: '*',
port: 9100,
base: '.',
keepalive: true
}
}
}
l 启动elasticsearch-head
进入elasticsearch-head目录，执行命令：grunt server
nohup grunt server &exit
l 关闭head插件
ps -aux|grep head
kill 进程号
3.3、集群简介
一个节点(node)就是一个Elasticsearch实例，而一个集群(cluster)由一个或多个节点组成，它们具有相同的cluster.name，它们协同工作，分享数据和负载。
当加入新的节点或者删除一个节点时，集群就会感知到并平衡数据（同步）。
3.3.1、集群节点
1、集群中一个节点会被选举为主节点(master)
2、主节点临时管理集群级别的一些变更，例如新建或删除索引、增加或移除节点等。
3、主节点不参与文档级别的变更或搜索，这意味着在流量增长的时候，该主节点不会成为集群的瓶颈。
4、任何节点都可以成为主节点。
5、用户，我们能够与集群中的任何节点通信，包括主节点。
6、每一个节点都知道文档存在于哪个节点上，它们可以转发请求到相应的节点上。
7、我们访问的节点负责收集各节点返回的数据，最后一起返回给客户端。这一切都由Elasticsearch处理。
3.3.2、集群健康
在Elasticsearch集群中可以监控统计很多信息，但是只有一个是最重要的：集群健康(cluster health)。集群健康有三种状态：green、yellow或red。
在一个没有索引的空集群中运行如上查询，将返回这些信息：
GET /_cluster/health
{
"cluster_name": "elasticsearch",
"status": "green",
"timed_out": false,
"number_of_nodes": 1,
"number_of_data_nodes": 1,
"active_primary_shards": 0,
"active_shards": 0,
"relocating_shards": 0,
"initializing_shards": 0,
"unassigned_shards": 0
}
status字段提供一个综合的指标来表示集群的的服务状况。三种颜色各自的含义：
颜色 | 意义 |
green | 所有主要分片和复制分片都可用 |
yellow | 所有主要分片可用，但不是所有复制分片都可用 |
red | 不是所有的主要分片都可用 |
3.3.3、集群分片
索引只是一个用来指向一个或多个分片(shards)的“逻辑命名空间(logical namespace)”.
分片(shard)是一个最小级别“工作单元(worker unit)”,它只是保存了索引中所有数据的一部分，是一个Lucene实例，并且它本身就是一个完整的搜索引擎。我们的文档存储在分片中，并且在分片中被索引，但是我们的应用程序不会直接与它们通信，取而代之的是，直接与索引通信。
分片是Elasticsearch在集群中分发数据的关键。把分片想象成数据的容器。文档存储在分片中，然后分片分配到你集群中的节点上。当你的集群扩容或缩小，Elasticsearch将会自动在你的节点间迁移分片，以使集群保持平衡。
1、主分片
索引中的每个文档属于一个单独的主分片，所以主分片的数量决定了索引最多能存储多少数据。
理论上主分片能存储的数据大小是没有限制的，限制取决于你实际的使用情况。分片的最大容量完全取决于你的使用状况：硬件存储的大小、文档的大小和复杂度、如何索引和查询你的文档，以及你期望的响应时间。
2、副分片
复制分片只是主分片的一个副本，它可以防止硬件故障导致的数据丢失，同时可以提供读请求，比如搜索或者从别的shard取回文档。
当索引创建完成的时候，主分片的数量就固定了，但是复制分片的数量可以随时调整。
创建分片：
PUT /blogs
{
"settings" : {
"number_of_shards" : 3,
"number_of_replicas" : 1
}
}
增加副分片：
PUT /blogs/_settings
{
"number_of_replicas" : 2
}
主分片设置后不能进行修改，只能修改副本分片
集群的健康状态yellow表示所有的主分片(primary shards)启动并且正常运行了——集群已经可以正常处理任何请求——但是复制分片(replica shards)还没有全部可用。事实上所有的三个复制分片现在都是unassigned状态——它们还未被分配给节点。在同一个节点上保存相同的数据副本是没有必要的，如果这个节点故障了，那所有的数据副本也会丢失。
3.3.4、故障转移
在单一节点上运行意味着有单点故障的风险——没有数据备份。幸运的是，要防止单点故障，我们唯一需要做的就是启动另一个节点。
第二个节点已经加入集群，三个复制分片(replica shards)也已经被分配了——分别对应三个主分片，这意味着在丢失任意一个节点的情况下依旧可以保证数据的完整性。
文档的索引将首先被存储在主分片中，然后并发复制到对应的复制节点上。这可以确保我们的数据在主节点和复制节点上都可以被检索。
3.4、集群操作原理
3.4.1、路由
当你索引一个文档，它被存储在单独一个主分片上。Elasticsearch是如何知道文档属于哪个分片的呢？当你创建一个新文档，它是如何知道是应该存储在分片1还是分片2上的呢？
进程不能是随机的，因为我们将来要检索文档。
算法决定：
shard = hash(routing) % number_of_primary_shards
routing值是一个任意字符串，它默认是_id但也可以自定义。
为什么主分片的数量只能在创建索引时定义且不能修改？
如果主分片的数量在未来改变了，所有先前的路由值就失效了，文档也就永远找不到了。
所有的文档API（get、index、delete、bulk、update、mget）都接收一个routing参数，它用来自定义文档到分片的映射。自定义路由值可以确保所有相关文档——例如属于同一个人的文档——被保存在同一分片上。
3.4.2、操作数据节点工作流程
每个节点都有能力处理任意请求。每个节点都知道任意文档所在的节点，所以也可以将请求转发到需要的节点。
新建、索引和删除请求都是写(write)操作，它们必须在主分片上成功完成才能复制到相关的复制分片上。
1. 客户端给Node 1发送新建、索引或删除请求。
2. 节点使用文档的_id确定文档属于分片0。它转发请求到Node 3，分片0位于这个节点上。
3. Node 3在主分片上执行请求，如果成功，它转发请求到相应的位于Node 1和Node 2的复制节点上。当所有的复制节点报告成功，Node 3报告成功到请求的节点，请求的节点再报告给客户端。
replication
复制默认的值是sync。这将导致主分片得到复制分片的成功响应后才返回。
如果你设置replication为async，请求在主分片上被执行后就会返回给客户端。它依旧会转发请求给复制节点，但你将不知道复制节点成功与否。
上面的这个选项不建议使用。默认的sync复制允许Elasticsearch强制反馈传输。async复制可能会因为在不等待其它分片就绪的情况下发送过多的请求而使Elasticsearch过载。
3.4.3、检索流程
文档能够从主分片或任意一个复制分片被检索。
1. 客户端给Node 1发送get请求。
2. 节点使用文档的_id确定文档属于分片0。分片0对应的复制分片在三个节点上都有。此时，它转发请求到Node 2。
3. Node 2返回文档(document)给Node 1然后返回给客户端。
对于读请求，为了平衡负载，请求节点会为每个请求选择不同的分片——它会循环所有分片副本。
可能的情况是，一个被索引的文档已经存在于主分片上却还没来得及同步到复制分片上。这时复制分片会报告文档未找到，主分片会成功返回文档。一旦索引请求成功返回给用户，文档则在主分片和复制分片都是可用的。