印刻数据库

外观

TiDB 垂直扩容 ​

垂直扩容是指通过升级单个节点的硬件资源（如 CPU、内存、磁盘等）来提高 TiDB 集群的性能和容量。垂直扩容适用于单节点负载过高的场景，可以快速提升节点的处理能力。

适用场景 ​

垂直扩容适用于以下场景：

  • 单个 TiDB 节点 CPU 使用率持续过高
  • 单个 TiKV 节点内存不足，频繁出现 OOM 错误
  • 单个 PD 节点负载过高，影响集群调度
  • 单个 TiFlash 节点性能不足，无法满足分析查询需求
  • 节点磁盘空间不足，需要扩容存储容量

扩容原则 ​

进行垂直扩容时，应遵循以下原则：

  • 评估负载情况：在扩容前，评估节点的负载情况，确定需要升级的硬件资源
  • 选择合适的硬件：根据节点的角色和负载情况，选择合适的硬件配置
  • 分批进行：分批进行垂直扩容，避免同时升级多个节点影响集群稳定性
  • 测试验证：在扩容后，进行测试验证，确保扩容效果符合预期
  • 监控调整：持续监控扩容后的节点性能，根据需要调整配置

扩容影响 ​

垂直扩容可能对集群产生以下影响：

  • 服务中断：升级硬件时需要重启节点，可能导致服务中断
  • 性能波动：节点重启后，需要重新加载数据和恢复连接，可能导致性能波动
  • 数据迁移：如果调整了 TiKV 节点的存储配置，可能触发数据迁移
  • 调度调整：PD 会根据节点的新配置调整调度策略

扩容前准备 ​

评估负载情况 ​

使用以下方法评估节点的负载情况：

  • 监控指标分析：查看 Prometheus 和 Grafana 监控面板中的 CPU、内存、磁盘、网络等指标
  • 日志分析：分析节点日志，查找性能瓶颈和错误信息
  • 命令行工具：使用 top、iostat、vmstat 等命令查看节点的实时负载情况
  • TiDB Dashboard：使用 TiDB Dashboard 查看节点的负载分布和性能指标

制定扩容计划 ​

根据负载评估结果，制定详细的扩容计划：

  • 确定扩容节点：确定需要进行垂直扩容的节点
  • 选择硬件配置：根据节点角色和负载情况，选择合适的硬件配置
  • 安排扩容时间：选择业务低峰期进行扩容，减少对业务的影响
  • 准备回滚方案：制定回滚方案，以防扩容失败
  • 通知相关人员：通知相关人员，协调扩容工作

备份数据 ​

在进行垂直扩容前，备份重要数据：

  • 全量备份：使用 BR 工具进行全量备份
  • 增量备份：确保增量备份正常运行
  • 元数据备份：备份 PD 的元数据

扩容操作 ​

TiDB 节点垂直扩容 ​

TiDB 节点主要负责 SQL 解析、优化和执行，对 CPU 和内存要求较高。

升级步骤 ​

  1. 停止 TiDB 节点：

    bash
    tiup cluster stop <cluster-name> -R tidb -N <tidb-node-ip>:4000

  2. 升级硬件：

    • 升级 CPU：增加 CPU 核心数或更换更高性能的 CPU
    • 升级内存：增加内存容量
    • 升级磁盘：更换为更高性能的 SSD 磁盘

  3. 调整配置：

    bash
    # 编辑集群配置
tiup cluster edit-config <cluster-name>

# 在配置中调整 TiDB 节点的资源配置
tidb_servers:
- host: <tidb-node-ip>
  port: 4000
  status_port: 10080
  config:
    performance.max-procs: 16  # 根据新的 CPU 核心数调整
    memory.oom-action: "log"  # 设置 OOM 行为

  4. 启动 TiDB 节点：

    bash
    tiup cluster start <cluster-name> -R tidb -N <tidb-node-ip>:4000

  5. 验证节点状态：

    bash
    tiup cluster display <cluster-name>

TiKV 节点垂直扩容 ​

TiKV 节点主要负责数据存储和分布式事务处理，对 CPU、内存和磁盘要求较高。

