ES集群

1、基本介紹

1.1、為什么需要集群

單臺 Elasticsearch 服務器提供服務，往往都有最大的負載能力，超過這個閾值，服務器性能就會大大降低甚至不可用，所以生產環境中，ES 一般都是運行在指定服務器集群中。

除了負載能力，單點服務器也存在其他問題：

單臺機器存儲容量有限
單服務器容易出現單點故障，無法實現高可用
單服務的并發處理能力有限

配置服務器集群時，集群中節點數量沒有限制，大于等于 2 個節點就可以看做是集群了。一般出于高性能及高可用方面來考慮集群中節點數量都是 3 個以上。

1.2、集群 Cluster

一個集群就是由一個或多個服務器節點組織在一起，共同持有整個的數據，并一起提供索引和搜索功能。一個 Elasticsearch 集群有一個唯一的名字標識，這個名字默認就是”elasticsearch”。這個名字是重要的，因為一個節點只能通過指定某個集群的名字，來加入這個集群。

1.3、節點 Node

集群中包含很多服務器，一般來說，一臺服務器上只部署一個節點（當然實際上一臺服務器上也是可以部署多個節點的）。節點作為集群的一部分，它存儲數據，參與集群的索引和搜索功能。

一個節點也是由一個名字來標識的，默認情況下，這個名字是一個隨機的漫威漫畫角色的名字，這個名字會在啟動的時候賦予節點。這個名字對于管理工作來說挺重要的，因為在這個管理過程中，你會去確定網絡中的哪些服務器對應于 Elasticsearch 集群中的哪些節點。

一個節點可以通過配置集群名稱的方式來加入一個指定的集群。默認情況下，每個節點都會被安排加入到一個叫做“elasticsearch”的集群中，這意味著，如果你在你的網絡中啟動了若干個節點，并假定它們能夠相互發現彼此，它們將會自動地形成并加入到一個叫做“elasticsearch”的集群中。

在一個集群里，只要你想，可以擁有任意多個節點。而且，如果當前你的網絡中沒有運行任何 Elasticsearch 節點，這時啟動一個節點，會默認創建并加入一個叫做“elasticsearch”的集群。

1.4、節點角色

一個節點是邏輯上獨立的ES實例，表現為一個ES進程，它是集群的一部分。節點可分為多種角色，如主節點、數據節點、協調節點等。

1.4.1、主節點

負責集群狀態管理，分片分配管理

1.4.2、數據節點

負責保存數據，執行數據增、刪、改、查等操作。

1.4.3、協調節點

接收客戶端請求，然后轉發這些請求，收集數據并返回給客戶端的節點。

1.5、角色設置原則

當數據節點超過 7 個時，建議數據節點和主節點角色進行分離，部署在不同服務器上
當數據節點不少于 10 個并且集群所有索引單副本的存儲總量超過 5T 時應增加獨立的協調節點，協調節點最少 2 個。

2、window系統部署ES集群

2.1、安裝啟動

下載window版es軟件并解壓，復制三份，如下：

修改集群文件目錄中每個節點的 config/elasticsearch.yml 配置文件

node-1001 節點

#節點 1 的配置信息：
#集群名稱，節點之間要保持一致
cluster.name: my-elasticsearch
#節點名稱，集群內要唯一
node.name: node-1001
node.master: true
node.data: true
#ip 地址
network.host: localhost
#http 端口
http.port: 1001
#tcp 監聽端口
transport.tcp.port: 9301
#discovery.seed_hosts: ["localhost:9301", "localhost:9302","localhost:9303"]
#discovery.zen.fd.ping_timeout: 1m
#discovery.zen.fd.ping_retries: 5
#集群內的可以被選為主節點的節點列表
#cluster.initial_master_nodes: ["node-1", "node-2","node-3"]
#跨域配置
#action.destructive_requires_name: true
http.cors.enabled: true
http.cors.allow-origin: "*"

node-1002 節點

