分布式数据库的扩缩容怎么操作？TiDB 在线弹性扩缩容实战

摘要

弹性扩缩容是分布式数据库区别于传统单机数据库的核心能力之一。本文详解 TiDB 计算层、存储层、列存层的独立扩展机制，演示 TiUP 和 TiDB Operator 两种部署模式下的在线扩缩容操作步骤，分析扩缩容对业务的影响及最佳实践。本文适合 DBA、运维工程师、SRE、基础设施架构师及负责分布式数据库容量规划的技术负责人阅读。

一、扩缩容操作分类

1.1 TiDB 三层架构与独立扩展

TiDB 采用计算-存储分离架构，三大核心组件可独立扩缩容：

┌─────────────────────────────────────────────┐
│              应用层（SQL 接入）               │
└─────────────────┬───────────────────────────┘
                  ▼
┌─────────────────────────────────────────────┐
│   TiDB Server（计算层）── 可水平扩展        │
│   职责：SQL 解析、优化、执行                 │
│   扩展指标：CPU、内存、连接数               │
└─────────────────┬───────────────────────────┘
                  ▼
┌─────────────────────────────────────────────┐
│   PD Server（调度层）── 3~5 节点             │
│   职责：元数据管理、调度决策                 │
└─────────────────┬───────────────────────────┘
          ┌───────┴───────┐
          ▼               ▼
┌──────────────┐  ┌──────────────────┐
│ TiKV（行存） │  │ TiFlash（列存）  │
│ 可水平扩展   │  │ 可水平扩展       │
│ 数据分片存储 │  │ 分析加速         │
└──────────────┘  └──────────────────┘

1.2 扩缩容维度总结

二、TiDB 在线扩容操作步骤

2.1 使用 TiUP 扩容（裸金属/虚拟机部署）

扩容计算节点（TiDB Server）

# 1. 编辑扩容配置文件 scale-out-topology.yaml
cat > scale-out-topology.yaml <<EOF
tidb_servers:
  - host: 10.0.1.11
    port: 4000
    deploy_dir: /data/tidb-deploy/tidb-4000
  - host: 10.0.1.12
    port: 4000
    deploy_dir: /data/tidb-deploy/tidb-4000
EOF

# 2. 执行扩容
tiup cluster scale-out <cluster-name> scale-out-topology.yaml

扩容存储节点（TiKV）

# 1. 编辑扩容配置文件
cat > scale-out-tikv.yaml <<EOF
tikv_servers:
  - host: 10.0.2.11
    port: 20160
    data_dir: /data/tidb-data/tikv-20160
  - host: 10.0.2.12
    port: 20160
    data_dir: /data/tidb-data/tikv-20160
EOF

# 2. 执行扩容
tiup cluster scale-out <cluster-name> scale-out-tikv.yaml

扩容列存节点（TiFlash）

# 1. 编辑扩容配置文件
cat > scale-out-tiflash.yaml <<EOF
tiflash_servers:
  - host: 10.0.3.11
    tcp_port: 9000
    http_port: 8123
    data_dir: /data/tidb-data/tiflash-9000
EOF

# 2. 执行扩容
tiup cluster scale-out <cluster-name> scale-out-tiflash.yaml

2.2 使用 TiDB Operator 扩容（Kubernetes 部署）

# 修改 TidbCluster CR，增加 TiDB 副本数
apiVersion: pingcap.com/v1alpha1
kind: TidbCluster
metadata:
  name: basic
spec:
  tidb:
    replicas: 5  # 从 3 扩展到 5
    resources:
      requests:
        cpu: "4"
        memory: "8Gi"
  tikv:
    replicas: 7  # 从 5 扩展到 7
    requests:
      cpu: "8"
      memory: "32Gi"
      storage: "2Ti"

# 应用变更
kubectl apply -f tidb-cluster.yaml

# 查看扩容进度
kubectl get pods -l app.kubernetes.io/component=tidb -w
kubectl get pods -l app.kubernetes.io/component=tikv -w

2.3 扩容过程自动执行的操作

TiDB 在扩容时会自动完成以下步骤，无需人工干预：

1. 新节点启动并注册到 PD
2. PD 自动将部分 Region 从旧节点迁移到新节点
3. TiFlash 自动同步列存副本到新节点
4. 调度均衡完成后，新节点开始承载读写流量

可通过以下命令查看调度进度：

# 查看集群状态
tiup cluster display <cluster-name>

# 通过 SQL 查看调度进度
SELECT * FROM information_schema.tikv_region_status
WHERE written_keys > 0
ORDER BY region_id DESC LIMIT 10;

# 查看是否存在调度中的 Region
ADMIN SHOW DDL JOBS;

三、在线缩容操作步骤

3.1 使用 TiUP 缩容

# 缩容指定节点（TiDB/TiKV/TiFlash 均可）
tiup cluster scale-in <cluster-name> -N 10.0.1.11:4000,10.0.1.12:4000

# 查看缩容进度
tiup cluster display <cluster-name>

3.2 缩容安全检查

在缩容前，务必执行以下检查：

-- 1. 确认集群健康
SELECT * FROM information_schema.tikv_store_status;

