參看網址：

Elasticsearch 已經有了 很好 的預設值， 特別是涉及到效能相關的配置或者選項。 如果你有疑問，最好就不要動它。我們已經目睹了數十個因為錯誤的設定而導致毀滅的叢集， 因為它的管理者總認為改動一個配置或者選項就可以帶來 100 倍的提升。

其它資料庫可能需要調優，但總得來說，Elasticsearch 不需要。 如果你遇到了效能問題，解決方法通常是更好的資料佈局或者更多的節點。 在 Elasticsearch 中很少有“神奇的配置項”， 如果存在，我們也已經幫你優化了！

另外，有些 邏輯上的 配置在生產環境中是應該調整的。 這些調整可能會讓你的工作更加輕鬆。

需要更改的配置如下：

指定名字

Elasticsearch 預設啟動的叢集名字叫 elasticsearch 。 你最好給你的生產環境的叢集改個名字，改名字的目的很簡單， 就是防止某人的膝上型電腦加入了叢集這種意外。簡單修改成 elasticsearch_production 會很省心。

你可以在你的 elasticsearch.yml 檔案中修改：

cluster.name: elasticsearch_production

同樣，最好也修改你的節點名字。就像你現在可能發現的那樣， Elasticsearch 會在你的節點啟動的時候隨機給它指定一個名字。你可能會覺得這很有趣，但是當凌晨 3 點鐘的時候， 你還在嘗試回憶哪臺物理機是

更重要的是，這些名字是在啟動的時候產生的，每次啟動節點， 它都會得到一個新的名字。這會使日誌變得很混亂，因為所有節點的名稱都是不斷變化的。

這可能會讓你覺得厭煩，我們建議給每個節點設定一個有意義的、清楚的、描述性的名字，同樣你可以在 elasticsearch.yml 中配置：

node.name: elasticsearch_005_data

路徑編輯

預設情況下， Elasticsearch 會把外掛、日誌以及你最重要的資料放在安裝目錄下。這會帶來不幸的事故， 如果你重新安裝 Elasticsearch 的時候不小心把安裝目錄覆蓋了。如果你不小心，你就可能把你的全部資料刪掉了。

不要笑，這種情況，我們見過很多次了。

最好的選擇就是把你的資料目錄配置到安裝目錄以外的地方， 同樣你也可以選擇轉移你的外掛和日誌目錄。

可以更改如下：

path.data: /path/to/data

# Path to log files:

path.logs: /path/to/logs

# Path to where plugins are installed:

path.plugins: /path/to/plugins

最小主節點數

minimum_master_nodes 設定對你的叢集的穩定 極其 重要。

當你的叢集中有兩個或多個可以成為 master的節點的時候，這個配置有助於防止 腦裂 。

如果你的叢集發生了腦裂，那麼你的叢集就會處在丟失資料的危險中，因為主節點被認為是這個叢集的最高統治者，它決定了什麼時候新的索引可以建立，分片是如何移動的等等。

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

此設定應該始終被配置為 master 候選節點的法定個數（大多數個）。法定個數就是 ( master 候選節點個數 / 2) + 1 。 這裡有幾個例子：

如果你有 10 個節點（能儲存資料，同時能成為 master），法定數就是 6 。

如果你有 3 個候選 master 節點，和 100 個 data 節點，法定數就是 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 個還沒啟動的場景。

假設其它 5 個節點出問題，或者他們根本沒有收到立即重啟的命令。不管什麼原因，你有 5 個節點在線上，這五個節點會相互通訊，選出一個 master，從而形成一個叢集。 他們注意到資料不再均勻分佈，因為有 5 個節點在叢集中丟失了，所以他們之間會立即啟動分片複製。

最後，你的其它 5 個節點開啟加入了叢集。這些節點會發現 它們 的資料正在被複制到其他節點，所以他們刪除本地資料（因為這份資料要麼是多餘的，要麼是過時的）。 然後整個叢集重新進行平衡，因為叢集的大小已經從 5 變成了 10。

在整個過程中，你的節點會消耗磁碟和網路頻寬，來回移動資料，因為沒有更好的辦法。對於有 TB 資料的大叢集, 這種無用的資料傳輸需要 很長時間 。如果等待所有的節點重啟好了，整個叢集再上線，所有的本地的資料都不需要移動。

現在我們知道問題的所在了，我們可以修改一些設定來緩解它。 首先我們要給 ELasticsearch 一個嚴格的限制：

gateway.recover_after_nodes: 8

這將阻止 Elasticsearch 在存在至少 8 個節點（資料節點或者 master 節點）之前進行資料恢復。 這個值的設定取決於個人喜好：整個叢集提供服務之前你希望有多少個節點線上？這種情況下，我們設定為 8，這意味著至少要有 8 個節點，該叢集才可用。

現在我們要告訴 Elasticsearch 叢集中 應該 有多少個節點，以及我們願意為這些節點等待多長時間：

gateway.expected_nodes: 10

gateway.recover_after_time: 5m

這意味著 Elasticsearch 會採取如下操作：

等待叢集至少存在 8 個節點

等待 5 分鐘，或者10 個節點上線後，才進行資料恢復，這取決於哪個條件先達到。

這三個設定可以在叢集重啟的時候避免過多的分片交換。這可能會讓資料恢復從數個小時縮短為幾秒鐘。

注意：這些配置只能設定在 config/elasticsearch.yml 檔案中或者是在命令列裡（它們不能動態更新）它們只在整個叢集重啟的時候有實質性作用。

最好使用單播代替組播

Elasticsearch 預設被配置為使用單播發現，以防止節點無意中加入叢集。只有在同一臺機器上執行的節點才會自動組成叢集。

雖然組播仍然 作為外掛提供， 但它應該永遠不被使用在生產環境了，否在你得到的結果就是一個節點意外的加入到了你的生產環境，僅僅是因為他們收到了一個錯誤的組播訊號。 對於組播 本身 並沒有錯，組播會導致一些愚蠢的問題，並且導致叢集變的脆弱（比如，一個網路工程師正在搗鼓網路，而沒有告訴你，你會發現所有的節點突然發現不了對方了）。

使用單播，你可以為 Elasticsearch 提供一些它應該去嘗試連線的節點列表。 當一個節點聯絡到單播列表中的成員時，它就會得到整個叢集所有節點的狀態，然後它會聯絡 master 節點，並加入叢集。

這意味著你的單播列表不需要包含你的叢集中的所有節點， 它只是需要足夠的節點，當一個新節點聯絡上其中一個並且說上話就可以了。如果你使用 master 候選節點作為單播列表，你只要列出三個就可以了。 這個配置在 elasticsearch.yml 檔案中：

discovery.zen.ping.unicast.hosts: ["host1", "host2:port"]