#節點 2 的配置信息：
#集群名稱，節點之間要保持一致
cluster.name: my-elasticsearch
#節點名稱，集群內要唯一
node.name: node-1002
node.master: true
node.data: true
#ip 地址
network.host: localhost
#http 端口
http.port: 1002
#tcp 監聽端口
transport.tcp.port: 9302
discovery.seed_hosts: ["localhost:9301"]
discovery.zen.fd.ping_timeout: 1m
discovery.zen.fd.ping_retries: 5
#集群內的可以被選為主節點的節點列表
#cluster.initial_master_nodes: ["node-1", "node-2","node-3"]
#跨域配置
#action.destructive_requires_name: true
http.cors.enabled: true
http.cors.allow-origin: "*"

node-1003 節點

#節點 3 的配置信息：
#集群名稱，節點之間要保持一致
cluster.name: my-elasticsearch
#節點名稱，集群內要唯一
node.name: node-1003
node.master: true
node.data: true
#ip 地址
network.host: localhost
#http 端口
http.port: 1003
#tcp 監聽端口
transport.tcp.port: 9303
#候選主節點的地址，在開啟服務后可以被選為主節點
discovery.seed_hosts: ["localhost:9301", "localhost:9302"]
discovery.zen.fd.ping_timeout: 1m
discovery.zen.fd.ping_retries: 5
#集群內的可以被選為主節點的節點列表
#cluster.initial_master_nodes: ["node-1", "node-2","node-3"]
#跨域配置
#action.destructive_requires_name: true
http.cors.enabled: true
http.cors.allow-origin: "*"

然后分別啟動 node-1001、node-1002、node-1003 節點，啟動前先刪除每個節點中的 data 目錄中所有內容（如果存在），啟動后，節點會自動加入指定名稱的集群。

2.2、查看集群健康狀態

可通過 get 請求 http://IP:節點端口號/_cluster/health 查看集群狀態，如：http://127.0.0.1:1002/_cluster/health。

當啟動 1、2個節點時輸出分別如下：

status字段指示著當前集群在總體上是否工作正常，它返回的三種顏色含義如下：

green：所有的主分片和副本分片都正常運行。
yellow：所有的主分片都正常運行，但不是所有的副本分片都正常運行。
red：有主分片沒能正常運行。

3、Linux系統部署ES集群

Linux 系統上部署 es 集群跟單節點部署沒什么差別，只是配置文件有點不一樣而已。（ES Linux單機部署參考：http://www.rzrgm.cn/wenxuehai/p/17038600.html#_label2_1）

3.1、安裝啟動

先下載 Linux 的 7.8.0 版本使用。下載地址：https://www.elastic.co/cn/downloads/past-releases/elasticsearch-7-8-0

將下載的軟件放到分別放到兩臺服務中并解壓縮：tar -zxvf elasticsearch-7.8.0-linux-x86_64.tar.gz -C /opt/es-cluster

因為安全問題，Elasticsearch 不允許 root 用戶直接運行，需使用其他用戶啟動 es，這里我們創建新用戶 es。在 root 用戶中創建新用戶如下：

useradd es #新增 es 用戶
passwd es #為 es 用戶設置密碼
userdel -r es #如果錯了，可以刪除再加
chown -R es:es /opt/es-cluster/elasticsearch-7.8.0 #文件夾所有者

修改完目錄所有者后可以看到目錄的擁有者發生了變化，如下：

修改/opt/es-cluster/elasticsearch-7.8.0/config/elasticsearch.yml 文件，如下：

192.168.118.130 主節點配置：