升级步骤 ​

  1. 停止 TiKV 节点：

    bash
    tiup cluster stop <cluster-name> -R tikv -N <tikv-node-ip>:20160

  2. 升级硬件：

    • 升级 CPU：增加 CPU 核心数或更换更高性能的 CPU
    • 升级内存：增加内存容量，建议至少 32GB
    • 升级磁盘：增加磁盘容量或更换更高性能的 SSD 磁盘

  3. 调整配置：

    bash
    # 编辑集群配置
tiup cluster edit-config <cluster-name>

# 在配置中调整 TiKV 节点的资源配置
tikv_servers:
- host: <tikv-node-ip>
  port: 20160
  status_port: 20180
  config:
    server.labels:
      host: <tikv-node-ip>
    storage.block-cache.capacity: "24GB"  # 根据新的内存容量调整
    raftstore.apply-pool-size: 8  # 根据新的 CPU 核心数调整
    raftstore.store-pool-size: 8  # 根据新的 CPU 核心数调整
    storage.scheduler-worker-pool-size: 8  # 根据新的 CPU 核心数调整

  4. 启动 TiKV 节点：

    bash
    tiup cluster start <cluster-name> -R tikv -N <tikv-node-ip>:20160

  5. 验证节点状态：

    bash
    tiup cluster display <cluster-name>

  6. 检查数据迁移：

    bash
    # 查看数据迁移进度
tiup ctl pd -u http://<pd-host>:2379 operator show

PD 节点垂直扩容 ​

PD 节点主要负责集群调度和元数据管理，对 CPU、内存和磁盘要求适中。

升级步骤 ​

  1. 停止 PD 节点：

    bash
    tiup cluster stop <cluster-name> -R pd -N <pd-node-ip>:2379

  2. 升级硬件：

    • 升级 CPU：增加 CPU 核心数
    • 升级内存：增加内存容量，建议至少 16GB
    • 升级磁盘：更换为更高性能的 SSD 磁盘

  3. 调整配置：

    bash
    # 编辑集群配置
tiup cluster edit-config <cluster-name>

# 在配置中调整 PD 节点的资源配置
pd_servers:
- host: <pd-node-ip>
  port: 2379
  peer_port: 2380
  config:
    schedule.max-store-down-time: "30m"  # 调整存储节点宕机超时时间
    schedule.leader-schedule-limit: 4  # 调整 Leader 调度限制

  4. 启动 PD 节点：

    bash
    tiup cluster start <cluster-name> -R pd -N <pd-node-ip>:2379

  5. 验证节点状态：

    bash
    tiup cluster display <cluster-name>

TiFlash 节点垂直扩容 ​

TiFlash 节点主要负责实时分析查询，对 CPU、内存和磁盘要求较高。

升级步骤 ​

  1. 停止 TiFlash 节点：

    bash
    tiup cluster stop <cluster-name> -R tiflash -N <tiflash-node-ip>:9000

  2. 升级硬件：

    • 升级 CPU：增加 CPU 核心数，建议至少 16 核
    • 升级内存：增加内存容量，建议至少 64GB
    • 升级磁盘：增加磁盘容量或更换更高性能的 SSD 磁盘

  3. 调整配置：

    bash
    # 编辑集群配置
tiup cluster edit-config <cluster-name>

# 在配置中调整 TiFlash 节点的资源配置
tiflash_servers:
- host: <tiflash-node-ip>
  port: 9000
  status_port: 20292
  flash_service_port: 3930
  flash_proxy_port: 20170
  config:
    tiflash:
      profiles:
        default:
          max_memory_usage: 50GB  # 根据新的内存容量调整
          max_threads: 16  # 根据新的 CPU 核心数调整

  4. 启动 TiFlash 节点：

    bash
    tiup cluster start <cluster-name> -R tiflash -N <tiflash-node-ip>:9000

  5. 验证节点状态：

    bash
    tiup cluster display <cluster-name>

扩容后验证 ​

性能测试 ​

在垂直扩容后，进行性能测试，验证扩容效果：

  • 基准测试：使用 Sysbench 或 TiUP Bench 进行基准测试
  • 业务测试：运行业务测试用例，验证业务性能
  • 压力测试：进行压力测试，验证节点的承载能力

监控指标验证 ​

