來源：銘毅天下Elasticsearch

1、主節點設定1個，但是當機了，叢集咋辦？

有人試過唯一的 master 所在的主機恢復不了了，可以配置其他資料節點作為 master 恢復叢集嗎？

1.1 問題描述

多節點叢集，但只設定一個候選主節點，但這個主節點所在的物理機出故障了，怎麼辦？

1.2 問題拆解分析

第一直覺——這裡的關鍵在於：我們們得有多個候選主節點。如果沒有，這個沒法再次選主。

在 Elasticsearch 中，叢集的穩健性和高可用性是透過多個主節點候選（eligible master nodes）實現的，而不是依賴單個主節點候選。如果你的叢集只配置了一個候選主節點，且該節點所在的物理機出現故障，這確實會導致問題，因為沒有其他節點可以接替成為新的主節點。

問題提及的多節點叢集中單一主節點候選的問題包含但不限於：

• 問題1：單點故障；
• 問題2：叢集不可用；
• 問題3：資料完整性風險。

1.3 解決方案探討

1.3.1 配置其他資料節點作為主節點

在 Elasticsearch 叢集中，任何節點理論上都可以被配置為主節點候選。如果叢集當前只有一個主節點候選，並且該節點發生故障，可以嘗試透過以下步驟恢復叢集（這個得試驗後給出具體結論）。

• 步驟1：更新配置——在其他資料節點的配置檔案中（通常是 elasticsearch.yml），修改相關設定以使這些節點成為主節點候選。

• 步驟2：重啟節點——對配置進行更改後，需要重啟這些節點以應用新配置。

• 步驟3：監控和驗證——重啟節點後，監控叢集狀態，確保新的主節點被正確選舉且叢集恢復正常執行。

步驟2、步驟3的時間因資料量、叢集規模而異，有可能非常長！

1.3.2 馬後炮方案——配置多個候選主節點

叢集規模足夠大，也就是節點足夠多時（比如大於6個），需要配置多個主節點候選主節點。

一般我們們建議至少配置三個符合主節點條件的節點。這樣，即使一個節點發生故障，其他節點仍然可以參與主節點選舉，確保叢集的持續執行和資料的一致性。

從 Elasticsearch 7 開始，當主節點失效時，叢集會自動進行新的主節點選舉。如果有多個候選主節點，這個過程將更加順利和迅速。

參見：

https://www.elastic.co/cn/blog/a-new-era-for-cluster-coordination-in-elasticsearch

1.4 叢集的高可用性非小事

像類似上述問題，當然配置多個候選主節點是關鍵中的關鍵。與之同等重要的是，確保叢集的高可用性，就是我們們的資料即便出現硬體配置故障，也不丟！

為保障叢集的高可用性，我們們之前也講過快照備份策略機制、定時快照SLM機制。我們要確保叢集有恰當的故障轉移和恢復策略，例如，定期快照和備份可以幫助在發生故障時快速恢復資料。

1.5 小結

總之，為了確保 Elasticsearch 叢集的高可用性和穩定性，強烈推薦配置多個主節點候選，並且定期進行備份和快照。這樣即使某個節點發生故障，叢集也可以繼續執行，減少了單點故障的風險。

2、複製一時爽，出問題難倒英雄漢！

2.1 一臺機器兩個叢集，直接複製，啟動報錯！

老師，請問你有沒有遇到過一臺機器啟動兩個 es 叢集，並各自啟動一個 kibana，但是登入其實一個 kibana 會把另一個擠下去。

是這樣的，我直接把一個 es 叢集的整個 es 目錄和 kibana 目錄全部複製，然後修改了 es 和 kibana 的配置，只改了一個埠就啟動了。

2.2 問題拆解

直接複製整個Elasticsearch和Kibana目錄然後僅修改埠配置確實可能是問題的根源。

這種做法可能導致了幾個潛在的問題：

• 潛在問題1——配置檔案的重複。

僅僅修改埠可能不足以完全隔離兩個叢集。Elasticsearch 和 Kibana 的配置檔案中包含多個設定項，不僅僅是埠。

例如，Elasticsearch的叢集名稱、節點名稱、路徑設定等，Kibana的 Elasticsearch 連線設定、安全設定等，都需要根據第二個叢集的特定需求進行調整。

• 潛在問題2——資料和狀態檔案的衝突。

如果直接複製了整個目錄，那麼其中的一些資料和狀態檔案也會被複制。

這可能導致兩個叢集之間的資料衝突，特別是如果這些檔案包含了特定於叢集的資訊（如叢集狀態、節點ID、日誌檔案等）。

• 潛在問題3：安全和會話設定的衝突。

Kibana的安全設定（如加密金鑰）在兩個例項之間可能會發生衝突，特別是如果它們都使用預設設定的話。

這可能解釋了為什麼登入一個Kibana例項會影響另一個例項。產生問題所說的現象。

2.3 解決方案探討

要說明一下，我直接直播錄課的影片中兩個節點、三個節點也都是1臺雲伺服器部署兩個或三個節點，但沒有出現上面的問題。 

核心在於：從第一個節點複製到第二個、第三個節點的時候，直接清空了 data 路徑下的一切檔案，是狠狠的 rm -rf，然後修改的配置。這樣能確保萬無一失。

當然，為了解決這個問題，可以採取以下步驟：

