Lightdb分布式版问题锦集 - hslightdb/LightDB-FAQ GitHub Wiki

1. 分布式表在协调节点上会有数据存储吗

如果是普通表则会在协调节点上存储。

2. 计算和存储节点如何扩容缩容，扩缩容后，存储节点的数据是会自动平衡吗，数据平衡过程中对集群性能的影响

SELECT rebalance_table_shards();

执行此操作进行重平衡，最好在业务低时添加，因为会有磁盘IO、CPU等消耗。

3. 数据缓存是在协调节点，还是工作节点上的局部缓存

存储在工作节点上。

4. LightDB分布式表创建

需要通过下面命令将普通表改为分布式表，

SELECT create_distributed_table('table_name', 'dist_column');

有业务侵入，要制定合理的分片键，分片键不合理有性能下降的可能。

5. 大表在业务上没有设计分区键，查询逻辑可能会扫描表，这种情况是用单机数据库，还是用分区键（比如主键）的分布式表

建议还是要添加分区键做转换成分布式表处理，负载可以分配到多个节点，如果实在加不了，只能单实例运行。

6. 分片键的要求

报错：DETAIL: Distributed relations cannot have UNIQUE, EXCLUDE, or PRIMARY KEY constraints that do not include the partition column (with an equality operator if EXCLUDE).

唯一约束必须包含分片键。

这个错误提示在 Canopy 中创建了一个分布式表，并且在表上定义了 UNIQUE、EXCLUDE 或 PRIMARY KEY 约束，但约束中没有包含分区列（或分区列的一部分），因此 Canopy 无法在分布式环境中正确地强制执行这些约束。

在 Canopy 中，数据通常被分区并存储在不同的节点上，每个节点上存储的数据子集只能部分地表示分布式表的完整数据集。这就需要 Canopy 在整个分布式集群上保证数据一致性和正确性，因此 Canopy 需要在分布式表上使用分区键或分区键的一部分来定义这些约束。

例如，假设我们有一个表 orders，其分区键为 order_id，并且我们想在该表上定义一个唯一约束，以确保每个订单 ID 都是唯一的。在 Canopy中，我们应该将分区键 order_id 包含在唯一约束中，这样 Canopy 才能确保唯一性约束适用于整个分布式表的所有节点，从而避免重复数据在不同的节点上出现。

因此，当您在 Canopy 中创建分布式表并定义 UNIQUE、EXCLUDE 或 PRIMARY KEY 约束时，请确保这些约束包括分区键或分区键的一部分，以确保约束可以在整个分布式集群上正确地强制执行。如果没有包含分区键或分区键的一部分，则会出现您所描述的错误提示。

解决方案参考 https://www.modb.pro/db/615790

7. 分布式表和本地表不支持直接join

报错：SQL 错误 [0A000]: ERROR: direct joins between distributed and local tables are not supported

Hint: Use CTE's or subqueries to select from local tables and use them in joins

这个错误提示是因为 Canopy不支持在分布式表和本地表之间进行直接连接操作。

在 Canopy中，分布式表是由多个节点上的数据子集组成的，而本地表只存在于单个节点上。由于分布式表和本地表之间的数据分布不同，Canopy不能有效地执行这种连接操作。

相反，您可以使用公共表表达式 (CTE) 或子查询来从本地表中选择数据，然后将其与分布式表连接。例如：

WITH local_data AS (

SELECT *

FROM my_local_table

)

SELECT *

FROM my_distributed_table

JOIN local_data ON my_distributed_table.key = local_data.key

上面的示例中，我们首先使用 CTE 选择本地表中的数据，然后将其与分布式表进行连接。这种方法可以避免直接连接分布式表和本地表，从而避免了错误提示。

总之，在 Canopy中连接分布式表和本地表时，您应该使用 CTE 或子查询来选择本地表数据，并将其与分布式表进行连接，而不是直接连接它们。这可以确保 Canopy在分布式集群中正确执行查询，并避免出现错误提示。

解决方案参考 https://www.modb.pro/db/615781

8. 复杂连接的支持

报错：ERROR: complex joins are only supported when all distributed tables are co-located and joined on their distribution columns

当所有分布式表都在同一个节点上并且使用它们的分布列进行连接时，才支持复杂连接。

解决方案参考 https://www.modb.pro/db/615963 https://www.modb.pro/db/616553

9. 分布式事务并行报错

报错：Cause: org.postgresql.util.PSQLException: ERROR: Query could not find the intermediate result file "15_1", it was mostly likely deleted due to an error in a parallel process within the same distributed transaction

这个报错信息是由 PostgreSQL 分布式查询引擎产生的，意思是查询无法找到一个名为 "15_1" 的中间结果文件，很可能是由于在同一分布式事务内的并行进程中发生错误而被删除。

这种错误通常发生在一个并行查询被拆分成多个子查询，并行地在不同节点上执行，每个节点生成一部分结果，这些结果最后被合并为最终结果。在这个过程中，每个节点都会将它们的结果存储在本地磁盘上的临时文件中，然后将这些文件上传到协调节点以进行合并。

当一个并行进程出现错误时，可能会导致该进程创建的中间结果文件被意外删除。这会导致其他进程无法访问该文件，从而导致查询失败并报告上述错误。

解决这个问题的方法通常是重新运行查询。如果错误继续发生，可能需要检查系统日志以查找其他有关错误原因的信息。此外，还可以尝试减少并行度或增加节点间通信的时间间隔，以避免并行查询中的竞争条件。

解决方案参考 https://www.modb.pro/db/615991

10. no password supplied报错信息

报错：Caused by: org.postgresql.util.PSQLException: ERROR: connection to the remote node 10.101.0.122:5432 failed with the following error: fe_sendauth: no password supplied at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2676) ~[postgresql-42.5.1.jar!/:42.5.1]

给应用分配的数据库用户是需要手工在DN的$LTDATA/lt_hba.conf的配置文件中增加trust

DN的$LTDATA/lt_hba.conf md5->trust

例如数据库用户名是jydb，DN上的lt_hba.conf配置是需要增加下面3行 host all jydb CN_IP/32 trust host all jydb DN1_IP/32 trust host all jydb DN2_IP/32 trust

lt_ctl -D /data/lightdb_data reload即可，不用重启实例