[Bug] IoTDB Partition Bug in Version 2.0.5 #17030
Description
Search before asking
- I searched in the issues and found nothing similar.
Version
IoTDB Version: 2.0.5 official docker container
=== SYSTEM INFORMATION ===
Linux ecs01 6.8.0-79-generic #79-Ubuntu SMP PREEMPT_DYNAMIC Tue Aug 12 14:42:46 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux
Distributor ID: Ubuntu
Description: Ubuntu 24.04.3 LTS
Release: 24.04
Codename: noble
=== HARDWARE INFORMATION ===
Memory:
total used free shared buff/cache available
Mem: 62Gi 6.7Gi 29Gi 118Mi 27Gi 56Gi
Swap: 0B 0B 0B
CPU:
Architecture: x86_64
CPU(s): 16
On-line CPU(s) list: 0-15
Model name: AMD EPYC 9634 84-Core Processor
BIOS Model name: pc-i440fx-6.2 CPU @ 2.0GHz
NUMA node0 CPU(s): 0-15
Disk space (root):
/dev/vda3 2.0T 32G 1.9T 2% /
=== DOCKER INFORMATION ===
Docker version 28.4.0, build d8eb465
+------+----------+-------+---------------+------------+-------+---------+
|NodeID| NodeType| Status|InternalAddress|InternalPort|Version|BuildInfo|
+------+----------+-------+---------------+------------+-------+---------+
| 0|ConfigNode|Running| confignode1| 10710| 2.0.5| 0917050|
| 3|ConfigNode|Running| confignode2| 10710| 2.0.5| 0917050|
| 1| DataNode|Running| datanode1| 10730| 2.0.5| 0917050|
| 2| DataNode|Running| datanode2| 10730| 2.0.5| 0917050|
+------+----------+-------+---------------+------------+-------+---------+
Total line number = 5
It costs 0.005s
IoTDB> SHOW databases;
+----------------+-----------------------+---------------------+-------------------+---------------------+
| Database|SchemaReplicationFactor|DataReplicationFactor|TimePartitionOrigin|TimePartitionInterval|
+----------------+-----------------------+---------------------+-------------------+---------------------+
|root.electricity| 1| 1| 0| 604800000|
+----------------+-----------------------+---------------------+-------------------+---------------------+
Total line number = 1
It costs 0.031s
Describe the bug and provide the minimal reproduce step
Description
IoTDB incorrectly prunes partitions when querying time ranges (also in epoch format), resulting in empty results for valid queries. The issue appears to be related to corrupted or incorrect partition metadata.
Steps to Reproduce
IoTDB>SELECT Wh_in FROM root.electricity.measured.1m.REDC21620CDADC WHERE time >= 2026-01-01T00:00:00.000 AND time < 2026-01-08T00:00:00.000;
+----+-------------------------------------------------+
|Time|root.electricity.measured.1m.REDC21620CDADC.Wh_in|
+----+-------------------------------------------------+
+----+-------------------------------------------------+
Empty set.
It costs 0.004s
IoTDB> SELECT Wh_in FROM root.electricity.measured.1m.REDC21620CDADC WHERE time >= 2026-01-01T00:00:00.000 AND time < 2026-01-09T00:00:00.000;
+------------------------+-------------------------------------------------+
| Time|root.electricity.measured.1m.REDC21620CDADC.Wh_in|
+------------------------+-------------------------------------------------+
|2026-01-01T00:00:00.000Z| 1.0756308|
|2026-01-01T00:01:00.000Z| 1.081479|
|2026-01-01T00:02:00.000Z| 1.0312717|
|2026-01-01T00:03:00.000Z| 1.0825367|
|2026-01-01T00:04:00.000Z| 0.9839263|
|2026-01-01T00:05:00.000Z| 1.0742621|
|2026-01-01T00:06:00.000Z| 1.0643699|
|2026-01-01T00:07:00.000Z| 1.0771862|
|2026-01-01T00:08:00.000Z| 1.0795504|
|2026-01-01T00:09:00.000Z| 1.0848386|
|2026-01-01T00:10:00.000Z| 1.0043327|
|2026-01-01T00:11:00.000Z| 1.0071946|
IoTDB> explain SELECT Wh_in FROM root.electricity.measured.1m.REDC21620CDADC WHERE time >= 2026-01-01T00:00:00.000 AND time < 2026-01-08T00:00:00.000;
+-----------------------------------------------------------+
| distribution plan|
+-----------------------------------------------------------+
|┌─────────────────────────────────────────────────────────┐|
|│SeriesScan-1 │|
|│Series: root.electricity.measured.1m.REDC21620CDADC.Wh_in│|
|│ScanOrder: ASC │|
|│Partition: Not Assigned │|
|└─────────────────────────────────────────────────────────┘|
+-----------------------------------------------------------+
Total line number = 6
It costs 0.004s
IoTDB> explain SELECT Wh_in FROM root.electricity.measured.1m.REDC21620CDADC WHERE time >= 2026-01-01T00:00:00.000 AND time < 2026-01-09T00:00:00.000;
+-----------------------------------------------------------+
| distribution plan|
+-----------------------------------------------------------+
|┌─────────────────────────────────────────────────────────┐|
|│SeriesScan-1 │|
|│Series: root.electricity.measured.1m.REDC21620CDADC.Wh_in│|
|│ScanOrder: ASC │|
|│Partition: 4 │|
|└─────────────────────────────────────────────────────────┘|
+-----------------------------------------------------------+
Total line number = 6
It costs 0.005s
What did you expect to see?
Expected Behavior
Both queries should return the same data for the overlapping time range (2026-01-01 to 2026-01-07).
What did you see instead?
Actual Behavior
Query with end time < 2026-01-09: Returns empty set
Query with end time >= 2026-01-09: Returns correct data (including data with time < 2026-01-09) missing in the previous query
Example with another range:
IoTDB> SELECT Wh_in FROM root.electricity.measured.1m.REDC21620CDADC WHERE time >= 1764543600000 AND time < 1767222000000;
+----+-------------------------------------------------+
|Time|root.electricity.measured.1m.REDC21620CDADC.Wh_in|
+----+-------------------------------------------------+
+----+-------------------------------------------------+
Empty set.
It costs 0.012s
IoTDB>
In this case simply removing the time < 1767222000000 condition I can retrieve the data (including the data with time >= 1764543600000 AND time < 1767222000000 missing in the previous query)
IoTDB> SELECT Wh_in FROM root.electricity.measured.1m.REDC21620CDADC WHERE time >= 1764543600000;
+------------------------+-------------------------------------------------+
| Time|root.electricity.measured.1m.REDC21620CDADC.Wh_in|
+------------------------+-------------------------------------------------+
|2025-11-30T23:00:00.000Z| 1.4880524|
|2025-11-30T23:01:00.000Z| 1.438405|
|2025-11-30T23:02:00.000Z| 1.4517189|
|2025-11-30T23:03:00.000Z| 1.4238467|
|2025-11-30T23:04:00.000Z| 1.3950413|
|2025-11-30T23:05:00.000Z| 1.3992097|
|2025-11-30T23:06:00.000Z| 1.3678535|
|2025-11-30T23:07:00.000Z| 1.3358752|
|2025-11-30T23:08:00.000Z| 1.2472813|
|2025-11-30T23:09:00.000Z| 1.3025903|
|2025-11-30T23:10:00.000Z| 1.2923248|
|2025-11-30T23:11:00.000Z| 1.1174392|
|2025-11-30T23:12:00.000Z| 1.023246|
|2025-11-30T23:13:00.000Z| 0.9979246|
|2025-11-30T23:14:00.000Z| 1.0176467|
|2025-11-30T23:15:00.000Z| 1.0394218|
|2025-11-30T23:16:00.000Z| 1.381914|
IoTDB> explain SELECT Wh_in FROM root.electricity.measured.1m.REDC21620CDADC WHERE time >= 1764543600000 AND time < 1767222000000;
+-----------------------------------------------------------+
| distribution plan|
+-----------------------------------------------------------+
|┌─────────────────────────────────────────────────────────┐|
|│SeriesScan-1 │|
|│Series: root.electricity.measured.1m.REDC21620CDADC.Wh_in│|
|│ScanOrder: ASC │|
|│Partition: Not Assigned │|
|└─────────────────────────────────────────────────────────┘|
+-----------------------------------------------------------+
Total line number = 6
It costs 0.005s
IoTDB> explain SELECT Wh_in FROM root.electricity.measured.1m.REDC21620CDADC WHERE time >= 1764543600000;
+-----------------------------------------------------------+
| distribution plan|
+-----------------------------------------------------------+
|┌─────────────────────────────────────────────────────────┐|
|│SeriesScan-1 │|
|│Series: root.electricity.measured.1m.REDC21620CDADC.Wh_in│|
|│ScanOrder: ASC │|
|│Partition: 4 │|
|└─────────────────────────────────────────────────────────┘|
+-----------------------------------------------------------+
Total line number = 6
It costs 0.006s
IoTDB>
Anything else?
Root Cause Analysis
The partition logic appears to be incorrectly determining that no partitions contain data for certain time ranges, even though data exists. The issue seems to be:
Partition metadata is corrupted or incorrectly calculated
Query optimizer makes wrong decisions based on this metadata
Different time range thresholds trigger different partition assignments
This appears to be a critical bug affecting data retrieval reliability
Are you willing to submit a PR?
- I'm willing to submit a PR!