# 加入如下配置
#集群名稱
cluster.name: cluster-es
#節點名稱，每個節點的名稱不能重復
node.name: node-1
#ip 地址，每個節點的地址不能重復
network.host: 192.168.118.130
#是不是有資格主節點
node.master: true
node.data: true
http.port: 9200
# head 插件需要這打開這兩個配置
http.cors.allow-origin: "*"
http.cors.enabled: true
http.max_content_length: 200mb
#es7.x 之后新增的配置，初始化一個新的集群時需要此配置來選舉 master
cluster.initial_master_nodes: ["node-1"]
#es7.x 之后新增的配置，節點發現
discovery.seed_hosts: ["192.168.118.130:9300","192.168.118.131:9300"]
gateway.recover_after_nodes: 2
network.tcp.keep_alive: true
network.tcp.no_delay: true
transport.tcp.compress: true
#集群內同時啟動的數據任務個數，默認是 2 個
cluster.routing.allocation.cluster_concurrent_rebalance: 16
#添加或刪除節點及負載均衡時并發恢復的線程個數，默認 4 個
cluster.routing.allocation.node_concurrent_recoveries: 16
#初始化數據恢復時，并發恢復線程的個數，默認 4 個
cluster.routing.allocation.node_initial_primaries_recoveries: 16

192.168.118.131 節點配置：

# 加入如下配置
#集群名稱
cluster.name: cluster-es
#節點名稱，每個節點的名稱不能重復
node.name: node-2
#ip 地址，每個節點的地址不能重復
network.host: 192.168.118.131
#是不是有資格主節點
node.master: true
node.data: true
http.port: 9200
# head 插件需要這打開這兩個配置
http.cors.allow-origin: "*"
http.cors.enabled: true
http.max_content_length: 200mb
#es7.x 之后新增的配置，初始化一個新的集群時需要此配置來選舉 master
cluster.initial_master_nodes: ["node-1"]
#用于節點發現。（ES7.x之后新增的配置）
discovery.seed_hosts: ["192.168.118.130:9300","192.168.118.131:9300"]
gateway.recover_after_nodes: 2
network.tcp.keep_alive: true
network.tcp.no_delay: true
transport.tcp.compress: true
#集群內同時啟動的數據任務個數，默認是 2 個
cluster.routing.allocation.cluster_concurrent_rebalance: 16
#添加或刪除節點及負載均衡時并發恢復的線程個數，默認 4 個
cluster.routing.allocation.node_concurrent_recoveries: 16
#初始化數據恢復時，并發恢復線程的個數，默認 4 個
cluster.routing.allocation.node_initial_primaries_recoveries: 16

修改Linux系統的 /etc/security/limits.conf 文件

# 在文件末尾中增加下面內容
# 每個進程可以打開的文件數的限制
es soft nofile 65536
es hard nofile 65536

修改/etc/security/limits.d/20-nproc.conf

# 在文件末尾中增加下面內容
# 每個進程可以打開的文件數的限制
es soft nofile 65536
es hard nofile 65536
# 操作系統級別對每個用戶創建的進程數的限制
* hard nproc 4096
# 注：* 表示 Linux 所有用戶名稱

修改/etc/sysctl.conf

# 在文件中增加下面內容
# 一個進程可以擁有的 VMA(虛擬內存區域)的數量,默認值為 65536
vm.max_map_count=655360

重新加載

sysctl -p

使用 ES 用戶分別依次啟動主節點和其他節點。

（在啟動集群時，建議一定要先啟動主節點即cluster.initial_master_nodes配置的節點，然后再啟動其他節點，否則集群可能會啟動失敗或者啟動時長很慢）

#啟動
/opt/elasticsearch/elasticsearch-7.8.0/bin/elasticsearch
#后臺啟動
/opt/elasticsearch/elasticsearch-7.8.0/bin/elasticsearch -d

顯示如下則表示啟動成功：

啟動后可以在瀏覽器中輸入地址：http://linux1:9200/ 訪問，如下：（如果訪問不通可能是端口未開通訪問權限，可以臨時關閉 Linux的防火墻：systemctl stop firewalld）

或者可以訪問 http://linux1:9200/_cat/nodes 請求查詢節點數量，如下：

4、集群分片示例

這里是以上面 window 系統部署的集群為示例。

4.1、單節點集群

啟動一個單節點集群，在集群內創建名為 users 的索引，為了演示目的，我們將分配 3個主分片和一份副本（每個主分片擁有一個副本分片）。

#PUT http://127.0.0.1:1001/users
{
    "settings" : {
        "number_of_shards" : 3,
        "number_of_replicas" : 1
    }
}

