Citus集群分片重平衡无进展，请求排查及解决方法

可能的原因分析 #

1. 分区表重平衡机制的适配问题
   你的表是分片+分区的组合结构（32分片+1200分区），Citus迁移包含多分区的分片时，需要逐个同步分区数据。而每分钟25000行的持续插入会不断生成新分区，重平衡进程可能在处理活跃分区时，因持续写入无法完成快照同步，导致进程挂起但无报错输出。

2. 重平衡并发配置不合理
   默认的citus.max_running_tasks_per_node、citus.rebalance_max_concurrent_shard_migrations等参数可能过低，加上每个分片包含大量分区，导致单任务处理速度极慢，甚至因长时间未响应被静默终止。

3. 锁竞争导致的静默阻塞
   持续插入会在源分片的分区上持有写锁，Citus分片迁移需要获取源分片的共享快照，若锁竞争过于激烈，迁移进程会无限期等待，且不会在get_rebalance_progress()中反馈异常。

4. 未排查节点底层问题
   新节点初期有磁盘/网络活动后停滞，可能是迁移过程中触发了底层限制（比如磁盘IO瓶颈、网络连接中断后未重试），但未向上层抛出错误。

解决方法 #

1. 调整重平衡并发参数 #

先修改Citus任务并发配置，提升迁移效率：

-- 根据节点CPU核心数调整，比如设为4
SET citus.max_running_tasks_per_node = 4;
-- 提升并发分片迁移数，避免单任务阻塞拖慢整体进度
SET citus.rebalance_max_concurrent_shard_migrations = 2;

修改后重启重平衡：

SELECT rebalance_table_shards('your_table_name');

2. 手动分片迁移替代自动重平衡 #

如果自动重平衡持续卡住，可逐个迁移分片规避批量操作的阻塞：

1. 查看当前分片分布：

SELECT shardid, nodename, nodeport FROM pg_dist_shard_placement WHERE logicalrelid = 'your_table_name'::regclass;

2. 选择未迁移到新节点的分片，手动执行迁移：

SELECT move_shard_placement(your_shard_id, 'old_node_host', old_node_port, 'new_node_host', new_node_port);

3. 全部完成后验证分布均衡性：

SELECT nodename, count(*) FROM pg_dist_shard_placement WHERE logicalrelid = 'your_table_name'::regclass GROUP BY nodename;

3. 临时暂停插入（业务允许时） #

持续插入是核心干扰因素，若有业务窗口，可临时切换写入流量到临时表/备用集群，待重平衡完成后恢复写入，彻底规避锁竞争问题。

4. 排查节点日志找静默错误 #

查看Coordinator和新Worker节点的PostgreSQL日志（默认路径/var/log/postgresql/），搜索rebalance、shard migration关键词，可能找到未在get_rebalance_progress()中显示的异常，比如磁盘空间不足、网络权限问题等。

5. 优化分片与分区的匹配策略（长期方案） #

当前每个分片平均包含37个分区，可调整分片键与分区键对齐（比如按天分片+按小时分区），减少单分片的分区数量，从根源提升迁移效率。

内容的提问来源于stack exchange，提问作者Kellad