Elasticsearch重要文章之三：重要配置項的修改

Elasticsearch已經有很好的默認值，特別是涉及到性能相關的配置或者選項。若是你有什麼拿不許的，最好就不要動它。咱們已經目擊了數十個由於錯誤的設置而致使集羣毀滅，由於它的管理者總認爲他改動一個配置或者選項就能夠帶來100倍的提高。

注意：請閱讀全文，全部的配置項都同等重要，和描述順序無關，請閱讀全部的配置選項，並應用到你的集羣中。

其它數據庫可能須要調優，但總得來講，Elasticsearch不須要。若是你遇到了性能問題，最好的解決方法一般是更好的數據佈局或者更多的節點。在Elasticsearch中有不多的」神奇的配置項」，若是存在，咱們也已經幫你優化了。

指定名字

Elasticsearch默認啓動的集羣名字叫elasticsearch，你最好給你的生產環境的集羣改個名字，更名字的目的很簡單，就是防止某我的的筆記本加入到了集羣，形成意外。簡單修改爲elasticsearch_production ，會省掉屢次心痛~。
你能夠在你的elasticsearch.yml中修改：
cluster.name: elasticsearch_production

一樣，修改節點的名字也是明智的，就像你如今可能發現的那樣，Elasticsearch會在你的節點啓動的時候隨機給它指定一個名字。這在你開發的時候可能以爲很萌，可是當凌晨3點鐘，你還在嘗試會議哪臺物理機是Tagak the Leopard Lord.的時候，你就不以爲萌了。

更重要的是，這些名師是在啓動的時候產生的，每次啓動節點，它都會獲得一個新的名字，這可使日誌混淆，由於全部節點的名稱都是不斷變化的。
這些可能性都是很無聊的，咱們建議你給每一個及誒點一個有意義的名字-一個清楚的，描述性的名字，一樣你能夠在elasticsearch.yml中配置：
node.name: elasticsearch_005_data

路徑

默認狀況下，Eleasticsearch會把插件、日誌以及你最重要的數據放在安裝目錄下。這會帶來不幸的事故。即若是你從新安裝Elasticsearch的時候就可能不當心把安裝目錄覆蓋了，若是你不當心，你就可能把你的所有數據刪掉了。

不要笑，這種狀況，咱們見過不少次了。

最好的選擇就是把你的數據目錄配置到安裝目錄之外的地方，一樣你也能夠選擇轉移你的插件和日誌目錄。

能夠更改以下：
path.data: /path/to/data1,/path/to/data2

# Path to log files:
path.logs: /path/to/logs

# Path to where plugins are installed:
path.plugins: /path/to/plugins

注意：你能夠經過逗號分隔指定多個目錄。

數據能夠保存到多個不一樣的目錄，每一個目錄若是是掛載在不一樣的硬盤，作一我的RAID 0是一個簡單而有效的方式。Elasticsearch會自動把數據分隔到不一樣的目錄，以便提升性能。

最小主節點數

minimum_master_nodes的設定對你的集羣的穩定及其重要，當你的集羣中有兩個masters的時候，這個配置有助於防止集羣分裂。

若是你發生了一個集羣分裂，你集羣就會處在丟失數據的危險中，由於master節點是被認爲是這個集羣的最高統治者，它決定了何時新的索引能夠建立，多少分片要移動等等。若是你有兩個master節點，你的數據的完整性將得不到保證，由於你有兩個master節點認爲他們有集羣的控制權。

這個配置就是告訴Elasticsearch當沒有足夠master候選節點的時候，就不要進行master選舉，等master候選節點足夠了才進行選舉。

該配置必須應該配置成master候選節點的法定個數(大多數個),法定個數就是（master候選節點個數*2)+1. 這裏有幾個例子：
*若是你有10個節點（能保存數據，同時能成爲master） 法定數就是6
*若是你有3個候選master，和100個數據節點，法定數就是2，你只要數數那些能夠作master的節點數就能夠了。
*若是你有兩個節點，你遇到難題了，法定數固然是2，可是這意味着若是有一個節點掛掉，你整個集羣就不可用了。設置成1能夠保證集羣的功能，可是就沒法保證集羣分裂了，想這樣的狀況，你最好至少保證有3個節點。

elasticsearch.yml中這樣配置：
discovery.zen.minimum_master_nodes: 2

可是因爲ELasticsearch是動態的，你能夠很容易的添加和刪除節點，這會改變這個法定個數，若是你不得不修改索引的節點的配置而且重啓你的整個集羣爲了讓配置生效，這將是很是痛苦的一件事情。
基於這個緣由，minimum_master_nodes （還有一些其它配置），容許經過API調用的方式動態進行配置，當你的集羣在線運行的時候，你能夠這樣修改配置：
PUT /_cluster/settings
{
「persistent」 : {
「discovery.zen.minimum_master_nodes」 : 2
}
}

