印刻数据库

外观

TiDB 单数据中心高可用 ​

单数据中心高可用架构设计 ​

核心设计原则 ​

组件冗余设计 ​

TiDB 单数据中心高可用架构通过组件冗余实现高可用性，每个核心组件至少部署 3 个实例：

  • PD 集群：至少 3 个实例，确保 Raft 共识算法正常工作
  • TiKV 集群：至少 3 个实例，实现数据的多副本存储
  • TiDB Server：至少 2 个实例，提供无状态的 SQL 处理服务
  • TiFlash（可选）：至少 2 个实例，提供列式存储和实时分析能力

数据多副本机制 ​

TiDB 使用 Raft 共识算法确保数据一致性和高可用性：

  • 每个 Region 默认有 3 个副本
  • 副本分布在不同的 TiKV 节点上
  • 通过 Raft 协议实现副本之间的数据同步
  • 当 Leader 副本故障时，自动选举新的 Leader

无状态服务设计 ​

TiDB Server 采用无状态设计，便于水平扩展和故障恢复：

  • 不存储任何业务数据
  • 所有会话信息存储在客户端或 TiKV 中
  • 故障时可以快速重启或替换

典型单数据中心拓扑 ​

基础高可用拓扑 ​

带 TiFlash 的高可用拓扑 ​

组件级高可用配置 ​

PD 集群高可用配置 ​

基本配置要求 ​

yaml
pd_servers:
  - host: 10.0.0.1
    name: pd-1
    client_port: 2379
    peer_port: 2380
  - host: 10.0.0.2
    name: pd-2
    client_port: 2379
    peer_port: 2380
  - host: 10.0.0.3
    name: pd-3
    client_port: 2379
    peer_port: 2380

关键配置参数 ​

参数名推荐值说明
replication.enable-placement-rulestrue启用 PD Placement Rules
replication.max-replicas3每个 Region 的最大副本数
schedule.leader-schedule-limit4Leader 调度并发数
schedule.region-schedule-limit20Region 调度并发数
schedule.replica-schedule-limit64副本调度并发数

TiKV 集群高可用配置 ​

基本配置要求 ​

yaml
tikv_servers:
  - host: 10.0.0.4
    port: 20160
    status_port: 20180
  - host: 10.0.0.5
    port: 20160
    status_port: 20180
  - host: 10.0.0.6
    port: 20160
    status_port: 20180
  - host: 10.0.0.7
    port: 20160
    status_port: 20180
  - host: 10.0.0.8
    port: 20160
    status_port: 20180
  - host: 10.0.0.9
    port: 20160
    status_port: 20180

关键配置参数 ​

参数名推荐值说明
raftstore.raftdb-path"/data/tikv/raft"Raft 日志存储路径
raftstore.raft-log-gc-tick-interval"30m"Raft 日志 GC 间隔
raftstore.raft-log-gc-threshold50000Raft 日志 GC 阈值
server.grpc-concurrency8gRPC 并发数
storage.scheduler-worker-pool-size4存储调度 worker 池大小
readpool.storage.use-unified-pooltrue使用统一的存储读池

TiDB 集群高可用配置 ​

基本配置要求 ​

yaml
tidb_servers:
  - host: 10.0.0.10
    port: 4000
    status_port: 10080
  - host: 10.0.0.11
    port: 4000
    status_port: 10080
  - host: 10.0.0.12
    port: 4000
    status_port: 10080

关键配置参数 ​

参数名推荐值说明
prepared-plan-cache.enabledtrue启用执行计划缓存
oom-action"log"OOM 时的行为
performance.max-procs0最大 CPU 核心数，0 表示使用所有核心
performance.txn-total-size-limit"1073741824"事务总大小限制
proxy-protocol.networks"127.0.0.1"允许使用 Proxy Protocol 的网络

故障自动恢复机制 ​

PD 集群故障恢复 ​

PD Leader 故障 ​

  • 当 PD Leader 故障时，剩余 PD 节点会自动选举新的 Leader
  • 选举过程通常在几秒内完成
  • 期间 PD 服务可能短暂不可用，但不会影响已建立的连接

PD 节点故障 ​

  • 当单个 PD 节点故障时，集群仍能正常工作
  • 建议在 24 小时内恢复故障节点
  • 当故障节点数超过一半时，PD 集群将无法提供服务

TiKV 集群故障恢复 ​

TiKV 节点故障 ​

  • 当 TiKV 节点故障时，PD 会检测到并启动容错机制
  • 对于受影响的 Region，Raft 会自动选举新的 Leader
  • 如果故障节点无法恢复，PD 会调度新的副本以保持副本数量
  • 恢复时间取决于故障节点上的 Region 数量和数据量

Region Leader 故障 ​

  • 当 Region Leader 故障时，Raft 会自动选举新的 Leader
  • 选举过程通常在毫秒级完成
  • 期间该 Region 的写入请求会短暂延迟，但不会丢失数据

