背景

最近某集群擴容了一批物理機，其中 TiKV 節點有6臺機器12個實例，同時調整了 label 設置增加了一層機柜級容災。因為前期做了比較充分的準備工作，到了變更窗口只等著執行scale-out就行，操作過程也很順利，很快就把所有節點都擴進去了，檢查完各實例的運行狀態，確保region已經開始正常調度，就放心去睡覺了（半夜變更，結束時凌晨1點左右）。

第二天一大早還在上班路上，業務方反饋數據庫有部分SQL報錯Region is Unavailable，懷疑新擴容的 TiKV 節點出了問題，火速趕到公司開始排查。

此時內心os，打工人1024不加班的小小心愿要破滅了。。??

故障現象

業務方反饋的報錯信息如下：

其實Region is Unavailable不算什么疑難雜癥，從過往經驗來判斷基本是 TiKV 節點的原因，從字面意思上看就是region在某段時間內不可用，可能的因素有：

• region leader在調度中，或者無法選舉出leader（會有內部backoff）
• tikv實例繁忙被限流，同步可能會有 TiKV server is busy報錯
• tikv實例故障掛掉了，同步可能會有 TiKV server is timeout報錯
• 其他tikv未知問題或bug等

前三種基本能覆蓋90%以上的場景，所以我一開始還是從tikv著手排查。

但是讓人迷惑的是，各種分析下來最后發現和tikv沒有關系，這就是最有意思的點。??

好戲開始。

排查過程

首先檢查前一天晚上擴容的12個tikv實例運行狀態，分析監控和日志并未發現有異常現象，無重啟，各節點負載也很低不存在性能瓶頸。

接著懷疑是偶發性報錯，因為region還處于調度中（到這里感覺到了調度不太正常，比預期中的要慢），偶發性還是有可能的，另外通過監控面板failed query OPM發現tikv:9005報錯碼只是零星出現，也不排除這種可能性。

驗證方式：從dashboard日志搜索中找出具體報錯的SQL，直接用報錯碼搜索即可：

把SQL拿出來嘗試手動執行，發現也報同樣的錯，多次執行效果一樣。于是懷疑這張表的region有副本丟失，打算用show table regions看下這張表的region分布，發現了一個奇怪的報錯：

從報錯信息看，在執行show table regions的時候tidb server去請求了pd的一個API，這個API是作用是查詢region id為xxx的詳細信息，但是無法訪問pd節點。跟著報錯信息，我去檢查了這個pd節點的狀態，發現沒有任何異常，服務正常運行未發生過重啟。

接著我進去pd-ctl用報錯的region id查詢region信息，也能夠正常返回，確認pd節點正常。

退出客戶端，手動執行curl API，報錯依舊，telnet測試報錯pd實例，無法連接，然后把三個pd都telnet了一遍，發現只有這一個pd無法訪問，異常詭異，初步懷疑網絡有問題。

但是擴容前網絡環境都檢查過都是聯通狀態，而且都在同一個網段中，不應該有網絡故障。

接著轉頭去看那個連接不上的pd節點日志，跟蹤了一段時間發現絕大部分都是region調度的信息，但是一點一點翻發現中間偶爾出現operator timeout的字樣，認真把日志讀了幾遍總算看清楚了它說的啥，大意就是在兩個store之間mv peer超時（應該是10min）失敗了：

期間并沒有發現pd自身運行異常問題，回想起前面的調度慢，猜測應該和這個現象有關，貌似和Region is Unavailable有一點點沾邊了，但還不能完全解釋過去，繼續懷疑網絡。

吐槽：給個WARN日志是不是好點

接著命令行登錄原有的tidb實例，再次執行報錯的SQL和show table regions，神奇的事情發生了，均能夠正常返回。再換另一臺新擴的tidb節點執行，報錯依舊。

到這里基本判定是新擴進來的tidb實例有問題，此時距離故障出現超過2小時，業務方開始著急了，無奈之下只能把新擴的tidb實例從負載均衡中剔除臨時繞過，詳細原因進一步排查。

重新梳理了一下思路，我們都知道正常select查詢和show table regions都需要從pd獲取表的region分布信息，這個請求是從被連接的tidb server上發起的，現在奇怪的地方是新擴容的tidb server無法訪問pd，原有的可以訪問，那說明極有可能是新節點被限制訪問了。

登錄pd節點查看防火墻狀態，是關閉狀態，進一步檢查發現iptables服務開啟，查看配置規則后虎軀一震：

這簡直是在不亞于在代碼里下毒啊，所有tidb集群相關的通信端口全都顯式地做了限制，只允許原集群的5臺機器訪問，做了也不算啥，偏偏有的做有的不做，這就有點坑了。。。而且這臺機器上還部署了2個tikv實例，那前面operator timeout也說的通了。

至此復盤一下問題：原集群某些節點設置iptables規則，限制集群外的節點無法與tidb內部服務通信，新擴容的機器并不知道有這個限制，導致新擴容的tidb server無法從pd獲取region信息，連接到新tidb server的會話無法讀到region，拋出Region is Unavailable報錯。同時該節點上的tikv實例無法與新擴容的tikv實例通信，導致region調度受影響，直觀感受是調度非常慢。

回過頭再看，還好故障比較簡答，1024算是保住了。

解決方案

經過各方溝通，得知iptables是為了解決早期某安全漏掃問題設置，現在也沒辦法直接關掉。那么解決辦法就只有一條路，把新擴容的所有機器ip都加到iptables白名單里即可，順便也檢查了原有的5臺機器iptables設置情況，該加的都加上。

vi /etc/iptables.rules
systemctl restart iptables

調整完畢后重新用客戶端登錄新擴容的tidb server執行SQL，發現一切都恢復正常了。

同時region遷移也明顯加速，修改前：

修改后：

總結

看似一個簡單的操作就解決了問題，實際背后隱藏了很多工作在里面，碰到問題不可怕，重要的是要有清晰的思路，綜合運用自己的經驗。

就像有個故事里說的，知道在哪畫線比會畫線更值錢，troubleshooting就是核心競爭力。

作者介紹：hey-hoho，來自神州數碼鈦合金戰隊，是一支致力于為企業提供分布式數據庫TiDB整體解決方案的專業技術團隊。團隊成員擁有豐富的數據庫從業背景，全部擁有TiDB高級資格證書，并活躍于TiDB開源社區，是官方認證合作伙伴。目前已為10+客戶提供了專業的TiDB交付服務，涵蓋金融、證券、物流、電力、*、零售等重點行業。

本文首發渠道：TiDB社區專欄 https://tidb.net/blog/8f7e13dc

總結

以上是生活随笔為你收集整理的TiDB故障处理之让人迷惑的Region is Unavailable的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。