作者｜陳玉

最近(jin)，在TDengine Database的一(yi)個社區群中突(tu)發了一(yi)場(chang)嚴(yan)重(zhong)的灌(guan)水事件。幾位群友不眠不休(xiu)地(di)聊天，可以說是廢(fei)寢(qin)忘(wang)食。那么到底是什么話題能讓他們凌(ling)晨四(si)點還在忘(wang)我地(di)討論？

這個話題就是(shi)——如(ru)何(he)完(wan)善Docker環境下TDengine Database的集群搭建。“什(shen)么(me)？除(chu)了你(ni)們官方(fang)自己人之外，怎么(me)會有(you)用戶(hu)加班加點地(di)討論如(ru)何(he)完(wan)善Docker環境的集群搭建，這也太(tai)假了。”

好吧，我們承認：其實是有一個叫Oliver（群昵稱）的(de)用戶(hu)遇到了這樣(yang)的(de)問題——辛(xin)辛(xin)苦苦搭起來Docker環(huan)境下的(de)TDengine集群在客戶(hu)端連不上了。接下來，就引(yin)發了群里的(de)二(er)位(wei)熱(re)心(xin)大佬的(de)討論不休，直到想出最后的(de)解(jie)決(jue)方案。

事情的經(jing)過(guo)是這樣(yang)的：

該用戶的數據庫集群裝在(zai)這(zhe)臺(tai)Linux服(fu)務器上（ip:10.0.31.2），容(rong)器ip所(suo)在(zai)的網(wang)絡(luo)是由Docker在(zai)宿主機創建的虛擬網(wang)絡(luo)172.19.0.0/16。三個(ge)容(rong)器的hostname和節點ip分別：taosnode1（172.19.0.41）、taosnode2（172.19.0.42）、taosnode3（172.19.0.43）。

各個節點配置如下：

taosnode1: firstEp=taosnode1:6030,secondEp=taosnode2:6030,fqdn=taosnode1;端口映射：16030-16042:6030-6042（tcp/udp）
taosnode2: firstEp=taosnode1:6030,secondEp=taosnode2:6030,fqdn=taosnode2;端口映射：26030-26042:6030-6042（tcp/udp）
taosnode3: firstEp=taosnode1:6030,secondEp=taosnode2:6030,fqdn=taosnode3;端口映射：36030-36042:6030-6042（tcp/udp）

按照(zhao)官方文(wen)檔的指示努力(li)折騰(teng)一番后，Oliver終(zhong)于搭起(qi)了(le)這(zhe)個集群。添(tian)加完節點之后，他忐(tan)忑地敲下了(le)“show dnodes”，隨著三個READY映入眼簾后———舒(shu)坦(tan)了(le)。

服務端沒有問(wen)題，接下來該客(ke)戶端了。他打開(kai)了自(zi)己的一(yi)臺ip為10.0.31.5（與(yu)集(ji)群宿(su)主機同一(yi)網段）的Windows主機，迅(xun)速地(di)在上(shang)面(mian)安裝了個(ge)TDengine客(ke)戶端，添(tian)加(jia)hosts信息，做好路由(you)，2.8MB，傻瓜式安裝，輕松便捷，連(lian)接集(ji)群一(yi)氣呵成。“show dnodes”隨著三個(ge)READY再(zai)次映入眼簾后———又舒坦了。

Oliver十分滿意，然而，他馬(ma)上發現事情(qing)可(ke)能(neng)并不像(xiang)想(xiang)象中的(de)那(nei)么簡(jian)單。

由(you)于(yu)業務需要(yao)，他還(huan)需要(yao)完成客戶端（10.0.2.61）跨網段連接服務端集群(qun)(qun)（基(ji)于(yu)ip:10.0.31.2的(de)Docker環境下的(de)集群(qun)(qun)）。ping得通宿主(zhu)機，telnet得通集群(qun)(qun)映射(she)出來的(de)端口，使用taos連接集群(qun)(qun)，一(yi)樣的(de)操作也和此前一(yi)樣順利。于(yu)是他再次敲(qiao)下“show dnodes”——萬萬沒想到，這時令所有TDengine用戶都(dou)深惡痛絕(jue)的(de)“DB error：Unable to establish connection”出現了。于(yu)是，他便在群(qun)(qun)中拋出了自己(ji)的(de)問(wen)題。

