遷移背景

隨著時序數據庫（Time Series Database） TDengine 3.0 的發布至今，我們除了在持續地優化產品質量的本身，也一直在努力地提升用戶體驗。但由于 3.0 底層有大量的重構優化，導致開源版的 2.0 用戶無法通過常規途徑來升級到 3.0 ，本期文章將會協助大部分開源版用戶解決這個問題。
目前，我們可以(yi)提(ti)供兩種(zhong)遷(qian)移方案：

1. TDengine 官方工具 taosdump；
2. 開源數據遷移解決方案：dataX TDengine reader/writter；

前(qian)者會(hui)把數據根據配置導出壓縮存儲到本(ben)地，產品屬(shu)性(xing)更傾(qing)向于(yu)備份/恢復工具。后(hou)者則會(hui)在內存中直接傳輸數據，偏向數據遷移工具。本(ben)篇(pian)文(wen)章(zhang)的主體為前(qian)者的 taosdump，dataX 的使用(yong)方式(shi)可以(yi)通過這(zhe)篇(pian)文(wen)章(zhang)來了解：//yakult-sh.com.cn/engineering/16401.html

首先(xian)，我們(men)先(xian)說下(xia) taosdump 為(wei)什么是協(xie)助“大(da)部(bu)分”開源版用戶(hu)解決(jue)這個問題：

taosdump 的導(dao)出(chu)行為的本(ben)質其實是使(shi)用(yong) SQL 進行查詢，將數(shu)(shu)據(ju)壓縮后(hou)輸出(chu)到本(ben)地，導(dao)入行為則是通(tong)過 STMT 接口(kou)再把導(dao)出(chu)的數(shu)(shu)據(ju)導(dao)入新的環境(jing)。在內部(bu)，它嵌入了(le)一個(ge) TDengine 客(ke)戶端，通(tong)過 -T 參數(shu)(shu)的線程數(shu)(shu)配(pei)置，并(bing)發地把所(suo)有 SQL 請求發給數(shu)(shu)據(ju)庫(ku)，此后(hou)，后(hou)續的查詢工作(zuo)就是數(shu)(shu)據(ju)庫(ku)自己(ji)的事情了(le)。鑒于以上原因，所(suo)以它的導(dao)出(chu)導(dao)入的性能都十分(fen)依賴于數(shu)(shu)據(ju)庫(ku)本(ben)身的部(bu)署建模是否(fou)(fou)科(ke)學，硬件資(zi)源(yuan)是否(fou)(fou)充足(zu)等因素。

舉(ju)個簡單例子：假(jia)如某用戶(hu)在建表的(de)時(shi)(shi)候(hou)，對(dui)于一(yi)列(lie)本(ben)應使用 binary(100) 就(jiu)足夠(gou)的(de)數據使用了(le) nchar(2000)，那么等到導出 SQL 執行的(de)時(shi)(shi)候(hou)，性(xing)能(neng)就(jiu)會被拖累(lei)很多。

因(yin)此，能夠(gou)順(shun)利完成數據導出的(de)用戶，應(ying)盡(jin)量擁(yong)有(you)如下幾個特征：

1. 擁有足夠磁盤空間——因為硬盤上的數據是列式壓縮，而導出數據為行式壓縮。如果選擇一次性導出全部數據，建議需要至少留出 du -sh $dataDir/vnode –exclude=’wal’ 大小的 3 倍空間（多多益善）。但如果是按照庫/表為單位分批導出，或者指定時間范圍導出的話，就比較靈活了。
   
2. 數據庫日常使用負載不高，在大量導出 SQL 執行時，數據庫仍有充足資源可以保障正常生產使用。
   
3. 待遷移的 2.0 數據為測試環境不需擔心影響業務，或者生產環境的業務間歇期足夠完成數據的導出——這兩點需要結合當前導出速度自己評估。

總結

導(dao)出/導(dao)入(ru)數(shu)據的快(kuai)慢(man)是(shi)由 SQL 執行效率(lv)來決定的，而(er) SQL執行效率(lv)的背后又是(shi)由部(bu)署建模(mo)，硬件資(zi)源等因素決定的。

只要(yao)磁盤空間充(chong)足(zu)，時間充(chong)足(zu)，就(jiu)可以完(wan)成導出操作。導入則相對簡單(dan)，沒有額外需求(qiu)，按照正(zheng)常的數據(ju)庫部署思路即可。