創建成功后，通過 elasticsearch-head 插件（一個Chrome插件，安裝參考：http://www.rzrgm.cn/wenxuehai/p/18153752）可以看到該集群現在是擁有一個索引的單節點集群，所有 3 個主分片都被分配在 node-1 。如下圖：

集群健康值：yellow( 3 of 6 )：表示當前集群的全部主分片都正常運行，但是副本分片沒有全部處在正常狀態。
3 個主分片正常。
3 個副本分片都是 Unassigned，它們都沒有被分配到任何節點。在同一個節點上既保存原始數據又保存副本是沒有意義的，因為一旦失去了那個節點，我們也將丟失該節點上的所有副本數據。

當前集群是正常運行的，但存在丟失數據的風險。

4.2、故障轉移（部署多節點集群）

當集群中只有一個節點在運行時，意味著會有一個單點故障問題——沒有冗余。幸運的是，我們只需再啟動一個節點即可防止數據丟失。當你在同一臺機器上啟動了第二個節點時，只要它和第一個節點有同樣的 cluster.name 配置，它就會自動發現集群并加入到其中。但是在不同機器上啟動節點的時候，為了加入到同一集群，你需要配置一個可連接到的單播主機列表。之所以配置為使用單播發現，以防止節點無意中加入集群。只有在同一臺機器上運行的節點才會自動組成集群。
如果啟動了第二個節點，我們的集群將會擁有兩個節點的集群，所有主分片和副本分片會被自動分配。

下面我們再啟動一個節點 1002，啟動成功后elasticsearch-head 插件查看集群情況如下：

集群健康值：green( 6 of 6 )：表示所有 6 個分片（包括 3 個主分片和 3 個副本分片）都在正常運行。
3 個主分片正常
當第二個節點加入到集群后，3 個副本分片將會分配到這個節點上（每個主分片對應一個副本分片）。這意味著當集群內其中一個節點出現問題時，我們的數據都會完好無損。所有新近被索引的文檔都將會保存在主分片上，然后被并行的復制到對應的副本分片上。這就保證了我們既可以從主分片又可以從副本分片上獲得文檔。

4.3、水平擴容

當啟動了第三個節點，我們的集群將會擁有三個節點的集群，ES 為了分散負載會自動對分片進行重新分配。

集群健康值：green( 6 of 6 )：表示所有 6 個分片（包括 3 個主分片和 3 個副本分片）都在正常運行。
Node 1 和 Node 2 上各有一個分片被遷移到了新的 Node 3 節點，現在每個節點上都擁有 2 個分片，而不是之前的 3 個。這表示每個節點的硬件資源（CPU, RAM, I/O）將被更少的分片所共享，每個分片的性能將會得到提升。

分片是一個功能完整的搜索引擎，它擁有使用一個節點上的所有資源的能力。我們這個擁有 6 個分片（3 個主分片和 3 個副本分片）的索引可以最大擴容到 6 個節點，每個節點上存在一個分片，并且每個分片擁有所在節點的全部資源。

索引的主分片的數目在該索引創建時就已經確定了下來。實際上，主分片數確定了該索引能夠存儲的最大數據量（當然，實際大小還取決于你的數據、硬件和使用場景）。

讀操作（搜索和返回數據）可以同時被主分片或副本分片所處理，所以當你擁有越多的副本分片時，也將擁有越高的吞吐量。但是，如果只是在相同節點數目的集群上增加更多的副本分片并不能提高性能，因為每個分片從節點上獲得的資源會變少。你需要增加更多的硬件資源來提升吞吐量。

在運行中的集群上是可以動態調整副本分片數目的，我們可以按需伸縮集群。如下，將副本數從默認的 1 增加到 2：

#PUT http://127.0.0.1:1001/users/_settings
{
     "number_of_replicas": 2
}

4.4、集群發生故障時的表現