上文(wen)說到(dao)的兩位熱(re)心的同學就(jiu)是在這(zhe)個時(shi)候(hou)出現(xian)的。一(yi)位是TDengine的外部Contributor——Freemine。另(ling)一(yi)位是路見問題拔刀相助的熱(re)心大佬(lao)pigwing。

由于(yu)集群本(ben)身(shen)沒有任(ren)何(he)使(shi)用(yong)問題(ti)，唯(wei)一的(de)(de)(de)區別就是客戶(hu)端連接(jie)服務器的(de)(de)(de)方式(shi)變(bian)成了跨網段。所(suo)以(yi)，一開始大家的(de)(de)(de)思路就是——既然走宿主(zhu)機的(de)(de)(de)端口不行，那就試(shi)試(shi)直(zhi)接(jie)連到Docker環境(jing)下(xia)(xia)的(de)(de)(de)ip吧。遺憾(han)的(de)(de)(de)是，跨網段連接(jie)Docker環境(jing)下(xia)(xia)內(nei)部(bu)ip的(de)(de)(de)想法沒能(neng)實現。

接(jie)著大家(jia)推(tui)測：TDengine靠的是EndPoint（EP）來識別數據節點，而(er)EP=FQDN+端口。可客戶端連接(jie)已(yi)經成功，只是無法(fa)對數據操(cao)作(zuo)，在(zai)FQDN無誤(wu)的情況(kuang)下，大家(jia)猜測是集群內的端口出現了問題，從(cong)(cong)而(er)沒拿到集群的拓撲信息。接(jie)下來，從(cong)(cong)最(zui)初的了解環境，到一步(bu)一步(bu)的排(pai)查問題，三個鍥而(er)不舍的工程(cheng)師在(zai)群里從(cong)(cong)4月22日討論到4月25，最(zui)晚(wan)的時(shi)候凌晨4點多都有人在(zai)線。

終(zhong)于，在三人的通力合作多(duo)次試錯下，4月24日凌晨1點(dian)——freemine提出了一個行之有效的最終(zhong)解(jie)決方案（文字過多(duo)只截圖關鍵部分）

大功告(gao)成，經過測試后，一切(qie)順利！

那么，freemine的(de)集群(qun)(qun)搭建方案和最初的(de)集群(qun)(qun)搭建有什么區別呢？

雖然過(guo)程曲折，但是最后我們仔細對比一(yi)下兩者的(de)(de)(de)方(fang)案(an)就(jiu)(jiu)會發現，它們的(de)(de)(de)區別(bie)就(jiu)(jiu)只有在端(duan)(duan)口(kou)配置這一(yi)塊不(bu)一(yi)樣。freemine的(de)(de)(de)方(fang)案(an)是在每一(yi)個單機的(de)(de)(de)serverport都修改(gai)了不(bu)一(yi)樣的(de)(de)(de)值。taosnode1節點的(de)(de)(de)serverport為6030—映(ying)射主機的(de)(de)(de)6030端(duan)(duan)口(kou)；taosnode2節點的(de)(de)(de)serverport為7030–映(ying)射主機的(de)(de)(de)7030端(duan)(duan)口(kou)；taosnode3節點的(de)(de)(de)serverport為8030–映(ying)射主機的(de)(de)(de)8030端(duan)(duan)口(kou)。

而提問(wen)者Oliver最初的各個節點(dian)的serverport都是沒做修(xiu)改的默認6030，映射到(dao)宿(su)主(zhu)(zhu)機(ji)的時(shi)候是16030，26030，36030。就(jiu)是這(zhe)樣(yang)的配(pei)置在客戶端(duan)與集群(qun)宿(su)主(zhu)(zhu)機(ji)的同網段連接時(shi)并(bing)沒有發生問(wen)題，而是在跨網段連接時(shi)出現問(wen)題。