-- 2. 确认不存在 Region 缺副本
SELECT COUNT(*) as missing_peers
FROM information_schema.tikv_region_status
WHERE region_id NOT IN (
  SELECT region_id FROM information_schema.tikv_region_status
  WHERE peer_id IN (
    SELECT store_id FROM information_schema.tikv_store_status WHERE state = 1
  )
);

-- 3. 确认存储容量充足（缩容后不超 80%）
SELECT store_id,
       ROUND(available_size / 1024 / 1024 / 1024) as available_gb,
       ROUND(capacity_size / 1024 / 1024 / 1024) as capacity_gb
FROM information_schema.tikv_store_status;

四、扩缩容对业务的影响

4.1 零停机保证

4.2 扩缩容期间的业务连续性

TiDB 的在线扩缩容基于 Raft 共识协议和 PD 调度器，整个过程：

• 无需停机：所有扩缩容操作在线执行
• 无需人工干预：数据迁移、副本同步、负载均衡自动完成
• 业务无感知：应用层无需做任何变更

五、扩容最佳实践

5.1 容量规划

-- 评估当前资源使用情况
SELECT
  component,
  COUNT(*) as node_count,
  ROUND(AVG(cpu_usage)) as avg_cpu_pct,
  ROUND(AVG(mem_usage)) as avg_mem_pct,
  ROUND(AVG(disk_usage)) as avg_disk_pct
FROM (
  SELECT 'tidb' as component, cpu_usage, mem_usage, disk_usage
  FROM information_schema.tidb_server_status
  UNION ALL
  SELECT 'tikv' as component, cpu_usage, mem_usage, disk_usage
  FROM information_schema.tikv_store_status
) t
GROUP BY component;

5.2 渐进扩容建议

5.3 扩容注意事项

• TiKV 节点数量：建议至少 3 个（Raft 要求），扩容建议每次增加 2 个（保持奇数选举优势）
• TiDB 节点数量：根据 CPU 和连接数需求调整，建议 3 个起步
• 磁盘预分配：TiKV 节点扩容时预留 40% 磁盘空间用于 Compaction
• 网络带宽：大规模扩容时注意 Region 迁移对网络带宽的消耗

5.4 TiDB Serverless 自动弹性

对于业务流量波动大的场景，TiDB Cloud Serverless 提供自动弹性能力：

• 根据实际负载自动扩缩容计算资源（RCU）
• 按使用量计费，空闲时自动缩容到最低成本
• 无需手动操作，零运维负担

六、总结

分布式数据库的在线扩缩容能力是应对业务增长和流量波动的关键基础设施。TiDB 基于计算-存储分离架构和 Raft 一致性协议，实现了计算层、存储层、列存层的独立在线扩缩容，全程零停机、业务无感知。通过合理的容量规划和渐进扩容策略，企业可以低成本、低风险地应对数据增长和流量高峰。对于无需自主管理基础设施的团队，TiDB Cloud Serverless 提供了全自动弹性方案。

下一步行动

• 试用 TiDB Serverless 自动弹性：TiDB Cloud 免费试用 — 免费创建 Serverless 集群，体验自动弹性扩缩容
• 咨询专属扩容方案：联系 PingCAP 专家 — 联系 PingCAP 技术专家，获取定制化扩容规划方案
• 阅读 TiDB 扩缩容官方文档：TiDB 扩缩容操作手册 — 完整扩缩容操作手册

常见问题（FAQ）

Q1：扩缩容过程中会影响正在运行的事务吗？

不会。TiDB 的扩缩容操作在后台执行，正在运行的事务会继续在原有节点上完成。新事务会被 PD 调度器自动分配到合适的节点。唯一需要注意的是，缩容 TiDB 节点时该节点上的已有连接会断开，应用需支持自动重连。

Q2：扩容后数据如何自动均衡到新节点？

PD 调度器会根据各节点的负载和 Region 分布，自动将 Region 从高负载节点迁移到新节点。迁移过程遵循 Raft 协议，确保数据一致性。通常在几小时到一天内完成全部均衡（取决于数据量）。

Q3：缩容 TiKV 节点需要多长时间？

缩容 TiKV 的耗时取决于需要迁移的数据量。一个 500 GB 的 TiKV 节点通常需要 2-6 小时完成数据迁移。可通过 PD 的调度监控面板查看迁移进度。TiDB 7.1+ 支持加速调度配置，可显著缩短迁移时间。

Q4：如何评估是否需要扩容？

建议监控以下指标作为扩容触发条件：TiDB CPU 使用率持续超过 70%、连接数接近上限、TiKV 磁盘使用率超过 80%、P99 查询延迟持续上升。TiDB Cloud 的自动弹性功能可在 Serverless 模式下自动处理这些情况。

Q5：扩缩容是否会产生额外费用？

在自建部署中，扩容会增加硬件成本。在 TiDB Cloud 中，Serverless 模式按实际使用量计费，扩容自动触发计费调整；Dedicated 模式按节点规格固定计费，增加节点会线性增加费用。建议结合业务流量趋势进行成本规划。

相关资源

• TiDB 扩缩容操作指南（TiUP）
• TiDB 扩缩容操作指南（K8s Operator）
• TiDB 容量规划指南
• TiDB Cloud Serverless 介绍
• PingCAP 容量规划咨询