假設我們關閉 node-1001 主節點，集群必須擁有一個主節點來保證正常工作，所以發生的第一件事情就是選舉一個新的主節點： Node 2 。在我們關閉 Node 1 的同時也失去了主分片 0 ，如果此時此時剛好來檢查集群的狀況，我們會看到的狀態將會為 red ：不是所有主分片都在正常工作。但是，在其它節點上存在著這個主分片的完整副本，所以新的主節點會立即將這些分片在 Node 2 和 Node 3 上的某一副本分片提升為主分片，此時集群的狀態將會為yellow。這個提升主分片的過程是瞬間發生的，如同按下一個開關一般。

雖然我們擁有所有的三個主分片，但是同時設置了每個主分片需要對應 2 份副本分片，而此時只存在一份副本分片，所以此時我們集群狀態是 yellow 而不是 green 。如果我們同樣關閉了 Node 2 ，我們的程序依然可以保持在不丟任何數據的情況下運行，因為Node 3 也為每一個分片都保留著一份副本。

如果想啟動 node-1001 節點回復原來的樣子，需要往 Node-1001 的配置文件添加如下配置，然后再啟動：

discovery.seed_hosts: ["localhost:9302", "localhost:9303"]

啟動后如下：

5、原理

5.1、路由計算（判斷文檔存儲位置）

Elasticsearch 如何知道一個文檔應該存放到哪個分片中呢？當我們創建文檔時，它如何決定這個文檔應當被存儲在主分片 1 還是主分片 2 中呢（數據是首先存到主分片，然后再從主分片復制到副本分片中的）？首先這肯定不會是隨機的，否則將來要獲取文檔的時候我們就不知道從何處尋找了。實際上，這個過程是根據下面這個公式決定的：

shard = hash(routing) % number_of_primary_shards

routing 是一個可變值，默認是文檔的 _id ，也可以設置成一個自定義的值。
routing 通過hash 函數生成一個數字，然后這個數字再除以 number_of_primary_shards （主分片的數量）后得到余數。這個分布在 0 到 number_of_primary_shards-1 之間的余數（如有3個主節點，則值只能0、1、2），就是我們所尋求的文檔所在分片的位置。
這里只是確定存放到哪個主分片中，然后數據會復制到對應的副本分片。在請求檢索文檔時，協調節點會通過輪詢所有的副本分片（即不一定從主節點檢索數據）來達到負載均衡。

（上圖中 P 代表主分片，R 代表副本分片，如兩個R0 都是 P0 的副本）

這就解釋了為什么我們要在創建索引的時候就確定好主分片的數量并且永遠不會改變這個數量，因為如果數量變化了，那么所有之前路由的值都會無效，文檔也再也找不到了。

