➜  zed brew services start mysql@5.7
Warning: Calling `brew services'. This command needs to be refactored, as it is written in a style that is deprecated! Use inherits from `Homebrew::AbstractCommand' ( see https://docs.brew.sh/External-Commands ) instead.
Please report this issue to the Homebrew/homebrew-services tap, or even better, submit a PR to fix it:
  /usr/local/Homebrew/Library/Taps/homebrew/homebrew-services/cmd/services.rb:9

Error: uninitialized constant Homebrew::Service
/usr/local/Homebrew/Library/Homebrew/formulary.rb:396:in `block in load_formula_from_api'
/usr/local/Homebrew/Library/Homebrew/formulary.rb:285:in `initialize'
/usr/local/Homebrew/Library/Homebrew/formulary.rb:285:in `new'
/usr/local/Homebrew/Library/Homebrew/formulary.rb:285:in `load_formula_from_api'
/usr/local/Homebrew/Library/Homebrew/formulary.rb:969:in `load_from_api'
/usr/local/Homebrew/Library/Homebrew/formulary.rb:962:in `klass'
/usr/local/Homebrew/Library/Homebrew/formulary.rb:570:in `get_formula'
/usr/local/Homebrew/Library/Homebrew/formulary.rb:1016:in `factory'
/usr/local/Homebrew/Library/Taps/homebrew/homebrew-services/cmd/services.rb:113:in `services'
/usr/local/Homebrew/Library/Homebrew/brew.rb:96:in `public_send'
/usr/local/Homebrew/Library/Homebrew/brew.rb:96:in `<main>'
Do not report this issue: you are running in an unsupported configuration.

解决办法

…

• create 如果文档不存在就创建，但如果文档存在就返回错误
• index 如果文档不存在就创建，如果文档存在就更新
• update 更新一个文档，如果文档不存在就返回错误
• delete 删除一个文档，如果要删除的文档id不存在，就返回错误

查看cpu情况 http://10.15.1.242:9200/_cat/nodes?v=true&s=cpu:desc

查看线程 http://10.15.1.242:9200/_nodes/hot_threads

http://10.15.1.242:9200/_nodes/slave-node-9,master-8/hot_threads

查看cpu情况 http://10.15.1.242:9200/_cat/nodes?v=true&s=cpu:desc 查看线程 http://10.15.1.242:9200/_nodes/hot_threads http://10.15.1.242:9200/_nodes/slave-node-9,master-8/hot_threads

大多数ElasticSearch用户在创建索引时通用会问的一个重要问题是:我需要创建多少个分片?

在本文中, 我将介绍在分片分配时的一些权衡以及不同设置带来的性能影响. 如果想搞清晰你的分片策略以及如何优化,请继续往下阅读.

为什么要考虑分片数

分片分配是个很重要的概念, 很多用户对如何分片都有所疑惑, 当然是为了让分配更合理. 在生产环境中, 随着数据集的增长, 不合理的分配策略可能会给系统的扩展带来严重的问题.

同时, 这方面的文档介绍也非常少. 很多用户只想要明确的答案而不仅仅一个数字范围, 甚至都不关心随意的设置可能带来的问题.

当然,我也有一些答案. 不过先要看看它的定义和描述, 然后通过几个通用的案例来分别给出我们的建议.

分片定义

如果你刚接触ElasticSearch, 那么弄清楚它的几个术语和核心概念是非常必要的.

(如果你已经有ES的相关经验, 可以跳过这部分)

假设ElasticSearch集群的部署结构如下: 通过该图, 记住下面的几个定义:

集群(cluster):由一个或多个节点组成, 并通过集群名称与其他集群进行区分

节点(node):单个ElasticSearch实例. 通常一个节点运行在一个隔离的容器或虚拟机中

索引(index):在ES中, 索引是一组文档的集合

分片(shard):因为ES是个分布式的搜索引擎, 所以索引通常都会分解成不同部分, 而这些分布在不同节点的数据就是分片. ES自动管理和组织分片, 并在必要的时候对分片数据进行再平衡分配, 所以用户基本上不用担心分片的处理细节，一个分片默认最大文档数量是20亿.

副本(replica):ES默认为一个索引创建5个主分片, 并分别为其创建一个副本分片. 也就是说每个索引都由5个主分片成本, 而每个主分片都相应的有一个copy.

对于分布式搜索引擎来说, 分片及副本的分配将是高可用及快速搜索响应的设计核心.主分片与副本都能处理查询请求, 它们的唯一区别在于只有主分片才能处理索引请求.

在上图示例中, 我们的ElasticSearch集群有两个节点, 并使用了默认的分片配置. ES自动把这5个主分片分配到2个节点上, 而它们分别对应的副本则在完全不同的节点上. 对,就这是分布式的概念.

请记住, 索引的number_of_shards参数只对当前索引有效而不是对整个集群生效.对每个索引来讲, 该参数定义了当前索引的主分片数(而不是集群中所有的主分片数).

关于副本

本文中不会对ElasticSearch的副本做详细阐述. 如果想单独了解可参考这篇文章.

副本对搜索性能非常重要, 同时用户也可在任何时候添加或删除副本. 正如另篇文章所述, 额外的副本能给你带来更大的容量, 更高的呑吐能力及更强的故障恢复能力.

谨慎分配你的分片

当在ElasticSearch集群中配置好你的索引后, 你要明白在集群运行中你无法调整分片设置. 既便以后你发现需要调整分片数量, 你也只能新建创建并对数据进行重新索引(reindex)(虽然reindex会比较耗时, 但至少能保证你不会停机).

主分片的配置与硬盘分区很类似, 在对一块空的硬盘空间进行分区时, 会要求用户先进行数据备份, 然后配置新的分区, 最后把数据写到新的分区上.

…