SQL YugabyteDB 的 tablet splitting 与负载均衡自动调整实践

yugabytedb 的 tablet splitting 后负载不均，因 split 与负载均衡异步：split 按 range 切分并注册新 tablet，但 loadbalancer 默认每 5 分钟检查一次，仅对偏离均值 2 倍以上的节点触发迁移；可手动执行 yb-admin trigger_load_balancing 加入下轮调度，但迁移本身受副本数、网络及 raft 同步影响，需数秒至十几秒；若 split 过于激进（如热点写入导致连续切分），易引发 tablet 数爆炸，建议建表时预设 split into n tablets 并监控总数（超 5000 需警惕）；跨 az 部署下，新 tablet 副本可能暂未满足 placement policy，需确保各 zone 至少 3 个 tserver 且 –placement_num_replicas 合理；split 窗口期的 “tablet not found” 错误属正常重试场景，依赖客户端 driver 自动重定向。

tablet splitting 触发后数据不均匀，为什么负载均衡没立刻跟上

YugabyteDB 的 tablet splitting 是按范围（range）切分的，切完新 tablet 会注册进集群，但不会自动触发立即重平衡。负载均衡器（yb-master 中的 LoadBalancer 模块）默认每 5 分钟检查一次 tablet 分布，且只对「偏离均值 2 倍以上」的节点才发起迁移。

• 观察是否真卡住：用 yb-admin list_tablets 看各 tablet 的 leader 分布，再用 yb-admin list_all_masters 对比节点数，确认是否真的倾斜
• 手动触发一次：运行 yb-admin trigger_load_balancing，它不阻塞，但会把当前不平衡状态加入下一轮调度队列
• 别指望秒级响应——即使触发，迁移本身受 --placement_num_replicas、网络延迟、raft log 同步速度影响，单个 tablet 迁移常需数秒到十几秒

split 相关参数调得太激进，导致 tablet 数爆炸

YugabyteDB 默认在 tablet 达到约 1GB 或写入 QPS 超过 1000 时尝试 split，但这个阈值是软限制。如果业务写入集中在某几个 range（比如时间戳前缀 + 用户 ID），容易在单个 tablet 内快速累积数据，触发连续 split，最终产生大量小 tablet，拖慢元数据管理。

• 关键配置项：--ysql_yb_num_tablets（建表时指定初始 tablet 数）、--tablet_split_limit（全局最大 tablet 数，超出后 split 被拒绝）
• 建表时预估写入热点：对高吞吐表，显式指定 SPLIT INTO 8 TABLETS，比依赖自动 split 更可控
• 查当前 tablet 总数：用 select count(*) FROM system.tablet_servers;，超过 5000 就该警惕——不是绝对上限，但 master 元数据压力明显上升

跨 AZ 部署下 split 后副本分布违反 placement policy

当 --placement_zone 或 --placement_cloud 配置了多可用区策略，tablet split 后的新副本可能暂时落在同一 zone，直到负载均衡介入。这不是 bug，而是 split 和 rebalance 两个异步流程的竞态结果。

• 验证方式：查 yb-admin list_tablets --tabular 输出中的 replicas 列，看每个 replica 的 cloud.region.zone 是否满足你定义的 placement_policy
• 临时缓解：设 --enable_load_balancing=false 启动后先手动 split，再开 balancer，避免 split 和 move 同时发生
• 根本解法：确保每个 zone 至少有 3 个 tserver，且 --placement_num_replicas ≤ zone 数 × 3；否则 balancer 根本无法凑出合法副本集

split 过程中遇到 “Tablet not found” 或 “Leader not found” 错误

这类错误通常出现在 split 正在进行、但客户端还在往旧 tablet 发请求的窗口期。YugabyteDB 会返回 TryAgain 或 NotFound，由 client driver 自动重试（如 ysql 的 pgwire 协议层会重定向），但重试逻辑依赖客户端版本和超时设置。

• 常见诱因：应用用了长连接 + 旧版 driver（如 psycopg2 TryAgain 重定向响应
• 检查点：升级到 ysql driver 支持 tablet-aware routing 的版本（如 libpq ≥ 12，pgx ≥ v4.16）
• 应急手段：临时加大 --tablet_split_timeout_sec（默认 30s），给 split 更多完成时间，减少重试窗口

split 和 load balancing 是两个独立机制，它们之间没有强同步信号。真正难调的不是单次 split，而是长期运行中 tablet 数增长与副本分布稳定性的拉锯——尤其在写入模式突变或节点反复上下线时，得盯住 yb-master 日志里的 LoadBalancer: Skipped tablet … due to … 这类提示，那才是真实瓶颈所在。