TiDB 集群故障恢复 ​

TiDB 节点故障 ​

  • TiDB Server 是无状态的，故障时不会影响数据安全
  • 客户端可以通过负载均衡器自动切换到其他 TiDB 节点
  • 故障节点可以快速重启或替换
  • 恢复时间通常在几秒到几分钟内

手动故障转移 ​

TiDB Server 手动故障转移 ​

1. 确认 TiDB 节点故障 ​

bash
# 检查 TiDB 节点状态
tiup cluster display <cluster-name> | grep tidb

# 检查节点是否可以访问
ping <tidb-node-ip>

# 检查端口是否开放
telnet <tidb-node-ip> 4000

2. 重启故障节点 ​

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

3. 如果重启失败，替换节点 ​

bash
# 编辑拓扑文件，添加新节点信息
# 执行扩容操作
tiup cluster scale-out <cluster-name> <topology-file>

# 移除故障节点
tiup cluster scale-in <cluster-name> -N <tidb-node-ip>:4000

TiKV 节点手动故障转移 ​

1. 确认 TiKV 节点故障 ​

bash
# 检查 TiKV 节点状态
tiup cluster display <cluster-name> | grep tikv

# 检查 PD 中的 TiKV 状态
pd-ctl -u http://<pd-ip>:2379 store

2. 标记节点为下线 ​

bash
pd-ctl -u http://<pd-ip>:2379 store delete <store-id>

3. 等待数据迁移完成 ​

bash
# 监控迁移进度
pd-ctl -u http://<pd-ip>:2379 operator show

4. 移除故障节点 ​

bash
tiup cluster scale-in <cluster-name> -N <tikv-node-ip>:20160

5. 添加新节点 ​

bash
tiup cluster scale-out <cluster-name> <topology-file>

PD 节点手动故障转移 ​

1. 确认 PD 节点故障 ​

bash
# 检查 PD 节点状态
tiup cluster display <cluster-name> | grep pd

# 检查 PD 集群状态
pd-ctl -u http://<pd-ip>:2379 cluster

2. 如果是 Leader 节点故障，等待自动选举 ​

3. 重启故障节点 ​

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

4. 如果重启失败，替换节点 ​

bash
# 编辑拓扑文件，添加新节点信息
# 执行扩容操作
tiup cluster scale-out <cluster-name> <topology-file>

# 移除故障节点
tiup cluster scale-in <cluster-name> -N <pd-node-ip>:2379

高可用监控与告警 ​

关键监控指标 ​

PD 监控指标 ​

  • pd_cluster_is_healthy：PD 集群健康状态
  • pd_server_is_leader：PD 节点是否为 Leader
  • pd_scheduler_operator_finish_total：调度操作完成总数
  • pd_scheduler_operator_create_total：调度操作创建总数

TiKV 监控指标 ​

  • tikv_raftstore_peer_state：Raft Peer 状态
  • tikv_raftstore_leader_count：Leader 数量
  • tikv_raftstore_apply_logs_duration_seconds：应用日志延迟
  • tikv_raftstore_append_logs_duration_seconds：追加日志延迟

TiDB 监控指标 ​

  • tidb_server_connection_count：连接数
  • tidb_server_query_duration_seconds：查询延迟
  • tidb_server_query_total：查询总数
  • tidb_server_internal_error_total：内部错误总数

重要告警规则 ​

PD 告警 ​

  • PDClusterUnavailable：PD 集群不可用
  • PDFewerThanMajority：PD 节点数少于多数派
  • PDLeaderChangeFrequent：PD Leader 频繁切换
  • PDSchedulerPendingTooMany：调度操作积压过多

TiKV 告警 ​

  • TiKVStoreDown：TiKV 存储节点宕机
  • TiKVUnreachable：TiKV 节点不可达
  • TiKVRaftLeaderMissing：Raft Leader 缺失
  • TiKVRaftPendingLogGap：Raft 日志差距过大

TiDB 告警 ​

  • TiDBServerDown：TiDB 服务器宕机
  • TiDBTooManyConnections：连接数过多
  • TiDBMemoryUsageHigh：内存使用率过高
  • TiDBQPSDrop：QPS 大幅下降

高可用最佳实践 ​

部署最佳实践 ​

硬件选型 ​

  • CPU：选择多核 CPU，推荐 Intel Xeon 或 AMD EPYC 系列
  • 内存：
    • PD：至少 8GB，推荐 16GB
    • TiDB：至少 16GB，推荐 32GB
    • TiKV：至少 32GB，推荐 64GB
    • TiFlash：至少 64GB，推荐 128GB
  • 存储：
    • PD：使用 SSD，推荐 NVMe SSD
    • TiDB：使用 SSD
    • TiKV：使用 SSD，推荐 NVMe SSD，容量根据数据量规划
    • TiFlash：使用 SSD，推荐 NVMe SSD
  • 网络：使用 10Gbps 或更高带宽的网络，降低网络延迟

