#Elasticsearch #Upgrade #SRE #DevOps #Maintenance

Elasticsearch 9.0+ 滾動升級手冊：SRE 的零停機實戰指南

2026年2月2日

為什麼要 Rolling Upgrade？

在 Production 環境，我們追求的是 Zero Downtime (零停機)。 Rolling Upgrade 允許我們一次重啟一個節點，整個 Cluster 依然保持服務。

但在 9.0+ 的升級中，有一個物理限制必須記住：

「新版節點的 Shard 無法複製回舊版節點。」

這意味著在升級過程中，如果一個新版節點掛了，它的資料無法轉移到還沒升級的舊節點上。所以，「順序」 決定了生死。

第一階段：升級前的準備 (Pre-flight Check)

在動手之前，請確認以下事項：

備份 (Snapshot)： 這是 SRE 的保命符。不要相信自己的運氣，執行一次完整的 Snapshot。
檢查 Deprecations： 使用 Kibana 的 Upgrade Assistant 確認有沒有即將被移除的設定。
規劃順序 (The Order)： 這是最關鍵的一步。

🚀 黃金升級順序 (The Upgrade Order)

官方建議嚴格遵守以下順序，確保 ILM (生命週期管理) 能正常運作，且 Master 最後升級以維持腦部穩定。

Frozen Tier (最不重要，先當白老鼠)
Cold Tier
Warm Tier
Hot Tier (寫入熱區)
Coordinating / Ingest / ML (無資料節點)
Master Eligible Nodes (最後升級大腦)

第二階段：SOP 循環 (每台 Node 做一次)

請針對每一台機器，依序執行以下 8 個步驟。嚴禁同時重啟多台機器。

Step 1: 暫停 Shard 分配 (Disable Allocation)

我們不希望因為重啟一台機器，ES 就開始瘋狂搬運幾 TB 的資料。我們先叫 Cluster 「冷靜」，不要因為短暫的離線就觸發 Rebalance。

PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.enable": "primaries"
  }
}

設定為 primaries 代表：只允許主分片分配，但不允許副本搬遷。

Step 2: 暫停 ML Jobs (如有)

如果你有跑 Machine Learning，先暫停它們，避免升級時發生錯誤。

POST _ml/set_upgrade_mode?enabled=true

Step 3: 執行 Flush (選用但推薦)

這可以把 Memory Buffer 的資料寫入 Disk，加快重啟後的 Recovery 速度。

POST /_flush

Step 4: 停止並升級節點 (RPM 範例)

這是真正動刀的時候。

# 1. 停止服務
sudo systemctl stop elasticsearch

# 2. 使用 RPM 升級 (設定檔會被保留，或是產生 .rpmnew)
sudo dnf update elasticsearch

# 3. 升級 Plugins (如果有的話，這步常被忘記!)
sudo /usr/share/elasticsearch/bin/elasticsearch-plugin install --batch analysis-icu

SRE 關鍵檢查： 檢查 /etc/elasticsearch/elasticsearch.yml。在 Rolling Upgrade 中，cluster.initial_master_nodes 必須被註解掉或移除。因為這是加入現有 Cluster，不是建立新 Cluster。

Step 5: 啟動節點

sudo systemctl start elasticsearch

確認它有加入 Cluster：

# 檢查該 Node 的 version 欄位是否變成新版
GET _cat/nodes?h=ip,name,version&v=ture

Step 6: 恢復 Shard 分配

節點回來了，我們要告訴 Cluster 可以開始把 Shard 搬回這個新節點了。

PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.enable": null
  }
}

Step 7: 等待綠燈 (Wait for Green)

這是最考驗耐心的時刻。絕對不要在 Status 還是 Red 或 Yellow 時去動下一台機器。

監控 Recovery 進度：

GET /_cluster/health

💡 黃燈 (Yellow) 警報： 在升級初期，你可能會看到狀態卡在 Yellow。 原因： 新版節點的 Shard 不能複製到舊版節點。如果你只升級了 1 台，那該台上面的 Primary Shard 就沒有地方放 Replica (因為其他台還是舊版)。 解法： 只要確認 init (初始化中) 和 relo (搬遷中) 的數字是 0，就可以繼續升級下一台。等到第二台升級完，Replica 就會有地方去了。

Step 8: 重複

回到 Step 1，對下一台機器執行同樣動作。

第三階段：收尾 (Post-Upgrade)

當所有節點（包含 Master）都升級完畢，且 Cluster 呈現綠燈時：

恢復 ML Jobs：

POST _ml/set_upgrade_mode?enabled=false

檢查 Archived Settings： 有些舊版設定在 9.0 可能被移除了，這些設定會被封存在 “archived” namespace 下，建議清理掉。
Kibana 升級： ES 升級完後，別忘了升級 Kibana、Logstash 和 Beats/Agent。

SRE 的最後叮嚀

不要跳級： 如果你是 7.x，請先升到 7.17，再升 8.x，最後才到 9.x。不要妄想從 7.x 直接 rpm install 9.0。
Log 是你的好朋友： 啟動失敗時，第一時間看 /var/log/elasticsearch/cluster-name.log。通常是 jvm.options 或 elasticsearch.yml 的格式問題。