今天的精選問題，說難肯定是不難，但是典型不典型呢——還是挺典型的。而且，相信大家也不是總有精力去閱讀枯燥的技術文字，所以正如文章的封面一樣，今天的主題是分享一個輕松的 TDengine Database的使用案例。

事情的經過是這樣的：一位用戶在華為云服務上用兩個節點的內網搭建了一個 TDengine Database 集群，集群可以正常工作。除了這個集群之外，該用戶還有另一個單獨的華為云服務器，他們不屬于同一內網，且分屬于兩個華為云賬號。在這臺服務器上面，有一個單機版的TDengine在運行。

有一天，他突然發現，在本地使用jdbc-restful方式去連接單機的TDengine是OK的，連接集群卻會報錯——timed out。

事實上，對于jdbc-restful這種連接方式而言，不論TDengine是單機還是集群都應該是透明的，不存在什么特殊的區別，因為它只是連接6041這個HTTP服務端口，由運行這個服務端口的主機提供taosd服務（單機或集群)。

所以，一個OK一個不OK的情況是很詭異的。發現群里有這樣的問題，我們立馬到達戰場開始排查。

對于云服務器出現的外網連接問題，我們的第一反應其實就是安全組的端口策略配置。所以，我們先讓用戶登陸了集群節點所在的華為云后臺，并發來安全組配置的截圖。在確認了安全組策略沒問題之后，我們才開始了其他操作。

一開始，我們試著把內網ip的集群換成了外網ip。這一換不要緊，整個集群當時就不能工作了。并且出現了熟悉的：“unable to establish connection”。

遇到這種情況，檢查節點間的端口連接情況是必須的操作。但我們telnet外網IP加端口6041后發現果然不通，而換成了telnet內網ip加端口6041就一切正常了。

這下我們就很迷惑了。

難道是外網ip的問題？可是檢查了下，這些ip都是彈性ip，也就是都綁定在云服務器上的ip。那么既然如此，telnet 外網IP+6041怎么可能連接不通呢？

正在一籌莫展的時候，我們突然想到了安全組配置后是需要關聯到服務器實例上的，否則是不會生效的。于是我們趕緊回到后臺做了檢查——果然，這個用戶雖然配置了規則，但是因為初次使用云服務對于操作并不熟悉。所以，這套安全組規則并沒有關聯到這兩臺集群的服務器。

而單機節點可以連接的原因很簡單——在另一個華為云賬號安全組的策略關聯上了。

這才是以上詭異事件的真正原因——是不是有一點哭笑不得，表象：云服務上的TDengine只有單機可以對外服務，集群卻不行？事實：集群和單機分屬兩個賬號，集群的安全組配置完并沒有關聯到實例上。

由于TDengine的生態正在逐步完善中，與各大平臺或組件的交互也會越來越頻繁，所以遇到的問題種類也會越來越多。很多問題其實都是一些非常不起眼的操作導致，這就需要我們非常細致地排查我們的場景了。就比如這次的問題，是典型的“細節決定成敗（keng  ren）”。

最終，我們用了一下午的時間，把問題解決了。又用了斷斷續續的半天才把來龍去脈全部摸清楚。期間，曾幫助解決docker集群連接問題（）的大佬 @freemine 再次悄悄路過幫忙定位問題原因，十分熱心。

最終，解決問題，皆大歡喜。

別看說起來輕描淡寫，但是當時雙方在只能靠文字溝通的情況下效率并不高，排查起來是比較耗時耗力的。就比如：“他們（集群和單機）不屬于同一內網且分屬于兩個華為云賬號”這個信息就是后來反推root cause的時候才得知的。

但不論如何，我們都會繼續為 TDengine Database 的用戶們保駕護航的。