查看监控指标，验证扩容后的节点性能：

  • CPU 使用率：检查 CPU 使用率是否降低
  • 内存使用率：检查内存使用率是否降低
  • 磁盘 I/O：检查磁盘 I/O 性能是否提升
  • 查询延迟：检查查询延迟是否降低
  • 写入性能：检查写入性能是否提升

功能验证 ​

验证节点的功能是否正常：

  • 连接验证：验证客户端能否正常连接到节点
  • 查询验证：执行查询语句，验证查询结果是否正确
  • 写入验证：执行写入语句，验证数据能否正常写入
  • 事务验证：执行事务操作，验证事务能否正常提交

最佳实践 ​

硬件选择 ​

  • TiDB 节点：

    • CPU：8 核+，主频 2.5GHz+
    • 内存：16GB+，根据业务负载调整
    • 磁盘：SSD，200GB+

  • TiKV 节点：

    • CPU：8 核+，主频 2.5GHz+
    • 内存：32GB+，建议内存大小为 CPU 核心数的 4-8 倍
    • 磁盘：NVMe SSD，500GB+，建议使用多个磁盘

  • PD 节点：

    • CPU：4 核+，主频 2.5GHz+
    • 内存：8GB+，根据集群规模调整
    • 磁盘：SSD，100GB+

  • TiFlash 节点：

    • CPU：16 核+，主频 2.5GHz+
    • 内存：64GB+，建议内存大小为 CPU 核心数的 4-8 倍
    • 磁盘：NVMe SSD，1TB+

配置调整 ​

  • TiDB 节点：

    • performance.max-procs：设置为 CPU 核心数的 80%
    • memory.oom-action：设置为 "log" 或 "cancel"
    • prepared-plan-cache.enabled：启用预编译计划缓存

  • TiKV 节点：

    • storage.block-cache.capacity：设置为内存的 50%-70%
    • raftstore.apply-pool-size：设置为 CPU 核心数的 1/4
    • raftstore.store-pool-size：设置为 CPU 核心数的 1/4
    • storage.scheduler-worker-pool-size：设置为 CPU 核心数的 1/4

  • PD 节点：

    • schedule.max-store-down-time：根据集群规模调整
    • schedule.leader-schedule-limit：根据集群规模调整
    • schedule.region-schedule-limit：根据集群规模调整

  • TiFlash 节点：

    • max_memory_usage：设置为内存的 80%
    • max_threads：设置为 CPU 核心数的 80%
    • storage.io_threads：根据磁盘数量调整

扩容操作 ​

  • 选择合适的时间：在业务低峰期进行扩容，减少对业务的影响
  • 分批进行：分批进行垂直扩容，每次只升级一个或少数几个节点
  • 监控进度：在扩容过程中，实时监控节点状态和集群性能
  • 验证效果：在扩容后，进行充分的测试验证，确保扩容效果符合预期
  • 文档记录：详细记录扩容过程，包括时间、节点、硬件配置、配置调整等信息

故障排除 ​

节点无法启动 ​

可能原因 ​

  • 硬件不兼容
  • 配置错误
  • 数据损坏
  • 端口冲突

解决方案 ​

  • 检查硬件兼容性：确认新硬件是否兼容当前的操作系统和 TiDB 版本
  • 检查配置文件：检查配置文件中的参数是否正确，特别是资源相关的参数
  • 检查日志文件：查看节点日志，查找启动失败的原因
  • 检查端口占用：使用 netstat 或 lsof 命令检查端口是否被占用
  • 恢复备份数据：如果数据损坏，使用备份数据恢复

性能没有提升 ​

可能原因 ​

  • 硬件配置不合理
  • 配置参数没有调整
  • 存在其他瓶颈
  • 负载测试方法不正确

解决方案 ​

  • 优化硬件配置：根据节点角色和负载情况，选择更合适的硬件配置
  • 调整配置参数：根据新的硬件配置，调整节点的配置参数
  • 排查其他瓶颈：检查集群中是否存在其他瓶颈，如网络、存储等
  • 优化测试方法：使用正确的测试方法和工具，确保测试结果准确

集群稳定性下降 ​