因(yin)(yin)為 taosdump 本身的產品特征決(jue)定了(le)在上述(shu)特殊情況(kuang)下，遷(qian)移數據會有效率問(wen)題，因(yin)(yin)此這(zhe)也(ye)是(shi)我們開發專業的企業版數據遷(qian)移工具 taosX 的原(yuan)因(yin)(yin)之(zhi)一。

遷移操作

導出方：

對于 2.0 一側，首先要(yao)準備(bei)好最新版本的 TDengine 和 taosdump 工具，具體操作(zuo)如下：

1. 把數據庫升級到 2.6.0.34，升級注意事項以及操作步驟都可以參考這篇文章：//yakult-sh.com.cn/engineering/10222.html。（注意：RPM 和 Deb 包不含 taosdump ，它需要通過安裝 taosTools 包獲得。所以建議大家直接使用包含 TDengine 的 Tar 包完成升級。）TDengine 安裝包需從 2.6 版本的文檔去下載：//yakult-sh.com.cn/all-downloads 。如果使用了 RPM 和 Deb 的話，同樣需要通過上述鏈接下載最新版的 taostool 獲取 taosdump工具（當前最新版為 2.4.5）。
2. 使用 taosdump 把數據導出：具體操作可參考：。舉例：

taosdump -o /test  -D test  -T 4

這(zhe)條(tiao)命令(ling)會把(ba) test 庫(ku)的數據，用 4 個線(xian)程導(dao)出到 /test 目錄下面(mian)，文件形式如下：

接下(xia)來，我(wo)們需要把 test 路徑下(xia)的(de)導出文(wen)件(jian)，遷移(yi)到 3.0 的(de)環(huan)境(jing)中，準備數據導入。

導入方：

1. 3.0 這一側，新環境我們建議使用最新版，各方面都更好（當前最新版為 3.0.4.1），正常安裝部署即可。（同樣：RPM 和 Deb 包不含 taosdump ，它需要通過安裝 taosTools 包獲得。 所以建議大家直接使用包含 taosdump 的 tar 包完成部署，下載鏈接：）但是如果只能使用 RPM 或者 Deb ，taosTools 則需要從 3.0 的文檔單獨下載，地址： （當前最新版為 2.5.0）
   
2. 導入之前，我們首先要進入導出文件目錄下的標紅目錄，打開里面的 dbs.sql，針對建庫 SQL 做一些針對性的調整。尤其需要注意的是 VGROUPS 參數，這是 3.0 的新增參數，代替了此前 2.0 的一系列建表邏輯，默認是 2 ，代表著這個庫有 2 個 VGROUP 。如果原本的 2.0 環境使用了 4 個 VGROUP，那么就需要手動添加 “VGROUPS 4” 到建庫語句后面，即可保持和 2.0 版本一樣的 VGROUP 數量了。（其他參數同理，直接在建庫 SQL 后添加即可，至于該語句中 2.0 時代的舊參數則會被導入程序自動屏蔽掉。具體的 3.0 建庫參數細節可參考：）

示例：

原本的建庫語句：

CREATE DATABASE IF NOT EXISTS test REPLICA 1  QUORUM 1 DAYS 10 KEEP 3650 CACHE 16 BLOCKS 6 FSYNC 3000  PRECISION 'ms'  MINROWS 100 MAXROWS 4096 COMP 2 ;

添加參數后：

CREATE DATABASE IF NOT EXISTS test REPLICA 1  QUORUM 1 DAYS 10 KEEP 3650 CACHE 16 BLOCKS 6 FSYNC 3000  PRECISION 'ms'  MINROWS 100 MAXROWS 4096 COMP 2 VGROUPS 4;

修改完 dbs.sql 后，便可以執行導入(ru)(ru)操作了，導入(ru)(ru)操作本身(shen)是(shi)比較簡(jian)單的(de)，具體操作可參考：。舉例：

這條命令會把 /test 目錄下的數據(ju)，用 4 個線(xian)程導入到當前環境(jing)下面，地(di)址(zhi)默(mo)認(ren)為 localhost，線(xian)程數可(ke)根據(ju)機器配置酌情設置。

導入完(wan)畢(bi)之后(hou)檢驗數據內容(rong)，確(que)認無誤之后(hou)，開源版 TDengine 2.0 至 3.0 數據遷移便(bian)完(wan)成了(le)。

如果上述(shu)兩種遷(qian)移(yi)方案都(dou)不能幫(bang)助我們完成(cheng)數據遷(qian)移(yi)，歡(huan)迎聯系 TDengine 企業(ye)版團(tuan)隊(dui)做定(ding)制化的(de)支持(chi)服務。