這將成爲一個永久的配置，而且不管你配置項裏配置的如何，這個將優先生效。當你添加和刪除master節點的時候，你須要更改這個配置。

集羣恢復方面的配置項

當你集羣重啓時，幾個配置項影響你的分片恢復的表現。首先，咱們必須明白，若是什麼也沒配置將會發生什麼。

想象一下假設你有10個節點，每一個節點保存一個分片，主分片或者副分片，也就是有一個有5個主分片/1個副本 的索引。你須要中止整個集羣進行休整（舉個例子，爲了安裝一個新的驅動程序）。當你重啓你的集羣，很天然會出現5個節點已經起動了，還有5個還沒啓動的場景。

假設其它五個節點出問題，或者他們根本沒有收到當即重啓的命令。不管什麼緣由，你只要五個節點在線上。這五個節點會相互通訊，選出一個master，從而造成一個集羣，他們注意到數據再也不均勻分佈，由於有個節點在集羣中丟失了，他們之間會立馬啓動分片複製。

最後，你的其它5個節點打開加入了集羣，這些節點會發現他們的數據已經成爲其它節點的副本了，因此他們刪除本地數據（由於這份數據要麼是多餘的，要麼是過期的）。而後整個集羣從新進行平衡，由於集羣的大小已經從5變成了10。

在整個過程當中，你的節點會消耗磁盤和網盤，來回移動數據，由於沒有更好的理由。對於有上T數據的大集羣，這種數據的傳輸須要很長時間。若是等待全部的節點重啓好了，整個集羣再上線，全部的本地的數據都不須要移動。

如今咱們知道問題的所在了，咱們能夠修改一個小配置就能夠緩解這個事情，首先咱們要給ELasticsearch一個嚴格的限制：
gateway.recover_after_nodes: 8

這將放置Elasticsearch進行數據恢復，在發現8個節點（數據節點或者master節點）以前。這個值的設定取決於我的喜愛: 整個集羣提供服務以前你但願有多少個節點在線？咱們設置爲8， 這意味着至少要有8個節點，該集羣纔可用。

如今咱們要告訴Ealsticsearch集羣中應該有多少個節點，而且咱們但願集羣須要多久等待全部節點：

gateway.expected_nodes: 10
gateway.recover_after_time: 5m

這意味着Elasticsearch會採起以下操做：
*至少等待8個節點上線
*等待5分鐘，或者10個節點上線後，才進行數據恢復，這取決於哪一個條件先達到。

這三個設置能夠在集羣重啓的時候避免過多的分片交換。這可能會讓數據恢復從數個小時縮短爲幾秒鐘。
這些配置只能設置在config/elasticsearch.yml文件中，或者是在命令行裏（這些配置是沒法東塔修改的），它們只在整個集羣重啓的時候有實質性做用。

最好使用單播代替組播

Elasticsearch默認是被配置成使用多播發現節點。多播就是經過在你的網絡中發送UDP的ping請求以發現節點，其它Elasticsearch會收到這些ping請求而且進行響應，這樣隨後就會造成一個集羣。
多播對於開發環境是很好的，你不須要作什麼事情，打開一些節點，他們天然的會發現對方造成一個集羣。
正是由於這種易用性，你在生產環境中必須禁掉它。否在你獲得的結果就是一個節點意外的加入到了你的生產環境，由於他們收到了一個錯誤的組播信號。對於組播自己並無錯。組播會致使一些愚蠢的問題，而且致使集羣變的脆弱(例如：一個網絡工程師正在搗鼓網絡，而沒有告訴你，你會發現全部的節點忽然發現不了對方了）。

在生產環境中，建議使用單播代替組播，也就是說爲Elasticsearch提供一些它應該去嘗試鏈接的節點列表。一旦這個節點聯繫到組播列表中的一員，它就會獲得整個集羣全部節點的狀態，而後它會聯繫master節點，並加入集羣。

這意味着你的單播列表不須要包含你的集羣中的全部節點，它只須要包含足夠一個新節點聯繫上其中一個而且說上話就ok了。若是你使用master候選節點做爲單播列表，你只要列出三個就能夠了。這個配置在elasticsearch.yml文件中：
discovery.zen.ping.multicast.enabled: false
discovery.zen.ping.unicast.hosts: [「host1」, 「host2:port」]

備註：請確認你已經關閉了組播（discovery.zen.ping.multicast.enabled: false），不然它會和單播同時存在。