看起來一絲小小的(de)改動居(ju)然有這(zhe)么大的(de)區別(bie)？Why？

其實是這(zhe)(zhe)樣，當客戶端(duan)與服務端(duan)同(tong)屬一(yi)個網段的時候，在(zai)添加路(lu)由后，客戶端(duan)是可(ke)以直接(jie)訪問(wen)到Docker內部的。這(zhe)(zhe)樣一(yi)來，IP地址(zhi)就可(ke)以根據需(xu)要被(bei)正確地解(jie)析出來。如：taosnode1（172.19.0.41）、taosnode2（172.19.0.42）、taosnode3（172.19.0.43）。在(zai)不(bu)同(tong)的IP地址(zhi)下(xia)，即便(bian)端(duan)口都(dou)是一(yi)樣的6030，TDengine還是可(ke)以完成不(bu)同(tong)節點的區分。

但是，當跨網(wang)段之后就不一樣了(le)。對于不同網(wang)段的(de)客(ke)戶端(duan)和服務(wu)(wu)端(duan)而言，客(ke)戶端(duan)要(yao)通過真實(shi)(shi)路由(you)去(qu)連接服務(wu)(wu)端(duan)，但真實(shi)(shi)路由(you)中并(bing)沒有注冊我們(men)設置的(de)Docker內部網(wang)絡，所以客(ke)戶端(duan)自然就訪問不了(le)Docker內部的(de)網(wang)絡。因此，當taosc需要(yao)得到(dao)集群(qun)提供的(de)不同節點的(de)信息時，FQDN已經無(wu)法正確解析IP地(di)址了(le)。這時候，就需要(yao)通過端(duan)口來實(shi)(shi)現不同節點的(de)區分。

這(zhe)就是不(bu)能再在Docker環境下的(de)節點中同時使(shi)用6030端口的(de)原因。

因(yin)此，當你使用(yong)了Docker主(zhu)機內外一(yi)致的端口映(ying)射，且每個(ge)節點(dian)的serverPort參數不(bu)相同(tong)的設(she)置時，集(ji)群(qun)就(jiu)可以(yi)通過不(bu)同(tong)的端口來區分(fen)不(bu)同(tong)的節點(dian)。這樣一(yi)來，客(ke)戶端才可以(yi)拿到拓撲信息進行集(ji)群(qun)的順利操作。

這(zhe)就(jiu)是整個“案(an)件(jian)”的最終答案(an)。

總(zong)結一下(xia)，對(dui)于(yu)(yu)用戶使用而言(yan)，Docker環(huan)境下(xia)搭建(jian)TDengine Database集群的水(shui)還是(shi)(shi)頗深。由于(yu)(yu)環(huan)境的相(xiang)對(dui)復雜，所以(yi)我們也并不是(shi)(shi)十分推薦大家(jia)使用這種方(fang)式搭建(jian)集群。所以(yi)，關(guan)于(yu)(yu)TDengine在Docker環(huan)境的使用，大家(jia)還是(shi)(shi)要小(xiao)心謹慎。

最后我們想說的是，作為一個開源的產品，社區的活躍與專業是我們濤思數據最為關注的地方。雖然目前官網上并沒有關于Docker環境下TDengine集群搭建的(de)文檔。但是(shi)這些(xie)社區用戶(hu)們的(de)活躍思(si)考顯然(ran)很(hen)大程(cheng)度填補了這樣的(de)一個(ge)空白。

真(zhen)心感(gan)謝Oliver，freemine，pigwing三位朋(peng)友。十分(fen)希望(wang)日后可以繼續(xu)看到你們在物聯(lian)網大數據技術前沿(yan)群中的活(huo)躍身影，同時我們也希望(wang)有更多的朋(peng)友們能夠參(can)與進(jin)來。

掃描二維碼(ma)，添加小T為好友(you)(you)，即可與各位熱衷開源的朋(peng)友(you)(you)一起在群內互動哦～

點擊“”，查看Oliver整理的(de)TDengine在Docker環境(jing)下的(de)集(ji)群搭(da)建(jian)筆(bi)記