AWS ElasticSearch 升級紀錄 5/6

本篇紀錄 AWS ES 升級相關資訊,這次是從版本 5.x 升到 6.x,因為敝 TEAM ES 資料龐大,為了不讓切換時影響 Prod ES ,擬定升級流程之外也需要 Dev/Stg 不同環境進行演練

升級流程與步驟

先看官方建議的流程 Upgrading Elasticsearch,而我後續實際執行的步驟可以這樣看:

  • 修正 Breaking Changes 錯誤/設定/測試
  • 執行資料轉移(底下仰賴 ES API 完成)
    1. Create the snapshot backups for ES V5 (透過 API 備份舊版 ES V5)
    2. Create the new V6 ES (建立新版 ES V6)
    3. Enable slow Log action (設定到 slow log action 收集到 CloudWatch)
    4. Register the snapshot repository (註冊備份用的 S3 Path )
    5. Delete the .kibana alias (刪除 V6 預設的 .kibana Alias)
    6. Restore the snapshot of V5 (復原 V5 的資料到 V6 的 Instance)
    7. Delete the .kibana index (刪除 V6 內的 V5 .kibana index)
    8. Create the alias named .kibana from .kibana_1 (根據 .kibana 從新建立 .kibana_1 的 alias)
    9. Wait for green status (等待同步完成)
  • Kibana 設定匯出/匯入
    • 利用 Kibana Web Console 匯出 Dashboard/Visualize/Search 等資料 (json file),等 V6 完成再匯入即可

      注意
      V5 的 kibana 無法匯出 Index Pattern·。如果有 V6 的DEV 環境,可以先把 PROD 的 Index Pattern 轉過去再使用 V6 匯出功能就可以連同 Index Pattern 一起輸出,這邊也要注意是否有設定 scripted_fields,如果轉移後有少會影響 Visualize 拉資料的轉換

  • 確認其他 AWS Service 是否有正確轉換接到新的 ES 版本

Breaking Changes

Elasticsearch RESTful API

使用 ES 提供的 RESTful API 來備份、編輯 Index 及 Alias、刪除復原等動作。

Blue/Green Deployments

操作同時,Create ES V6 跟 Enable Slow log action 要分開做沒辦法一次到位,同時要注意 Blue/Green deployments,最後真的要做的時候可以把會進行 Blue/Green 的修改盡可能安排在一起,避免 Instance 數量很多的時候觸發會噴更多 $$$.

Enabling or disabling the publication of error logs or slow logs to CloudWatch