背景

由於業務需求，需要通過MQ同步商品全量數據，為了防止同步的全量數據有問題導致線上事故，保留原來全量數據，新建索引用來保存本次同步索引數據，計劃通過別名來實現索引的切換。

寫入索引的過程中發現日誌平臺大量報錯：

<code>{"error":{"root_cause":[{"type":"cluster_block_exception","reason":"blocked by: [FORBIDDEN/12/index read-only / allow delete (api)];"}],"type":"
cluster_block_exception","reason":"blocked by: [FORBIDDEN/12/index read-only / allow delete (api)];"},"status":403}
Caused by: org.elasticsearch.ElasticsearchStatusException: Elasticsearch exception [type=cluster_block_exception, reason=blocked by: [FORBIDDEN/
12/index read-only / allow delete (api)];]/<code>

嚇尿，先暫停MQ消息的消費。百度（谷歌）了一下這個問題，發現大概原因是ES存儲空間不夠，索引被強制設置為只讀，不能寫入。這時候我決定打開kibana，查看一下節點機器的運行情況。順利走入了一個排查問題的誤區。

Kibana監控頁面無法打開

順利打開kibana頁面，點一下左側的monitoring菜單，發現監控提示：We couldn't activate monitoring。

監控都沒了，莫不過是機器掛了吧。迅速通過jumpsever登錄到機器，jps命名確認es在運行，ps -ef|grep kibana 命令確認kibana也在運行。好在kibana的console可以進入，迅速通過_cat/health,_cat/node命令確認集群節點正常。心裡總算沒那麼緊張了。決定先解決監控的問題，監控正常訪問才可以查看機器的運行情況，排查問題。

看到有人說重新選舉一個主節點可以解決這個問題

我重啟了主節點，根據es的主節點選舉，主節點重啟的過程中，設置為node.master的節點有可能成為新的主節點，就這樣通過重啟完成了主節點的切換，發現問題依然沒有解決。

接下來我又重啟了kibana,發現問題依然沒有解決。

最後，通過以下命令查看監控日誌的生成情況：

<code>GET /.monitoring-es-6-*/_search
{
  "size": 0,
  "query": {
    "term": {
      "type": "cluster_stats"
    }
  },
  "aggs": {
    "group_by_day": {
      "date_histogram": {
        "field": "timestamp",
        "interval": "hour"
      }
    }
  }
}/<code>

發現kibana的監控日誌確實沒有生成新的了。頓時明白，又回到了最初的問題，es索引只讀不可寫入狀態。

es 索引 read-only

刪除了之前以防萬一留的索引數據，2分索引大概數據量為20g。執行以下命令

<code>PUT _settings
{
  "index": {
    "blocks": {
      "read_only_allow_delete": "false"
    }
  }
}/<code>

讓es恢復到可寫入狀態。問題解決！

覆盤

當Elasticsearch所在磁盤佔用大於等於95%時，Elasticsearch會把所有相關索引自動置為只讀。（官網文檔）

節點上存在的3個主要索引數據大約30g,節點的磁盤大小40g,在加上一些小的索引數據，很容易就超過了閾值95%。

通過lsblk，查看節點磁盤情況，該節點磁盤被分為兩個區，vda1大小為40g,vbd1大小為200g。

es默認的索引存儲位置為home.data,通過命名df看到索引數據被存在了40g的vda1分區。

最終解決方案

修改es的配置文件elasticsearch.yml，為es 的索引和log指定新的存儲分區。

<code>path.data=
path.log=/<code>

並遷移數據文件，重啟es。

作者：Sophie May
鏈接：https://juejin.im/post/5e5809b8f265da57455b45bd
來源：掘金
著作權歸作者所有。商業轉載請聯繫作者獲得授權，非商業轉載請註明出處。

背景

由於業務需求，需要通過MQ同步商品全量數據，為了防止同步的全量數據有問題導致線上事故，保留原來全量數據，新建索引用來保存本次同步索引數據，計劃通過別名來實現索引的切換。

寫入索引的過程中發現日誌平臺大量報錯：

<code>{"error":{"root_cause":[{"type":"cluster_block_exception","reason":"blocked by: [FORBIDDEN/12/index read-only / allow delete (api)];"}],"type":"
cluster_block_exception","reason":"blocked by: [FORBIDDEN/12/index read-only / allow delete (api)];"},"status":403}
Caused by: org.elasticsearch.ElasticsearchStatusException: Elasticsearch exception [type=cluster_block_exception, reason=blocked by: [FORBIDDEN/
12/index read-only / allow delete (api)];]/<code>

嚇尿，先暫停MQ消息的消費。百度（谷歌）了一下這個問題，發現大概原因是ES存儲空間不夠，索引被強制設置為只讀，不能寫入。這時候我決定打開kibana，查看一下節點機器的運行情況。順利走入了一個排查問題的誤區。

Kibana監控頁面無法打開

順利打開kibana頁面，點一下左側的monitoring菜單，發現監控提示：We couldn't activate monitoring。

監控都沒了，莫不過是機器掛了吧。迅速通過jumpsever登錄到機器，jps命名確認es在運行，ps -ef|grep kibana 命令確認kibana也在運行。好在kibana的console可以進入，迅速通過_cat/health,_cat/node命令確認集群節點正常。心裡總算沒那麼緊張了。決定先解決監控的問題，監控正常訪問才可以查看機器的運行情況，排查問題。

看到有人說重新選舉一個主節點可以解決這個問題

我重啟了主節點，根據es的主節點選舉，主節點重啟的過程中，設置為node.master的節點有可能成為新的主節點，就這樣通過重啟完成了主節點的切換，發現問題依然沒有解決。

接下來我又重啟了kibana,發現問題依然沒有解決。

最後，通過以下命令查看監控日誌的生成情況：

<code>GET /.monitoring-es-6-*/_search
{
  "size": 0,
  "query": {
    "term": {
      "type": "cluster_stats"
    }
  },
  "aggs": {
    "group_by_day": {
      "date_histogram": {
        "field": "timestamp",
        "interval": "hour"
      }
    }
  }
}/<code>

發現kibana的監控日誌確實沒有生成新的了。頓時明白，又回到了最初的問題，es索引只讀不可寫入狀態。

es 索引 read-only

刪除了之前以防萬一留的索引數據，2分索引大概數據量為20g。執行以下命令

<code>PUT _settings
{
  "index": {
    "blocks": {
      "read_only_allow_delete": "false"
    }
  }
}/<code>

讓es恢復到可寫入狀態。問題解決！

覆盤

當Elasticsearch所在磁盤佔用大於等於95%時，Elasticsearch會把所有相關索引自動置為只讀。（官網文檔）

節點上存在的3個主要索引數據大約30g,節點的磁盤大小40g,在加上一些小的索引數據，很容易就超過了閾值95%。

通過lsblk，查看節點磁盤情況，該節點磁盤被分為兩個區，vda1大小為40g,vbd1大小為200g。

es默認的索引存儲位置為home.data,通過命名df看到索引數據被存在了40g的vda1分區。

最終解決方案

修改es的配置文件elasticsearch.yml，為es 的索引和log指定新的存儲分區。

<code>path.data=
path.log=/<code>

並遷移數據文件，重啟es。

作者：Sophie May
鏈接：https://juejin.im/post/5e5809b8f265da57455b45bd

閱讀更多 Java技術前沿 的文章

關鍵字: Redis 索引 ElasticSearch