部署架构 ​

  • 每个组件部署在独立的物理机器上
  • 避免单点故障，特别是 PD Leader 节点
  • 合理规划数据中心网络，确保低延迟和高带宽

配置最佳实践 ​

副本策略 ​

  • 根据数据重要性调整副本数量，关键业务可以使用 5 副本
  • 使用 Placement Rules 精细控制副本分布
  • 确保副本分布在不同的机架或服务器上

调度策略 ​

  • 根据集群规模调整调度参数
  • 避免在业务高峰期进行大规模调度
  • 合理设置调度限速，避免影响业务性能

日志与监控 ​

  • 配置适当的日志级别，确保关键信息被记录
  • 确保监控数据有足够的保留时间
  • 设置合理的告警阈值，避免误报和漏报

运维最佳实践 ​

定期健康检查 ​

  • 定期运行 tiup cluster check cluster-name 检查集群健康状态
  • 定期检查监控指标，发现潜在问题
  • 定期备份集群配置和元数据

故障演练 ​

  • 定期进行故障演练，验证高可用机制
  • 模拟各种故障场景，如节点故障、网络分区等
  • 评估故障恢复时间和数据安全性

版本升级 ​

  • 遵循官方升级指南，避免跨版本升级
  • 在测试环境验证升级流程
  • 采用滚动升级方式，减少业务影响

容量规划 ​

  • 定期评估集群容量，提前规划扩容
  • 监控存储使用率，避免磁盘空间不足
  • 考虑业务增长，预留足够的扩容空间

常见问题（FAQ） ​

Q1: 单数据中心部署时，如何避免机架级故障？ ​

A1: 可以通过以下方式避免机架级故障：

  • 使用 Placement Rules 将副本分布在不同的机架上
  • 配置 location-labels 标识机架信息
  • 确保每个机架至少有一个 TiKV 节点
  • 定期检查机架间网络连接

Q2: TiDB 单数据中心高可用的 RTO 和 RPO 是多少？ ​

A2: TiDB 单数据中心高可用的 RTO 和 RPO 取决于故障类型：

  • TiDB 节点故障：RTO `< 1 分钟，RPO = 0
  • TiKV 节点故障：RTO < 5 分钟，RPO = 0
  • PD Leader 故障：RTO < 30 秒，RPO = 0
  • PD 集群故障：RTO 取决于故障恢复时间，RPO = 0

Q3: 如何提高 TiDB 单数据中心的可用性？ ​

A3: 可以通过以下方式提高可用性：

  • 增加组件副本数量
  • 优化部署架构，避免单点故障
  • 配置完善的监控和告警
  • 定期进行故障演练
  • 制定详细的故障恢复预案
  • 保持 TiDB 版本更新，修复已知漏洞

Q4: TiKV 节点故障后，数据恢复需要多长时间？ ​

A4: 数据恢复时间取决于以下因素：

  • 故障节点上的 Region 数量
  • 每个 Region 的数据量
  • 集群的网络带宽
  • 集群的负载情况

一般情况下，单个 TiKV 节点故障的恢复时间在几分钟到几十分钟之间。

Q5: 如何验证 TiDB 集群的高可用性？ ​

A5: 可以通过以下方式验证：

  • 运行 tiup cluster check cluster-name --detail` 检查集群状态
  • 查看监控指标，确认所有组件运行正常
  • 进行故障演练，模拟节点故障
  • 检查数据一致性，确保故障后数据完整

Q6: 单数据中心部署时，是否需要考虑网络分区问题？ ​

A6: 是的，即使在单数据中心内部，也可能发生网络分区：

  • 交换机故障导致网络分区
  • 网络配置错误导致节点隔离
  • 大规模网络风暴导致连接中断

建议配置相应的监控和告警，及时发现网络问题。

Q7: 如何处理 TiDB 集群的脑裂问题？ ​

A7: TiDB 使用 Raft 共识算法避免脑裂：

  • Raft 要求多数派节点同意才能进行决策
  • 当网络分区发生时，只有包含多数派节点的分区才能继续工作
  • 另一个分区的节点会进入等待状态
  • 当网络恢复后，集群会自动恢复正常

Q8: 单数据中心部署与多数据中心部署相比，有哪些优缺点？ ​

A8: 单数据中心部署的优缺点：

  • 优点：
    • 部署和管理简单
    • 网络延迟低，性能更好
    • 成本较低
  • 缺点：
    • 数据中心级故障会导致整个集群不可用
    • 容灾能力有限
    • 无法实现跨地域的业务部署

对于关键业务，建议考虑多数据中心部署或跨地域部署，以提高容灾能力。