可能原因 ​

  • 节点配置不一致
  • 调度策略不适应新配置
  • 数据迁移导致负载过高
  • 硬件故障

解决方案 ​

  • 统一配置：确保所有节点的配置一致
  • 调整调度策略：根据新的硬件配置，调整 PD 的调度策略
  • 控制数据迁移速度：调整 PD 的调度速率限制，控制数据迁移速度
  • 检查硬件：检查新硬件是否存在故障，如磁盘坏道、内存故障等

垂直扩容与水平扩容对比 ​

维度垂直扩容水平扩容
扩容方式升级单个节点的硬件资源添加新节点到集群中
适用场景单节点负载过高集群整体负载过高
扩容成本硬件成本高硬件成本相对较低
实施难度相对简单相对复杂
服务影响可能导致服务中断对服务影响较小
扩容上限受限于单节点硬件上限理论上无上限
数据分布不改变数据分布会触发数据迁移
管理复杂度相对简单相对复杂

常见问题（FAQ） ​

Q1: 垂直扩容和水平扩容应该如何选择？ ​

A1: 选择垂直扩容还是水平扩容，取决于集群的负载情况和业务需求：

  • 如果单个节点的负载过高，而其他节点负载较低，适合进行垂直扩容
  • 如果集群整体负载过高，或需要提高集群的可用性和容错能力，适合进行水平扩容
  • 一般建议先进行垂直扩容，当垂直扩容达到瓶颈后，再进行水平扩容

Q2: 垂直扩容需要停止集群服务吗？ ​

A2: 垂直扩容需要重启节点，可能导致服务中断。为了减少对业务的影响，建议：

  • 选择业务低峰期进行扩容
  • 分批进行扩容，每次只升级一个或少数几个节点
  • 对于 TiDB 节点，可以配置多个实例，轮流进行扩容

Q3: 垂直扩容后，需要调整 PD 的调度策略吗？ ​

A3: 是的，垂直扩容后，PD 会根据节点的新配置调整调度策略。但可能需要手动调整一些调度参数，如：

  • schedule.leader-schedule-limit：调整 Leader 调度限制
  • schedule.region-schedule-limit：调整 Region 调度限制
  • schedule.replica-schedule-limit：调整副本调度限制

Q4: 如何监控垂直扩容后的节点性能？ ​

A4: 可以使用以下方法监控扩容后的节点性能：

  • Prometheus + Grafana：查看监控面板中的 CPU、内存、磁盘、网络等指标
  • TiDB Dashboard：使用 TiDB Dashboard 查看节点的负载分布和性能指标
  • 命令行工具：使用 top、iostat、vmstat 等命令查看节点的实时负载情况
  • 性能测试工具：使用 Sysbench 或 TiUP Bench 进行基准测试

Q5: 垂直扩容后，数据会自动均衡吗？ ​

A5: 垂直扩容后，如果调整了 TiKV 节点的存储配置，PD 会根据节点的新配置调整调度策略，可能会触发数据迁移，使数据分布更加均衡。但如果只是升级了 CPU 或内存，而没有调整存储配置，可能不会触发大量的数据迁移。

Q6: 如何回滚垂直扩容操作？ ​

A6: 如果垂直扩容失败，或扩容后性能没有提升，可以回滚扩容操作：

  • 恢复原来的硬件配置
  • 恢复原来的配置文件
  • 重启节点
  • 验证节点状态和性能

Q7: 垂直扩容对 TiDB 集群的高可用性有影响吗？ ​

A7: 垂直扩容可能对集群的高可用性产生一定影响，因为需要重启节点。为了提高集群的高可用性，建议：

  • 配置足够的副本数，如 3 个或更多
  • 分批进行扩容，避免同时升级多个节点
  • 对于关键业务，配置多个 TiDB 实例，提高服务可用性

Q8: 如何预测垂直扩容的效果？ ​

A8: 可以使用以下方法预测垂直扩容的效果：

  • 负载评估：评估节点的当前负载情况，确定瓶颈资源
  • 性能测试：在测试环境中模拟垂直扩容，测试性能提升效果
  • 经验公式：根据节点的角色和负载情况，使用经验公式预测扩容效果
  • 监控历史数据：分析监控历史数据，预测扩容后的性能变化