天津地产网站建设,网站description,安徽省城乡建设网站,管理课程培训视频教程全集在今天的文章中#xff0c;我们应该学习如何管理我们的集群。 备份和分片分配是我们应该能够执行的基本任务。 分片分配过滤
Elasticsearch 将索引配到一个或多个分片中#xff0c;我们可以将这些分片保存在特定的集群节点中。 例如#xff0c;假设你有多个数据集群节点我们应该学习如何管理我们的集群。 备份和分片分配是我们应该能够执行的基本任务。 分片分配过滤
Elasticsearch 将索引配到一个或多个分片中我们可以将这些分片保存在特定的集群节点中。 例如假设你有多个数据集群节点其中两个具有 SSD 存储。 如果我们正在寻找对我们的一个索引的快速响应我们可以将它们的分片配置为仅进入 SSD 数据节点。 这个概念称为分片分配过滤。 我们可以根据一组给定的要求将索引的分片分配给特定的节点。更多的细节可以阅读之前的文章 “Elasticsearch运用 shard 过滤器来控制索引分配给哪个节点”。
为了执行分片分配我们需要为每个节点指定属性。 每次启动节点时我们都会这样做
./bin/elasticsearch -Enode.attr.sizemedium -Enode.attr.diskssd
或者在 elasticsearch.yml 配置文件中指定这些属性
node.attr.size: medium
node.attr.disk: ssd
然后我们可以指定我们选择的索引 twitter 保存在具有 SSD 属性和大小中等的数据节点上
PUT twitter/_settings
{index.routing.allocation.require.size: medium,index.routing.allocation.require.disk: ssd
} 分片分配感知
此外执行这些操作的另一种可能性是使用分片分配感知。 我们可以让 Elasticsearch 将我们的物理硬件配置考虑在内。更多阅读请参考文章 “Elasticsearchshard 分配感知”。
例如我们可以指定集群的每个节点运行的机架
./bin/elasticsearch -Enode.attr.rack_idrack_one
或者使用 elasticsearch.yml
node.attr.rack_id: rack_one
然后我们需要在主节点中指定我们将使用 rack_id 作为属性
cluster.routing.allocation.awareness.attributes: rack_id
稍后如果我们添加新节点并指定不同的 rack_id例如 rack_two因为它们位于不同的机架中。 Elasticsearch 会将分片移动到新节点确保如果可能两个副本不会存储在同一个机架中。 这样我们就可以防止在同一位置分配特定分片的多个副本。一旦有一个机架发生故障那么我们的数据至少还是完整的。 强迫感知force awareness
可能是一个机架出现故障然后你可能没有足够的资源来仅在一个机架中托管主分片和副本分片。 为了防止在发生故障时过载我们可以使强迫感知。 我们可以指定仅当至少有两个机架都可用时才分配副本。 为此我们需要在我们的主节点中指定我们将使用 rack_id 作为属性并强制使用 rack_id 值。
cluster.routing.allocation.awareness.attributes: rack_id
cluster.routing.allocation.awareness.force.rack_id.values: rack_one,rack_two
更多阅读Elasticsearch为自管的 Elasticsearch 添加分片分配感知。 集群的健康
我们的集群有几种可能的健康状态绿色、黄色或红色。 这些健康颜色会根据分片分配而变化红色状态表示特定分片未分配黄色表示主分片已分配但副本未分配绿色表示所有分片均已分配。可以使用 Cluster Health API 检索集群健康状况
GET _cluster/health
此外我们可以检查单个索引及其分片的健康状况
GET /_cluster/health/twitter
GET /_cluster/health/twitter?levelshards
如果我们正在处理黄色或红色状态的集群我们可以使用集群分配解释 API 检查原因
GET /_cluster/allocation/explain
如前所述状态与分片分配相关联。 例如我们可以检查副本分片的状态“primary”: false一个索引
GET /_cluster/allocation/explain
{ index: twitter, shard: 0, primary: false
}
为了解决健康问题我们可能需要添加新的数据节点或更改索引的分配规则。 在此示例中我正在配置 twitter 索引指定其主分片不能保留在名为 “data-node1”的节点上。 该节点将仅用于副本分片。
PUT /twitter/_settings
{ index.routing.allocation.exclude._name: data-node1
} 备份还原
人们可以认为备份就像复制所有节点的数据目录一样简单。 你不应该以这种方式进行备份因为 elasticsearch 可能会在运行时对其数据进行更改。 为了执行备份elasticsearch 为我们提供了 snapshot API。 你可以拍摄正在运行的索引或整个集群的快照然后将该信息存储在其他地方。
此外快照是增量拍摄的。 每次我们创建索引的快照时elasticsearch 都会避免复制任何因为较早的快照已存储的数据。 因此建议你经常为集群拍摄快照。 注册一个存储库
要保存快照我们需要创建一个存储库。 首先我们需要为每个主节点和数据节点的 elasticsearch.yml 配置文件中的每个存储库指定可能的路径。
path.repo: [/mount/backups, /mount/longterm_backups]
之后我们可以使用名称注册一个存储库
PUT /_snapshot/my_backup
{type: fs,settings: {location: /mount/backups}
}
这也可以从 Kibana 转到管理然后快照和恢复进行配置。 备份集群配置
独立于存储库和未来的快照我们应该始终备份 elasticsearch 配置文件夹其中包括 elasticsearch.yml。 在这种情况下我们可以使用我们的备份工具对该文件夹进行备份。 但是 elasticsearch 安全功能存储在专用索引中。 所以有必要备份 .security 索引。
为了执行操作启用安全功能我们需要将角色 snapshot_user 分配给用户或创建一个具有角色 snapshot_user 的用户。
POST /_security/user/snapshot_user
{password : secret,roles : [ snapshot_user ]
}
然后拍摄 .security 索引的快照
PUT /_snapshot/my_backup/snapshot_1
{indices: .security,include_global_state: true
} 恢复集群的安全配置
成功备份我们的安全配置后我们可以随时恢复它。 只需创建一个具有超级用户角色的新用户
./bin/elasticsearch-users useradd restore_user -p password -r superuser
删除之前的安全数据
curl -u restore_user -X DELETE localhost:9200/.security-*
并使用新用户恢复安全索引
curl -u restore_user -X POST localhost:9200/_snapshot/my_backup/snapshot_1/_restore -H Content-Type: application/json -d{indices: .security-*,include_global_state: true } 备份数据
备份数据的最简单方法是执行快照。 默认情况下快照将复制集群中所有打开和启动的索引
PUT /_snapshot/my_backup/snapshot_1?wait_for_completiontrue
但是我们总是可以只备份一些索引
PUT /_snapshot/my_backup/snapshot_2?wait_for_completiontrue
{indices: index_1,index_2,ignore_unavailable: true,include_global_state: false
}
在执行快照后我们可以检查其状态
GET /_snapshot/my_backup/snapshot_1 恢复快照
最后在成功执行快照后我们可以使用 _restore 并指定快照名称来恢复它。
POST /_snapshot/my_backup/snapshot_1/_restore
无论哪种方式我们都可以恢复一些索引
POST /_snapshot/my_backup/snapshot_1/_restore
{indices: index_1,index_2,ignore_unavailable: true,include_global_state: true,rename_pattern: index_(.),rename_replacement: restored_index_$1
}
或者恢复索引并更改其配置
POST /_snapshot/my_backup/snapshot_1/_restore
{indices: index_1,index_settings: {index.number_of_replicas: 0},ignore_index_settings: [index.refresh_interval]
} 删除快照
类似于索引删除快照需要指定其名称和存储库向 _snapshot API 发送 DELETE 请求
DELETE /_snapshot/my_repository/my_snapshot
更多阅读请参考 ElasticsearchSearchable snapshot - 可搜索的快照 ElasticsearchCluster 备份 Snapshot 及 Restore API Elasticsearch为 snapshot 设置 NFS 共享 ElasticsearchSnapshot 生命周期管理 跨集群搜索
另一个有用的配置是启用跨集群搜索。 为此我们只需要指定每个集群的 IP 地址
PUT _cluster/settings
{persistent: {cluster: {remote: {cluster_one: {seeds: [127.0.0.1:9300]},cluster_two: {seeds: [127.0.0.1:9301]}}}}
}
执行此配置后我们可以在远程集群中搜索并在请求中指定其名称
GET /cluster_one:twitter/_search
{query: {match: {user.id: carloslannister}}
}
或者同时搜索两个集群
GET /cluster_one:twitter,cluster_two:twitter/_search
{query: {match: {user.id: carloslannister}}
}
更多阅读请参阅 Elasticsearch跨集群搜索 Cross-cluster search (CCS) Elasticsearch跨集群搜索 Cross-cluster searchCCS及安全 Elasticsearch如何为 CCR 及 CCS 建立带有安全的集群之间的互信 Elasticsearch如何在不更新证书的情况下为集群之间建立互信
