記一次中臺數據傳輸同步Elasticsearch失敗的車禍現場

時間 2019-11-07

標籤一次中臺數據傳輸同步 elasticsearch 失敗車禍現場欄目系統網絡简体版

原文原文鏈接

歡迎關注我的微信公衆號: 小哈學Java, 優質文章第一時間推送喲！html

我的網站: www.exception.site/essay/elast…node

1、背景

前幾天小哈在釘釘羣裏收到重慶業務線反饋，說是中臺數據傳輸中間件在同步 Mysql 增量數據到 Elasticsearch 老是失敗。sql

2、題外話

你說的這個數據傳輸和阿里雲提供的數據傳輸DTS是一個東西嗎？數據庫

不是！上面說的數據傳輸是小哈所在的中臺研發部自主研發的中間件，目的是爲了取代各業務線對阿里DTS同步功能的依賴！api

目前來講，數據傳輸仍是要依賴於阿里開源 Canal, 或者阿里 DTS，依賴的目的是實現對 Mysql 數據庫 binlog 增量訂閱。bash

以上網絡架構示例圖中，中臺數據傳輸充當一個 binlog 事件消費者的角色，經過自定義規則映射，數據加工，分發並最終同步到目標源 Elasticsearch 中。服務器

3、開始排查

迴歸正題，出了問題，立馬趕忙經過跳板機連上數據傳輸所在的服務器，開始查看日誌：微信

看到日誌中存在大量的 [FORBIDDEN/12/index read-only / allow delete (api)] 錯誤！！網絡

提示錯誤也很明顯：ES 索引處於只讀狀態！！在和業務組溝通之後，發現須要同步的目標索引有兩個，一個商品索引（充當主表），一個商品屬性索引(充當商品從表)，從表同步是 ok 的，也就是說商品屬性索引非只讀狀態，寫入正常，僅僅是商品索引處於只讀狀態，最終未能正常同步數據。架構

4、爲何索引處於只讀狀態呢？

什麼緣由致使的索引只讀的？小哈開始翻閱 Elasticsearch 官方文檔, 原文以下：

Elasticsearch considers the available disk space on a node before deciding whether to allocate new shards to that node or to actively relocate shards away from that node.

Elasticsearch 在決定是否分配新分片給該節點，或對該節點從新定位分片以前，會先判斷該節點存儲空間是否足夠，若是說你的使用磁盤空間已經超過 95%，ES 會自動將索引 index 置爲 read-only 狀態。

因而，讓運維看下 ES 機器的磁盤空間是否足夠，運維反饋說：前兩天就是由於磁盤不足告警，剛剛擴的容，確定是夠的！

真相大白了！

前兩天磁盤空間不足，那個時候，商品索引恰好有寫入的操做，因爲 ES 的保護機制，將該索引置爲了只讀狀態。

5、如何解決

緣由找到了！要如何解決呢？

處於只讀狀態的索引，只能被查詢或者刪除。而 ES 還不會自動將索引狀態切換回來，就須要咱們手動切換了：

PUT /<yourindex>/_settings
{
  "index.blocks.read_only_allow_delete": null
}
複製代碼

對商品索引執行如上命令後。讓業務組再次同步數據，一切正常了。

6、參考

歡迎關注微信公衆號: 小哈學Java

相關標籤/搜索