Elasticsearch參數配置的示例分析

小編給大家分享一下Elasticsearch參數配置的示例分析，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！

Elasticsearch的config文件夾里面有兩個配置文件：elasticsearch.yml和logging.yml，第一個是es的基本配置文件，第二個是日志配置文件，es也是使用log4j來記錄日志的.


cluster.name: gh-cluster
配置es的集群名稱，默認是elasticsearch，在一個集群內，各節點擁有相同的custer.name.


node.name: "gh-cluster-node-01"
節點名，默認隨機指定一個name列表中名字.同一集群中，各節點名稱要保持唯一。


node.master: true
指定該節點是否有資格被選舉成為node，默認是true，es是默認集群中的第一臺機器為master，如果這臺機掛了就會重新選舉master。


node.data: true
指定該節點是否存儲索引數據，默認為true。


index.number_of_shards: 5
設置默認索引分片個數，默認為5片。


index.number_of_replicas: 1
設置默認索引副本個數，默認為1個副本。


path.conf: /path/to/conf（建議修改）
設置配置文件的存儲路徑，默認是es根目錄下的config文件夾。


path.data: /path/to/data（建議修改）
設置索引數據的存儲路徑，默認是es根目錄下的data文件夾，可以設置多個存儲路徑，用逗號隔開，例：
path.data: /path/to/data1,/path/to/data2


path.work: /path/to/work（建議修改）
設置臨時文件的存儲路徑，默認是es根目錄下的work文件夾。


path.logs: /path/to/logs（建議修改）
設置日志文件的存儲路徑，默認是es根目錄下的logs文件夾


path.plugins: /path/to/plugins（建議修改）
設置插件的存放路徑，默認是es根目錄下的plugins文件夾


bootstrap.mlockall: true
設置為true來鎖住內存。因為當jvm開始swapping時es的效率會降低，所以要保證它不swap，可以把ES_MIN_MEM和ES_MAX_MEM兩個環境變量設置成同一個值，并且保證機器有足夠的內存分配給es。同時也要允許elasticsearch的進程可以鎖住內存，linux下可以通過`ulimit -l unlimited`命令。


network.bind_host: 192.168.0.1 （建議改成所在服務器的ip）
設置綁定的ip地址，可以是ipv4或ipv6的，默認為0.0.0.0。




network.publish_host: 192.168.0.1
設置其它節點和該節點交互的ip地址，如果不設置它會自動判斷，值必須是個真實的ip地址。


network.host: 192.168.0.1
這個參數是用來同時設置bind_host和publish_host上面兩個參數。


transport.tcp.port: 9300
設置節點間交互的tcp端口，默認是9300。


transport.tcp.compress: true
設置是否壓縮tcp傳輸時的數據，默認為false，不壓縮。


http.port: 9200
設置對外服務的http端口，默認為9200。


http.max_content_length: 100mb
設置內容的最大容量，默認100mb


http.enabled: false
是否使用http協議對外提供服務，默認為true，開啟。








ES集群可能會有整體重啟的情況，比如需要升級硬件、升級操作系統或者升級ES大版本。重啟所有結點可能帶來的一個問題: 某些結點可能先于其他結點加入集群， 先加入集群的結點可能已經可以選舉好master，并立即啟動了recovery的過程，由于這個時候整個集群數據還不完整，master會指示一些結點之間相互開始復制數據。 那些晚到的結點，一旦發現本地的數據已經被復制到其他結點，則直接刪除掉本地“失效”的數據。 當整個集群恢復完畢后，數據分布不均衡，顯然是不均衡的，master會觸發rebalance過程，將數據在節點之間挪動。整個過程無謂消耗了大量的網絡流量；合理設置recovery相關參數則可以防范這種問題的發生。
gateway.expected_nodes
gateway.expected_master_nodes
gateway.expected_data_nodes
以上三個參數是說集群里一旦有多少個節點就立即開始recovery過程。 不同之處在于，第一個參數指的是master或者data都算在內，而后面兩個參數則分指master和data node。
 
在期待的節點數條件滿足之前, recovery過程會等待gateway.recover_after_time (默認5分鐘) 這么長時間，一旦等待超時，則會根據以下條件判斷是否啟動:
gateway.recover_after_nodes
gateway.recover_after_master_nodes
gateway.recover_after_data_nodes
 
舉例來說，對于一個有10個data node的集群，如果有以下的設置:
gateway.expected_data_nodes: 10
gateway.recover_after_time: 5m
gateway.recover_after_data_nodes: 8
那么集群5分鐘以內10個data node都加入了，或者5分鐘以后8個以上的data node加入了，都會立即啟動recovery過程。








cluster.routing.allocation.cluster_concurrent_rebalance:2
指定用于并發再平衡的分片數。此屬性的設置要取決于硬盤條件，如CPU數量，IO性能等。如果該屬性設置不當，將影響ElasticSearch索引性能




cluster.routing.allocation.node_initial_primaries_recoveries: 4
初始化數據恢復時，并發恢復線程的個數，默認為4。


cluster.routing.allocation.node_concurrent_recoveries: 2
添加刪除節點或負載均衡時并發恢復線程的個數，默認為4。






indices.recovery.max_size_per_sec: 0
設置數據恢復時限制的帶寬，如入100mb，默認為0，即無限制。


indices.recovery.concurrent_streams: 5
設置這個參數來限制從其它分片恢復數據時最大同時打開并發流的個數，默認為5。


discovery.zen.minimum_master_nodes: 1
設置這個參數來保證集群中的節點可以知道其它N個有master資格的節點。默認為1，對于大的集群來說，可以設置大一點的值（2-4）


discovery.zen.ping.timeout: 3s （建議修改）
設置集群中自動發現其它節點時ping連接超時時間，默認為3秒，對于比較差的網絡環境可以高點的值來防止自動發現時出錯。


discovery.zen.ping.multicast.enabled: false
設置是否打開多播發現節點，默認是true。


discovery.zen.ping.unicast.hosts: ["host1", "host2:port", "host3"]
設置集群中master節點的初始列表，可以通過這些節點來自動發現新加入集群的節點。


下面是一些查詢時的慢日志參數設置
index.search.slowlog.level: TRACE
index.search.slowlog.threshold.query.warn: 10s
index.search.slowlog.threshold.query.info: 5s
index.search.slowlog.threshold.query.debug: 2s
index.search.slowlog.threshold.query.trace: 500ms


index.search.slowlog.threshold.fetch.warn: 1s
index.search.slowlog.threshold.fetch.info: 800ms
index.search.slowlog.threshold.fetch.debug:500ms
index.search.slowlog.threshold.fetch.trace: 200ms

以上是“Elasticsearch參數配置的示例分析”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業資訊頻道！