elasticseach日常维护之shard管理

转自我自己的博客:http://zhaoyanblog.com/archives/687.html

elasticseach的数据分片shard,在创建索引之后,在生命周期内就不可改变了,所以在索引开始创建的时候,要根据预估的数据规模合理的设置shard数目。在集群中让shard分布均匀,可以有效的均衡集群负载,所以我们要尽量保证shard的在集群中分布均匀。

每个shard都有自己的编号,从1往后数。你可以通过

curl -XGET ‘http://192.168.1.1:9200/_cat/shards’

来查看shard分布情况:

index_1 100 p STARTED 44217999 12.3gb 192.168.1.1 Strongarm

index_1 100 r STARTED 44217999 12.3gb 192.168.1.2 Agony

index_1 109 p STARTED 39394176 10.7gb 192.168.1.3 Captain America

index_1 109 r STARTED 39394176 10.6gb 192.168.1.1 Smuggler

index_1 103 p STARTED 42910705 11.9gb 192.168.1.2 Alyssa Moy

index_1 103 r STARTED 42910716 11.9gb 192.168.1.1 Chi Demon

index_1 169 r STARTED 40889958 11.4gb 192.168.1.2 Milos Masaryk

index_1 169 p STARTED 40889958 11.3gb 192.168.1.1 Sergeant Fury

index_1 55 r STARTED 44243841 12.2gb 192.168.1.3 Milos Masaryk

index_1 55 p STARTED 44243841 12.1gb 192.168.1.3 Whiteout

index_1 214 r STARTED 43512570 12gb 192.168.1.1 Mekano

index_1 214 p STARTED 43512570 12gb 192.168.1.2 Sergeant Fury

index_1 97 r STARTED 45660486 12.7gb 192.168.1.1 Pathway

index_1 97 p STARTED 45660486 12.7gb 192.168.1.2 Mekano

p 就表示是主分片 primary shard

r 就表示是副本分片 replica shard

分片数和副本个数在创建索引的时候都可以设置,副本的个数在创建索引之后可以随时更改。

elasticsearch的shard分布是根据集群设置的比重进行分配的,你可以设置:

curl -XPUT ‘http://192.168.1.1:9200/_cluster/settings?pretty=true’ -d ‘{

“transient” : {

“cluster.routing.allocation.balance.shard” : 0.33

“cluster.routing.allocation.balance.index” : 0.33

“cluster.routing.allocation.balance.primary” : 0.34

“cluster.routing.allocation.balance.threshold” : 1

}

}’

elasticsearch内部计算公式是:

weightindex(node, index) = indexBalance * (node.numShards(index) – avgShardsPerNode(index))

weightnode(node, index) = shardBalance * (node.numShards() – avgShardsPerNode)

weightprimary(node, index) = primaryBalance * (node.numPrimaries() – avgPrimariesPerNode)

weight(node, index) = weightindex(node, index) + weightnode(node, index) + weightprimary(node, index)

如果计算最后的weight(node, index)大于threshold, 就会发生shard迁移。

注:cluster.routing.allocation.balance.primary 在1.3.8版本之后被废弃了。

在一个已经创立的集群里,shard的分布总是均匀的。但是当你扩容节点的时候,你会发现,它总是先移动replica shard到新节点。

这样就导致新节点全部分布的全是副本,主shard几乎全留在了老的节点上。

cluster.routing.allocation.balance参数,比较难找到合适的比例。

建议一种方式是在扩容的时候,设置cluster.routing.allocation.enable=primaries。指只允许移动主shard。

当你发现shard数已经迁移了一半的时候,改回cluster.routing.allocation.enable=all。这样后面的全迁移的是副本shard。

扩容之后,shard和主shard的分布还是均匀的。

curl -XPUT ‘http://192.168.1.1:9200/_cluster/settings’ -d ‘{

“transient” : {

“cluster.routing.allocation.enable” : “primaries”

}

}’

那如果shard分布已经不均匀了,也可以手动进行shard迁移。

curl -XPOST ‘http://192.168.1.1:9200/_cluster/reroute’ -d ‘{

“commands” : [ {

“move” :

{

“index” : “index_1″, “shard” : 23,

“from_node” : “192.168.1.1”, “to_node” : “192.168.1.2”

}

}

]

}’

时间: 2024-11-10 17:28:25

elasticseach日常维护之shard管理的相关文章

Oracle 表空间的日常维护与管理

