背景

最近某集群擴(kuò)容了一批物理機(jī)，其中 TiKV 節(jié)點(diǎn)有6臺(tái)機(jī)器12個(gè)實(shí)例，同時(shí)調(diào)整了 label 設(shè)置增加了一層機(jī)柜級(jí)容災(zāi)。因?yàn)榍捌谧隽吮容^充分的準(zhǔn)備工作，到了變更窗口只等著執(zhí)行scale-out就行，操作過程也很順利，很快就把所有節(jié)點(diǎn)都擴(kuò)進(jìn)去了，檢查完各實(shí)例的運(yùn)行狀態(tài)，確保region已經(jīng)開始正常調(diào)度，就放心去睡覺了（半夜變更，結(jié)束時(shí)凌晨1點(diǎn)左右）。

第二天一大早還在上班路上，業(yè)務(wù)方反饋數(shù)據(jù)庫(kù)有部分SQL報(bào)錯(cuò)Region is Unavailable，懷疑新擴(kuò)容的 TiKV 節(jié)點(diǎn)出了問題，火速趕到公司開始排查。

此時(shí)內(nèi)心os，打工人1024不加班的小小心愿要破滅了。。??

故障現(xiàn)象

業(yè)務(wù)方反饋的報(bào)錯(cuò)信息如下：

其實(shí)Region is Unavailable不算什么疑難雜癥，從過往經(jīng)驗(yàn)來判斷基本是 TiKV 節(jié)點(diǎn)的原因，從字面意思上看就是region在某段時(shí)間內(nèi)不可用，可能的因素有：

• region leader在調(diào)度中，或者無法選舉出leader（會(huì)有內(nèi)部backoff）
• tikv實(shí)例繁忙被限流，同步可能會(huì)有 TiKV server is busy報(bào)錯(cuò)
• tikv實(shí)例故障掛掉了，同步可能會(huì)有 TiKV server is timeout報(bào)錯(cuò)
• 其他tikv未知問題或bug等

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

但是讓人迷惑的是，各種分析下來最后發(fā)現(xiàn)和tikv沒有關(guān)系，這就是最有意思的點(diǎn)。??

好戲開始。

排查過程

首先檢查前一天晚上擴(kuò)容的12個(gè)tikv實(shí)例運(yùn)行狀態(tài)，分析監(jiān)控和日志并未發(fā)現(xiàn)有異常現(xiàn)象，無重啟，各節(jié)點(diǎn)負(fù)載也很低不存在性能瓶頸。

接著懷疑是偶發(fā)性報(bào)錯(cuò)，因?yàn)閞egion還處于調(diào)度中（到這里感覺到了調(diào)度不太正常，比預(yù)期中的要慢），偶發(fā)性還是有可能的，另外通過監(jiān)控面板failed query OPM發(fā)現(xiàn)tikv:9005報(bào)錯(cuò)碼只是零星出現(xiàn)，也不排除這種可能性。

驗(yàn)證方式：從dashboard日志搜索中找出具體報(bào)錯(cuò)的SQL，直接用報(bào)錯(cuò)碼搜索即可：

把SQL拿出來嘗試手動(dòng)執(zhí)行，發(fā)現(xiàn)也報(bào)同樣的錯(cuò)，多次執(zhí)行效果一樣。于是懷疑這張表的region有副本丟失，打算用show table regions看下這張表的region分布，發(fā)現(xiàn)了一個(gè)奇怪的報(bào)錯(cuò)：

從報(bào)錯(cuò)信息看，在執(zhí)行show table regions的時(shí)候tidb server去請(qǐng)求了pd的一個(gè)API，這個(gè)API是作用是查詢r(jià)egion id為xxx的詳細(xì)信息，但是無法訪問pd節(jié)點(diǎn)。跟著報(bào)錯(cuò)信息，我去檢查了這個(gè)pd節(jié)點(diǎn)的狀態(tài)，發(fā)現(xiàn)沒有任何異常，服務(wù)正常運(yùn)行未發(fā)生過重啟。

接著我進(jìn)去pd-ctl用報(bào)錯(cuò)的region id查詢r(jià)egion信息，也能夠正常返回，確認(rèn)pd節(jié)點(diǎn)正常。