• 獨立安裝：而不是複製現有的目錄，最好是從頭開始為第二個叢集獨立安裝Elasticsearch和Kibana。這樣可以確保所有配置都是獨立和清晰的。

• 仔細檢查配置檔案：確保兩個叢集的所有配置檔案都已經根據各自的需求進行了適當的修改。這包括但不限於埠號，還有叢集名稱、節點名稱、路徑設定等。

• 區分資料目錄：確保兩個Elasticsearch叢集的資料目錄是分開的，以避免資料衝突。

• 單獨的會話和安全設定：對於Kibana，確保每個例項有自己的會話和安全設定，這可能包括server.basePath、xpack.security.encryptionKey等。

• 瀏覽器會話共享：當你在同一瀏覽器中登入兩個不同的Kibana例項時，可能會發生會話共享問題。這是因為Kibana預設使用相同的會話cookie，所以登入一個例項可能會覆蓋或干擾另一個例項的會話。解決方法是使用不同的瀏覽器或瀏覽器的隱身/無痕模式來訪問不同的Kibana例項，或者更改Kibana的會話cookie設定。這種機率也存在，不妨也嘗試一下。

• 資源競爭：在同一臺機器上執行兩個叢集可能導致資源競爭（CPU、記憶體等）。確保機器有足夠的資源來同時執行兩個叢集。這種硬體配置的確認是大前提。

相信採取這些措施後，兩個叢集應該能夠獨立執行，互不干擾。

3、資料衝突問題：全量重新整理索引丟失資料

3.1 問題背景描述

定時任務全量重新整理索引部分資料丟失,使用 api bluk 方式批次寫入，返回成功條數與寫入條數一致。但是在索引裡查詢不到這條資料。

• 重新整理頻率：預設1秒。
• bluk大小：1000條資料。

問題現象：週五 週六 週日 三天定時任務觀察，都會丟失固定的“品”（解釋一下：這裡指儲存的資料），不是隨機丟失，觀察日誌沒有報錯。

3.2 問題拆解

這個我與球友做過多次交流，大致根據最終結果：“資料不一致”猜測可能的原因。

現象在於：資料 bulk 寫入了，寫入過程也沒有報錯，但是結果卻查詢不到。

大致猜測問題可能出在：

• 寫入失敗，中間環節可能報錯，需要列印 bulk 寫入結果響應日誌排查。
• 重新整理頻率的問題，是不是不是預設的 1s，待核查確認。
• 資料更新問題，相同 id 導致後面寫入的覆蓋前面的資料（Elasticsearch 更新機制決定）。

3.3 問題解決

3.4 為什麼系統自帶id 比我們們自己定義的 id 要好呢？

在處理 Elasticsearch 叢集時，選擇如何生成文件的唯一識別符號（ID）是一個重要的設計決策。雖然有時可能會考慮使用自定義程式生成的ID，但通常推薦使用 Elasticsearch 自己生成的ID。

以下是幾個主要原因：

第一，從效能最佳化層面來講，Elasticsearch 自動生成的ID經過了專門的最佳化，旨在減少資料插入時的效能開銷。

這些ID根據特定的規則設計，以最小化新文件插入對索引結構的影響。這意味著，使用 Elasticsearch 生成的ID可以更高效地管理資料索引，從而提高整體效能。

第二：分散式環境中的唯一性保證。

在分散式系統中，確保ID全域性唯一是一個技術挑戰。Elasticsearch 的內部機制可以保證在分散式環境下生成的ID是全域性唯一的，避免了需要實現複雜邏輯來防止ID衝突的必要。

我不止一次收到過類似自定義 ID 重複的問題，當然本文提及的問題本質也是 ID 重複所致。

第三：減少索引碎片化

Elasticsearch 使用的ID生成機制有助於減少索引碎片化。

如果自定義ID不是隨機的，可能導致資料在分片之間分佈不均，某些分片可能承載更多資料，進而影響查詢和儲存效能。

第四：簡化應用程式設計 採用 Elasticsearch 自動生成的ID可以簡化應用程式的設計。不需要額外考慮ID生成的邏輯，開發者可以將更多的精力集中在核心業務邏輯上，從而提高開發效率和減少錯誤。

第五：避免文件重複插入 使用 Elasticsearch 自動生成的 ID 有助於避免文件的重複插入。因為即使內容相同，不同的文件也會被分配不同的ID，除非顯式指定。這樣就減少了資料冗餘和混淆的可能性。

然而，“不能一杆子打死”，也有一些場景下自定義ID是有意義的：

• 場景一：業務需求。

如果業務邏輯需要根據特定的ID訪問或關聯資料，例如，如果文件的ID與其他系統中的實體ID相對應。。

• 場景二：資料去重。

如果需要防止相同資料的重複插入，可以使用自定義ID來實現。這在資料同步或整合場景中尤其常見。

例如，我們們之前文章多次提及過的 MySQL 等資料庫同步  Elasticsearch 場景。

3.5 小結

綜上所述，在決定是否使用自定義ID之前，需要考慮上述因素，並根據具體的應用場景和需求來做出決定是否使用自定義的 ID。使用 Elasticsearch 自動生成的ID不僅有助於提升效能，還能確保資料的一致性和唯一性，同時簡化系統的設計和維護。這些優點使得在大多數情況下，使用系統生成的ID成為了一個更明智的選擇。