Manticore Search分布式查询中重复ID导致崩溃问题解析

问题背景

在Manticore Search这个开源搜索引擎中，当数据表中存在重复ID的记录时，通过分布式表执行查询操作会导致服务崩溃。这个问题不仅影响实时表(RT表)，也影响普通表(plain表)，因为普通表允许用户自行控制ID重复问题。

问题重现

这个问题可以通过两种方式重现：

1. 实时表重现方式：

-- 创建表并插入重复ID数据
CREATE TABLE t(f text);
REPLACE INTO t VALUES(2, 'a');
FLUSH RAMCHUNK t;
REPLACE INTO t VALUES(10000000000000000000, 'a'),(2, 'a');

-- 创建分布式表并查询
CREATE TABLE d TYPE='distributed' AGENT='localhost:9312:t';
SELECT * FROM d WHERE id = 2;  -- 这里会导致崩溃

2. 普通表重现方式： 通过配置文件创建包含重复ID的CSV数据源：

source src {
    type = csvpipe
    csvpipe_command = echo "1,abc" && echo "1,def"
    csvpipe_field = F
}

table t {
    type = plain
    source = src
    path = /tmp/plain
}

table d {
    type = distributed
    agent = 127.0.0.1:19312:t
}

技术分析

这个问题的核心在于分布式查询处理过程中对重复ID的处理机制存在缺陷。当分布式表代理查询到本地表时，如果本地表包含重复ID记录，在结果聚合阶段会出现内存访问越界，导致服务崩溃。

从技术栈回溯来看，崩溃发生在RemotesGetField函数中，这是分布式查询结果处理的关键环节。该函数未能正确处理来自不同分片的重复ID记录，导致内存访问异常。

影响范围

这个问题影响所有版本的Manticore Search，特别是在以下场景：

1. 用户手动创建了包含重复ID的普通表
2. 在7.0.0版本中创建的实时表可能存在重复ID问题(虽然7.0.1已修复创建重复ID的问题，但已存在的重复ID仍会导致崩溃)

解决方案

开发团队已经修复了这个问题，主要改进包括：

1. 在分布式查询结果聚合阶段增加了对重复ID的健壮性检查
2. 确保即使存在重复ID，查询也能正常返回结果而不会崩溃

需要注意的是，虽然服务不再崩溃，但分布式表和本地表对重复ID的查询结果展示仍存在细微差异(本地表会显示完整记录，而分布式表可能在某些字段上显示为空)。这是预期行为，因为分布式系统需要权衡一致性和可用性。

最佳实践建议

为避免此类问题，建议用户：

1. 尽量避免在表中创建重复ID的记录
2. 如果必须使用重复ID，确保所有相关字段值也完全相同
3. 升级到包含此修复的最新版本
4. 对于已存在重复ID的表，考虑重建表结构消除重复

这个问题再次提醒我们，在分布式系统中处理数据一致性需要特别谨慎，特别是在主键设计和查询处理方面。