所有的文檔API ( get . index . delete 、 bulk , update以及 mget ）都接受一個叫做routing 的路由參數，通過這個參數我們可以自定義文檔到分片的映射。一個自定義的路由參數可以用來確保所有相關的文檔（例如所有屬于同一個用戶的文檔）都被存儲到同一個分片中。

5.2、分片控制（每個節點都有能力處理任意請求）

我們可以發送請求到集群中的任一節點，每個節點都有能力處理任意請求，每個節點都知道集群中任一文檔位置，所以可以直接將請求轉發到需要的節點上。

在下面的例子中，如果將所有的請求發送到Node 1001，我們將其稱為協調節點coordinating node。（實際上，協調節點不一定從自身節點返回數據，也可能會將請求轉發至其他節點。）

當發送請求的時候，為了負載均衡和，更好的做法是輪詢集群中所有的節點，而不是一直請求同一節點。

5.3、數據寫流程

新建、索引和刪除請求都是寫操作，必須在主分片上面完成之后才能被復制到相關的副本分片。

在客戶端獲取反饋即收到成功響應時，此時文檔變更已經在主分片和所有副本分片執行完成，變更是安全的。

有一些可選的請求參數允許影響上述這個過程，可能以數據安全為代價提升性能，這些選項很少使用，因為 Elasticsearch 已經很快。如下：

1、consistency（一致性）

consistency 參數的值可以設為：

one ：只要主分片狀態 ok 就允許執行寫操作。
all：必須要主分片和所有副本分片的狀態沒問題才允許執行寫操作。
quorum：默認值，即大多數的分片副本狀態沒問題就允許執行寫操作。

在默認設置下，即使僅僅是在試圖執行一個寫操作之前，主分片都會要求必須要有規定數量 quorum（其實就是要求必須要有大多數）的分片副本處于活躍可用狀態，才會去執行寫操作（其中分片副本可以是主分片或者副本分片）。這是為了避免在發生網絡分區故障（network partition）的時候進行寫操作，進而導致數據不一致。規定數量即： int((primary + number_of_replicas) / 2 ) + 1

注意，規定數量的計算公式中number_of_replicas指的是在索引設置中的設定副本分片數，而不是指當前處理活動狀態的副本分片數。如果你的索引設置中指定了當前索引擁有3個副本分片，那規定數量的計算結果即：int((1 primary + 3 replicas) / 2) + 1 = 3，如果此時你只啟動兩個節點，那么處于活躍狀態的分片副本數量就達不到規定數量，也因此您將無法索引和刪除任何文檔。

2、timeout

如果沒有足夠的副本分片會發生什么？Elasticsearch 會等待，希望更多的分片出現。默認情況下，它最多等待 1 分鐘。如果你需要，你可以使用timeout參數使它更早終止：100是100 毫秒，30s是30秒。
（新索引默認有1個副本分片，這意味著為滿足規定數量應該需要兩個活動的分片副本。但是，這些默認的設置會阻止我們在單一節點上做任何事情。為了避免這個問題，要求只有當number_of_replicas 大于1的時候，規定數量才會執行。）

5.4、數據讀流程

在處理讀取請求時，協調結點在每次請求的時候會以輪詢的方式輪流訪問副本分片以此達到負載均衡。在文檔被檢索時，已經被索引的文檔可能已經存在于主分片上但是還沒有復制到副本分片，在這種情況下，副本分片可能會報告文檔不存在，但是主分片可能成功返回文檔。一旦索引請求成功返回給用戶，文檔在主分片和副本分片都是可用的。

5.5、更新流程

部分更新，即更新一個文檔的情況是結合了先前說明的讀取和寫入流程：

部分更新一個文檔的步驟如下：

客戶端向Node 1發送更新請求。
它將請求轉發到主分片所在的Node 3 。
Node3 從主分片檢索文檔，修改_source字段中的JSON，并且嘗試重新索引主分片的文檔。如果文檔已經被另一個進程修改，它會重試步驟3，超過 retry_on_conflict 次后放棄。
如果 Node3 成功地更新文檔，它將新版本的文檔并行轉發到Node 1和 Node 2上的副本分片，重新建立索引。一旦所有副本分片都返回成功，Node 3向協調節點也返回成功，協調節點向客戶端返回成功。

當主分片把更改轉發到副本分片時，它不會轉發更新請求。相反，它是轉發完整文檔的新版本。請記住，這些更改將會異步轉發到副本分片，并且不能保證它們以發送它們相同的順序到達。如果 Elasticsearch 僅轉發更改請求，則可能以錯誤的順序應用更改，可能會導致得到損壞的文檔。

5.6、批量操作流程

mge t和 bulk API 的模式實際上類似于單文檔模式。協調節點知道每個文檔存在于哪個分片中，它會將整個多文檔的請求分解成每個分片的多文檔請求，并且將這些請求并行轉發到每個參與節點。

協調節點一旦收到來自每個節點的應答，就將每個節點的響應收集整理成單個響應，返回給客戶端。

用單個 mget 請求取回多個文檔所需的步驟順序:

客戶端向 Node 1 發送 mget 請求。
Node 1為每個分片分別構建多文檔獲取請求，然后并行轉發這些請求到在每個需進行操作的主分片或者副本分片的節點上。一旦收到所有答復，Node 1 構建響應并將其返回給客戶端。

可以對docs數組中每個文檔設置routing參數。

bulk API，允許在單個批量請求中執行多個創建、索引、刪除和更新請求。

bulk API 按如下步驟順序執行：

客戶端向Node 1 發送 bulk請求。
Node 1為每個節點創建一個批量請求，并將這些請求并行轉發到每個包含主分片的節點主機。
主分片一個接一個按順序執行每個操作。當每個操作成功時，主分片并行轉發新文檔（或刪除）到副本分片，然后執行下一個操作。一旦所有的副本分片報告所有操作成功，該節點將向協調節點報告成功，協調節點將這些響應收集整理并返回給客戶端。

6、Elasticsearch 的 master 選舉流程

Elasticsearch 的選主是 ZenDiscovery 模塊負責的，主要包含 Ping（節點之間通過這個 RPC 來發現彼此）和 Unicast（單播模塊包含一個主機列表以控制哪些節點需要 ping 通）這兩部分
對所有可以成為 master 的節點（node.master: true）根據 nodeId 字典排序，每次選舉每個節點都把自己所知道節點排一次序，然后選出第一個（第 0 位）節點，暫且認為它是 master 節點。
如果對某個節點的投票數達到一定的值（可以成為 master 節點數 n/2+1）并且該節點自己也選舉自己，那這個節點就是 master。否則重新選舉一直到滿足上述條件。
master 節點的職責主要包括集群、節點和索引的管理，不負責文檔級別的管理；data 節點可以關閉 http功能。

7、Elasticsearch 集群腦裂問題

腦裂問題(split-brain problem) 在分布式系統中指的是，當網絡分裂（network partition）發生時，導致系統中的兩個或多個節點同時認為自己仍然與其他節點連接，并且各自獨立地開始進行資源的管理或者狀態的變更。這可能會導致數據不一致或其他不期望的行為。

在Elasticsearch（ES）集群中，腦裂現象就是：因主節點節點訪問阻塞或者網絡不可用導致出現分區，不同分區選舉出不同的主節點的現象，即有多個主節點。腦裂問題可能會導致數據丟失、不一致或其他問題。

7.1、腦裂問題的原因

“腦裂”問題可能的成因：

網絡問題：集群間的網絡延遲導致一些節點訪問不到 master，認為 master 掛掉了從而選舉出新的master，并對 master 上的分片和副本標紅，分配新的主分片
節點負載：主節點的角色既為 master 又為 data，訪問量較大時可能會導致 ES 停止響應造成大面積延遲，此時其他節點得不到主節點的響應認為主節點掛掉了，會重新選取主節點。
內存回收：data 節點上的 ES 進程占用的內存較大，引發 JVM 的大規模內存回收，造成 ES 進程失去響應。

7.2、如何解決腦裂問題

腦裂問題解決方案：

減少誤判：discovery.zen.ping_timeout 節點狀態的響應時間，默認為 3s，可以適當調大，如果 master 在該響應時間的范圍內沒有做出響應應答，判斷該節點已經掛掉了。調大參數（如 6s，discovery.zen.ping_timeout:6），可適當減少誤判。
選舉觸發：discovery.zen.minimum_master_nodes:1，這個參數指定了在集群中為了成功選舉出一個主節點，需要有多少個有資格成為主節點的節點（通常是配置了node.master: true的節點）達成一致。例如，如果設置為3，那么在選舉主節點時，至少需要三個有資格的節點達成一致才能選舉出一個主節點。官方建議該值計算公式為（n/2）+1（向下取整，n 為有資格成為主節點的節點個數）
- 通過設置合適的discovery.zen.minimum_master_nodes值，可以確保在出現網絡問題時，只有當大部分有資格的節點能夠相互通信時才會進行主節點選舉，從而避免腦裂的發生。
角色分離：即 master 節點與 data 節點分離，限制角色。主節點配置為：node.master: true node.data: false 從節點配置為：node.master: false node.data: true

posted @ 2024-04-17 20:48 wenxuehai 閱讀(1154) 評論(0) 收藏舉報

刷新頁面返回頂部

提升自己，才有選擇的能力和勇氣