退出客戶端，手動(dòng)執(zhí)行curl API，報(bào)錯(cuò)依舊，telnet測(cè)試報(bào)錯(cuò)pd實(shí)例，無法連接，然后把三個(gè)pd都telnet了一遍，發(fā)現(xiàn)只有這一個(gè)pd無法訪問，異常詭異，初步懷疑網(wǎng)絡(luò)有問題。

但是擴(kuò)容前網(wǎng)絡(luò)環(huán)境都檢查過都是聯(lián)通狀態(tài)，而且都在同一個(gè)網(wǎng)段中，不應(yīng)該有網(wǎng)絡(luò)故障。

接著轉(zhuǎn)頭去看那個(gè)連接不上的pd節(jié)點(diǎn)日志，跟蹤了一段時(shí)間發(fā)現(xiàn)絕大部分都是region調(diào)度的信息，但是一點(diǎn)一點(diǎn)翻發(fā)現(xiàn)中間偶爾出現(xiàn)operator timeout的字樣，認(rèn)真把日志讀了幾遍總算看清楚了它說的啥，大意就是在兩個(gè)store之間mv peer超時(shí)（應(yīng)該是10min）失敗了：

期間并沒有發(fā)現(xiàn)pd自身運(yùn)行異常問題，回想起前面的調(diào)度慢，猜測(cè)應(yīng)該和這個(gè)現(xiàn)象有關(guān)，貌似和Region is Unavailable有一點(diǎn)點(diǎn)沾邊了，但還不能完全解釋過去，繼續(xù)懷疑網(wǎng)絡(luò)。

吐槽：給個(gè)WARN日志是不是好點(diǎn)

接著命令行登錄原有的tidb實(shí)例，再次執(zhí)行報(bào)錯(cuò)的SQL和show table regions，神奇的事情發(fā)生了，均能夠正常返回。再換另一臺(tái)新擴(kuò)的tidb節(jié)點(diǎn)執(zhí)行，報(bào)錯(cuò)依舊。

到這里基本判定是新擴(kuò)進(jìn)來的tidb實(shí)例有問題，此時(shí)距離故障出現(xiàn)超過2小時(shí)，業(yè)務(wù)方開始著急了，無奈之下只能把新擴(kuò)的tidb實(shí)例從負(fù)載均衡中剔除臨時(shí)繞過，詳細(xì)原因進(jìn)一步排查。

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

登錄pd節(jié)點(diǎn)查看防火墻狀態(tài)，是關(guān)閉狀態(tài)，進(jìn)一步檢查發(fā)現(xiàn)iptables服務(wù)開啟，查看配置規(guī)則后虎軀一震：

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

至此復(fù)盤一下問題：原集群某些節(jié)點(diǎn)設(shè)置iptables規(guī)則，限制集群外的節(jié)點(diǎn)無法與tidb內(nèi)部服務(wù)通信，新擴(kuò)容的機(jī)器并不知道有這個(gè)限制，導(dǎo)致新擴(kuò)容的tidb server無法從pd獲取region信息，連接到新tidb server的會(huì)話無法讀到region，拋出Region is Unavailable報(bào)錯(cuò)。同時(shí)該節(jié)點(diǎn)上的tikv實(shí)例無法與新擴(kuò)容的tikv實(shí)例通信，導(dǎo)致region調(diào)度受影響，直觀感受是調(diào)度非常慢。

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

解決方案

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

vi /etc/iptables.rules
systemctl restart iptables

調(diào)整完畢后重新用客戶端登錄新擴(kuò)容的tidb server執(zhí)行SQL，發(fā)現(xiàn)一切都恢復(fù)正常了。

同時(shí)region遷移也明顯加速，修改前：

修改后：

總結(jié)

看似一個(gè)簡(jiǎn)單的操作就解決了問題，實(shí)際背后隱藏了很多工作在里面，碰到問題不可怕，重要的是要有清晰的思路，綜合運(yùn)用自己的經(jīng)驗(yàn)。

就像有個(gè)故事里說的，知道在哪畫線比會(huì)畫線更值錢，troubleshooting就是核心競(jìng)爭(zhēng)力。

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

本文首發(fā)渠道：TiDB社區(qū)專欄 https://tidb.net/blog/8f7e13dc

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。