常見問題
常見問題
一般問題
如何查詢我的IoTDB版本？
有幾種方法可以識別您使用的 IoTDB 版本：
- 啟動 IoTDB 的命令行界面：
> ./start-cli.sh -p 6667 -pw root -u root -h localhost
_____ _________ ______ ______
|_ _| | _ _ ||_ _ `.|_ _ \
| | .--.|_/ | | \_| | | `. \ | |_) |
| | / .'`\ \ | | | | | | | __'.
_| |_| \__. | _| |_ _| |_.' /_| |__) |
|_____|'.__.' |_____| |______.'|_______/ version x.x.x- 檢查 pom.xml 文件：
<version>x.x.x</version>- 使用 JDBC API:
String iotdbVersion = tsfileDatabaseMetadata.getDatabaseProductVersion();- 使用命令行接口：
IoTDB> show version
show version
+---------------+
|version |
+---------------+
|x.x.x |
+---------------+
Total line number = 1
It costs 0.241s在哪里可以找到IoTDB的日志？
假設您的根目錄是：
$ pwd
/workspace/iotdb
$ ls -l
server/
cli/
pom.xml
Readme.md
...假如 $IOTDB_HOME = /workspace/iotdb/server/target/iotdb-server-{project.version}
假如 $IOTDB_CLI_HOME = /workspace/iotdb/cli/target/iotdb-cli-{project.version}
在默認的設置里，logs 文件夾會被存儲在IOTDB_HOME/logs。您可以在IOTDB_HOME/conf目錄下的logback.xml文件中修改日志的級別和日志的存儲路徑。
在哪里可以找到IoTDB的數據文件？
在默認的設置里，數據文件（包含 TsFile，metadata，WAL）被存儲在IOTDB_HOME/data/datanode文件夾。
如何知道IoTDB中存儲了多少時間序列？
使用 IoTDB 的命令行接口：
IoTDB> show timeseries在返回的結果里，會展示Total timeseries number，這個數據就是 IoTDB 中 timeseries 的數量。
在當前版本中，IoTDB 支持直接使用命令行接口查詢時間序列的數量：
IoTDB> count timeseries如果您使用的是 Linux 操作系統，您可以使用以下的 Shell 命令：
> grep "0,root" $IOTDB_HOME/data/system/schema/mlog.txt | wc -l
> 6可以使用Hadoop和Spark讀取IoTDB中的TsFile嗎？
是的。IoTDB 與開源生態緊密結合。IoTDB 支持 Hadoop, Spark 和 Grafana 可視化工具。
IoTDB如何處理重復的數據點？
一個數據點是由一個完整的時間序列路徑（例如：root.vehicle.d0.s0) 和時間戳唯一標識的。如果您使用與現有點相同的路徑和時間戳提交一個新點，那么 IoTDB 將更新這個點的值，而不是插入一個新點。
我如何知道具體的timeseries的類型？
在 IoTDB 的命令行接口中使用 SQL SHOW TIMESERIES <timeseries path>:
例如：如果您想知道所有 timeseries 的類型 <timeseries path> 應該為 root.**。上面的 SQL 應該修改為：
IoTDB> show timeseries root.**如果您想查詢一個指定的時間序列，您可以修改 <timeseries path> 為時間序列的完整路徑。比如：
IoTDB> show timeseries root.fit.d1.s1您還可以在 timeseries 路徑中使用通配符：
IoTDB> show timeseries root.fit.d1.*如何更改IoTDB的客戶端時間顯示格式？
IoTDB 客戶端默認顯示的時間是人類可讀的（比如：1970-01-01T08:00:00.001)，如果您想顯示是時間戳或者其他可讀格式，請在啟動命令上添加參數-disableISO8601:
> $IOTDB_CLI_HOME/sbin/start-cli.sh -h 127.0.0.1 -p 6667 -u root -pw root -disableISO8601怎么處理來自org.apache.ratis.grpc.server.GrpcLogAppender的IndexOutOfBoundsException？
這是我們的依賴Ratis 2.4.1的一個內部錯誤日志，不會對數據寫入和讀取造成任何影響。
已經報告給Ratis社區，并會在未來的版本中修復。
預估內存不足報錯如何處理？
報錯信息：
301: There is not enough memory to execute current fragment instance, current remaining free memory is 86762854, estimated memory usage for current fragment instance is 270139392報錯分析：
datanode_memory_proportion參數控制分給查詢的內存，chunk_timeseriesmeta_free_memory_proportion參數控制查詢執行可用的內存。
默認情況下分給查詢的內存為堆內存*30%，查詢執行可用的內存為查詢內存的20%。
報錯顯示當前剩余查詢執行可用內存為86762854B=82.74MB，該查詢預估使用執行內存270139392B=257.6MB。
一些可能的改進項：
- 在不改變默認參數的前提下，調大IoTDB的堆內存大于 4.2G（4.2G * 1024MB=4300MB），4300M*30%*20%=258M>257.6M，可以滿足要求。
- 更改 datanode_memory_proportion 等參數，使查詢執行可用內存>257.6MB。
- 減少導出的時間序列數量。
- 給查詢語句添加 slimit 限制，也是減少查詢時間序列的一種方案。
- 添加 align by device，會按照device順序進行輸出，內存占用會降低至單device級別。
分布式部署 FAQ
集群啟停
ConfigNode初次啟動失敗，如何排查原因？
- ConfigNode初次啟動時確保已清空data/confignode目錄
- 確保該ConfigNode使用到的<IP+端口>沒有被占用，沒有與已啟動的ConfigNode使用到的<IP+端口>沖突
- 確保該ConfigNode的cn_seed_config_node（指向存活的ConfigNode；如果該ConfigNode是啟動的第一個ConfigNode，該值指向自身）配置正確
- 確保該ConfigNode的配置項（共識協議、副本數等）等與cn_seed_config_node對應的ConfigNode集群一致
ConfigNode初次啟動成功，show cluster的結果里為何沒有該節點？
- 檢查cn_seed_config_node是否正確指向了正確的地址； 如果cn_seed_config_node指向了自身，則會啟動一個新的ConfigNode集群
DataNode初次啟動失敗，如何排查原因？
- DataNode初次啟動時確保已清空data/datanode目錄。 如果啟動結果為“Reject DataNode restart.”則表示啟動時可能沒有清空data/datanode目錄
- 確保該DataNode使用到的<IP+端口>沒有被占用，沒有與已啟動的DataNode使用到的<IP+端口>沖突
- 確保該DataNode的dn_seed_config_node指向存活的ConfigNode
移除DataNode執行失敗，如何排查？
- 檢查remove-datanode腳本的參數是否正確，是否傳入了正確的ip:port或正確的dataNodeId
- 只有集群可用節點數量 > max(元數據副本數量, 數據副本數量)時，移除操作才允許被執行
- 執行移除DataNode的過程會將該DataNode上的數據遷移到其他存活的DataNode，數據遷移以Region為粒度，如果某個Region遷移失敗，則被移除的DataNode會一直處于Removing狀態
- 補充：處于Removing狀態的節點，其節點上的Region也是Removing或Unknown狀態，即不可用狀態。 該Remvoing狀態的節點也不會接受客戶端的請求。如果要使Removing狀態的節點變為可用，用戶可以使用set system status to running 命令將該節點設置為Running狀態；如果要使遷移失敗的Region處于可用狀態，可以使用migrate region from datanodeId1 to datanodeId2 命令將該不可用的Region遷移到其他存活的節點。另外IoTDB后續也會提供
remove-datanode.sh -f命令，來強制移除節點（遷移失敗的Region會直接丟棄）
掛掉的DataNode是否支持移除？
- 當前集群副本數量大于1時可以移除。 如果集群副本數量等于1，則不支持移除。 在下個版本會推出強制移除的命令
從0.13升級到1.0需要注意什么？
- 0.13版本與1.0版本的文件目錄結構是不同的，不能將0.13的data目錄直接拷貝到1.0集群使用。如果需要將0.13的數據導入至1.0，可以使用LOAD功能
- 0.13版本的默認RPC地址是0.0.0.0，1.0版本的默認RPC地址是127.0.0.1
集群重啟
如何重啟集群中的某個ConfigNode？
- 第一步：通過
stop-confignode.sh或kill進程方式關閉ConfigNode進程 - 第二步：通過執行
start-confignode.sh啟動ConfigNode進程實現重啟 - 下個版本IoTDB會提供一鍵重啟的操作
如何重啟集群中的某個DataNode？
- 第一步：通過
stop-datanode.sh或kill進程方式關閉DataNode進程 - 第二步：通過執行
start-datanode.sh啟動DataNode進程實現重啟 - 下個版本IoTDB會提供一鍵重啟的操作
將某個ConfigNode移除后（remove-confignode），能否再利用該ConfigNode的data目錄重啟？
- 不能。會報錯：Reject ConfigNode restart. Because there are no corresponding ConfigNode(whose nodeId=xx) in the cluster.
將某個DataNode移除后（remove-datanode），能否再利用該DataNode的data目錄重啟？
- 不能正常重啟，啟動結果為“Reject DataNode restart. Because there are no corresponding DataNode(whose nodeId=xx) in the cluster. Possible solutions are as follows:...”
用戶看到某個ConfigNode/DataNode變成了Unknown狀態，在沒有kill對應進程的情況下，直接刪除掉ConfigNode/DataNode對應的data目錄，然后執行start-confignode.sh/start-datanode.sh，這種情況下能成功嗎?
- 無法啟動成功，會報錯端口已被占用
集群運維
Show cluster執行失敗，顯示“please check server status”，如何排查?
- 確保ConfigNode集群一半以上的節點處于存活狀態
- 確保客戶端連接的DataNode處于存活狀態
某一DataNode節點的磁盤文件損壞，如何修復這個節點?
- 當前只能通過remove-datanode的方式進行實現。remove-datanode執行的過程中會將該DataNode上的數據遷移至其他存活的DataNode節點（前提是集群設置的副本數大于1）
- 下個版本IoTDB會提供一鍵修復節點的功能
如何降低ConfigNode、DataNode使用的內存？
- 在conf/confignode-env.sh、conf/datanode-env.sh文件可通過調整ON_HEAP_MEMORY、OFF_HEAP_MEMORY等選項可以調整ConfigNode、DataNode使用的最大堆內、堆外內存