TiCDC中配置 columns类型 partition 分发器不生效

🪐 TiDB 技术问题 备份&数据迁移
1

【 TiDB 使用环境】测试
【 TiDB 版本】v8.5.4
【遇到的问题：问题现象及影响】
创建 columns类型 partition 分发器 投递数据到 kafka，测试发现 partition 分发器并未按照预期结果投递， changefeeds 配置如下：

{
    "sink_uri": "kafka://xxx/tidb_binlog_topic?protocol=canal-json&kafka-version=2.8.2&max-message-bytes=67108864&replication-factor=3",
    "replica_config": {
        "filter": {
            "rules": [
                "*.*"
            ]
           
        },
         "ignore_ineligible_table": true,
        "sink": {
            "dispatchers": [
                {
                    "matcher": [
                        "*.*",
                        "!*.global_sequence"
                    ],
                    "partition": "columns",
                    "columns":["global_seq"]
                    
                }
            ]
        }
    }
}

对应的kafka topic tidb_binlog_topic 有 12个分区 ，TiDB 测试脚本如下：
begin;
update orders set global_seq =8888 where id < 2;
update products set global_seq=8888 where id < 2;
commit ;

上述 操作 将 不同表的 两行数据的 global_seq 修改为相同值 8888，理论上 按照 global_seq 分发后应该被发送到同一个分区，但查看 kafka 消息发现 两行数据变更被分发到两个分区！

image
image1583×385 76.7 KB

2

column 针对的是单表，你这里是两张表，所以有可能发送的不同的分区

3

这个的确没有用过cdc到kafka,在线学习下这个kafka

4

哈希计算时会隐含加入「表的唯一标识（table ID 或库表名哈希）」，确保不同表的相同列值不会强制路由到同一分区（避免单分区热点） . orders 和 products 是不同表，即使 global_seq=8888 相同，因表标识不同，最终哈希结果不同，导致分区不同 —— 这是 TiCDC 的设计逻辑 ，而非配置错误。

5

可以通过 crc32(concat(global_seq, '_', substr(table_name, 1, 3))) % 12 这类表达式，既保证相同 global_seq 大概率同分区，又避免单分区热点

6

感谢老师分享

7

查了一下源码 downstreamadapter/sink/eventrouter/partition/columns.go， columns或 index-value 分发器 会先 写入schema/table 到 hasher（保证不同表不会混淆），然后在结合 columns或index值 计算 partitionNum。

8

此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。