目录 Oracle 表空间的日常维护与管理 1.创建数据表空间 2.创建临时表空间 3.创建 UNDO 表空间 4.表空间的扩展与修改大小 5.表空间重命名 6.表空间的删除 7.更改表空间的读写模式 8.更改表空间的在线模式 Oracle 表空间的日常维护与管理 1.创建数据表空间 查询有关表和视图:[使用版本Oracle 11gR2] 1.查看表空间信息 dba_tablespaces v$tablespace 2.查看数据文件 dba_data_files v$datafile 3.查看临

MHA 日常维护命令集

MHA 日常维护命令集 1.查看ssh登陆是否成功 masterha_check_ssh --global_conf=/etc/masterha/masterha_default.conf --conf=/etc/masterha/app1.conf 2.查看复制是否建立好 masterha_check_repl --global_conf=/etc/masterha/masterha_default.conf --conf=/etc/masterha/app1.conf 3.启动mha noh

mha日常维护命令

mha日常维护命令 http://m.blog.chinaunix.net/uid-28437434-id-3959021.html?/13033.shtml 1.查看ssh登陆是否成功masterha_check_ssh --conf=/etc/masterha/app1.cnf 2.查看复制是否建立好masterha_check_repl --conf=/etc/masterha/app1.cnf 3.启动mhanohup masterha_manager --conf=/etc/maste

第三篇——第二部分——第五文 配置SQL Server镜像——域环境SQL Server镜像日常维护

本文接上面两篇搭建镜像的文章: 第三篇--第二部分--第三文 配置SQL Server镜像--域环境:http://blog.csdn.net/dba_huangzj/article/details/28904503第三篇--第二部分--第四文 配置SQL Server镜像--非域环境:http://blog.csdn.net/dba_huangzj/article/details/27652857 在搭建的过程中,可能你会遇到比较多的问题,下面介绍一些常见的问题及解决方案,另外把主要精力放到对

DBA日常维护SQL整理(原创)

database 概况信息检查 # 检查 database 基本信息 select * from v$version; select name ,open_mode,log_mode from v$database; select instance_number,instance_name ,status from gv$instance; show parameter cpu_count show parameter block_size select group#,thread#,membe

人脸识別终端日常维护

人脸识別终端日常维护 日常保养目的: 隨著人臉識別成功導入之后,經歷了一段時間之后,有的當初推行人員和維護人員可能已經離職,人臉識別系統和人臉設備可能由當初高層管理高度重視而漸漸來再關注,從而導致導入之初相關制度得不到真正落實,執行力大打折扣.人臉設注無人保養.于是機器日常維護又成為管理課題.好的設備需要有一整套保養制度,并透過HR系統反應出實際設備管理狀況.按ITSM理論,將被動救火變為主動保養. 日常保养项目: 電源.網絡.機器清潔管理.相關標志(SOP.責任書.排隊標志)定期更換.機器資料

DB2日常维护——REORG TABLE命令优化数据库性能

[转]DB2日常维护——REORG TABLE命令优化数据库性能 一个完整的日常维护规范可以帮助 DBA 理顺每天需要的操作,以便更好的监控和维护数据库,保证数据库的正常.安全.高效运行,防止一些错误重复发生. 由于DB2使用CBO作为数据库的优化器,数据库对象的状态信息对数据库使用合理的 ACCESS PLAN至关重要.DB2 优化器使用目录统计信息来确定任何给定查询的最佳访问方案.如果有关表或索引的统计信息已过时或者不完整,则会导致优化器选择不是最佳的方案,并且会降低 执行查询的速度.当数据

MongoDB之基本操作与日常维护

MongoDB基本操作 MongoDB的基本操作主要是对数据库.集合.文档的操作,包括创建数据库.删除数据库.插入文档.更改文档.删除文档.和查询文档. 操作 描述 show dbs 查看当前实例下的数据库列表 show users 显示用户 use <db_name> 切换当前数据库 db.help() 显示数据库操作命令 show.collections 显示当前数据库中的集合 db.foo.help() 显示集合操作命令,foo是当前数据库下的集合 db.foo.find() 对当前数据

Hive的配置详解和日常维护

Hive的配置详解和日常维护 一.Hive的参数配置详解 1>.mapred.reduce.tasks  默认为-1.指定Hive作业的reduce task个数,如果保留默认值,则Hive 自己决定应该使用多少个task. 2>.hive.mapred.mode  2.x下的默认值为strict,1.x以及之前的版本默认值为nonstrict.如果 设为strict,Hive将禁止一些危险的查询:分区表未用分区字段筛选: order by语句后未跟limit子句:join后没有on语句从而形