印刻数据库

外观

TiDB 网络故障 ​

网络故障类型 ​

1. 节点间网络中断 ​

  • 症状：节点间无法通信，集群状态异常
  • 影响：可能导致 Region 不可用，事务失败
  • 常见原因：网线松动、网卡故障、交换机故障、防火墙配置错误

2. 网络延迟过高 ​

  • 症状：节点间通信延迟增加，集群性能下降
  • 影响：查询响应时间变长，事务提交延迟增加，Raft 选举超时
  • 常见原因：网络拥塞、路由问题、硬件资源不足、网络拓扑不合理

3. 网络分区 ​

  • 症状：集群被分割成多个无法通信的子集群
  • 影响：可能导致脑裂，数据不一致
  • 常见原因：交换机故障、网络配置错误、大规模网络故障

4. 端口不可达 ​

  • 症状：特定端口无法访问，服务无法正常通信
  • 影响：组件无法正常通信，服务不可用
  • 常见原因：防火墙拦截、端口未开放、服务未启动、配置错误

网络故障诊断 ​

1. 日志分析 ​

bash
# 查看 TiDB 日志
tiup cluster log `<cluster-name>` --component tidb --instance `<tidb-address>`:4000 --follow

# 查看 TiKV 日志
tiup cluster log `<cluster-name>` --component tikv --instance `<tikv-address>`:20160 --follow

# 查看 PD 日志
tiup cluster log `<cluster-name>` --component pd --instance `<pd-address>`:2379 --follow

2. 监控检查 ​

bash
# 访问 TiDB Dashboard
tiup cluster display `<cluster-name>` --dashboard

# 查看网络监控
grafana http://`<grafana-address>`:3000/d/TiDB-Overview/tidb-overview?var-datasource=prometheus&var-cluster=`<cluster-name>`

3. 网络工具使用 ​

bash
# 检查节点间连通性
ping `<target-address>`

# 检查端口可达性
telnet `<target-address>` `<port>`

# 使用 nc 检查端口
nc -zv `<target-address>` `<port>`

# 检查网络延迟和丢包率
iperf3 -c `<target-address>`

# 检查路由
traceroute `<target-address>`

# 检查网络连接状态
ss -tuln

# 检查防火墙规则
iptables -L -n

网络故障处理 ​

1. 自动恢复机制 ​

Raft 协议 ​

TiDB 基于 Raft 协议实现数据一致性，当网络故障发生时：

  • Raft 选举会在超时后重新进行
  • 少数派节点会自动拒绝写请求
  • 当网络恢复后，集群会自动恢复正常

PD 调度 ​

PD 会监控集群状态，当检测到网络故障时：

  • 暂停调度操作
  • 当网络恢复后，自动恢复调度
  • 重新平衡集群负载

2. 手动干预措施 ​

节点间网络中断 ​

bash
# 检查网络连接
ping `<target-address>`

# 检查网卡状态
ip link show

# 检查网络配置
ip addr show

# 重启网络服务
systemctl restart network

# 检查防火墙配置
firewall-cmd --list-all

网络延迟过高 ​

bash
# 检查网络拥塞情况
tc -s qdisc

# 检查系统负载
uptime

# 检查磁盘 I/O
iotop

# 调整网络参数
sysctl -w net.core.rmem_max=16777216
sysctl -w net.core.wmem_max=16777216
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.ipv4.tcp_wmem="4096 65536 16777216"

网络分区 ​

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

# 查看 PD 成员状态
tiup ctl pd -u http://`<pd-address>`:2379 member

# 查看 Region 状态
tiup ctl pd -u http://`<pd-address>`:2379 region status

# 手动移除故障节点（仅当确认节点无法恢复时）
tiup cluster scale-in `<cluster-name>` --node `<faulty-node-address>`:`<port>`

端口不可达 ​

bash
# 检查服务状态
systemctl status `<service-name>`

# 检查服务配置
cat `<service-config-file>`

# 检查防火墙规则
firewall-cmd --add-port=`<port>`/tcp --permanent
firewall-cmd --reload

# 检查 SELinux 状态
getenforce
setenforce 0

网络故障预防 ​

1. 网络架构设计 ​

  • 使用冗余网络架构
  • 采用万兆或更高带宽网络
  • 合理规划网络拓扑
  • 使用专用网络进行节点间通信

2. 监控和告警 ​

yaml
# 示例 Prometheus 告警规则
groups:
- name: network-alerts
  rules:
  - alert: HighNetworkLatency
    expr: rate(node_network_receive_bytes_total[5m]) / rate(node_network_transmit_bytes_total[5m]) > 0.9
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: "High network latency on {{ $labels.instance }}"
      description: "Network latency is above 90% for 5 minutes"

  - alert: NetworkPacketLoss
    expr: rate(node_network_transmit_drop_total[5m]) > 0
    for: 5m
    labels:
      severity: critical
    annotations:
      summary: "Network packet loss on {{ $labels.instance }}"
      description: "Network packet loss detected for 5 minutes"

3. 定期网络测试 ​

bash
# 定期测试节点间连通性
for node in $(tiup cluster display `<cluster-name>` | grep -E 'tidb|tikv|pd' | awk '{print $1}'); do
  ping -c 5 $node
  echo "---"
done

# 定期测试端口可达性
for node in $(tiup cluster display `<cluster-name>` | grep -E 'tidb|tikv|pd' | awk '{print $1}'); do
  for port in 4000 20160 2379 20180; do
    nc -zv $node $port
  done
done

4. 配置优化 ​

toml
# TiKV 网络配置优化
[server]
# 调整 gRPC 线程数
grpc-concurrency = 8
# 调整 gRPC 超时时间
grpc-keepalive-time = "10s"
grpc-keepalive-timeout = "3s"

# PD 网络配置优化
[grpc]
# 调整 gRPC 超时时间
timeout = "3s"

# TiDB 网络配置优化
[server]
# 调整连接超时时间
tcp-keep-alive = true

网络故障案例分析 ​

案例 1: 节点间网络中断 ​

问题现象 ​

  • 集群中一个 TiKV 节点无法与其他节点通信
  • TiDB Dashboard 显示该节点状态为 Down
  • 相关 Region 变为不可用

诊断过程 ​

  1. 检查节点间连通性，发现 ping 失败
  2. 检查网卡状态，发现网卡故障
  3. 查看系统日志，确认网卡硬件故障

解决方案 ​

  1. 更换故障网卡
  2. 重启网络服务
  3. 验证节点恢复正常
  4. 检查集群状态，确认 Region 恢复正常

案例 2: 网络延迟过高 ​

问题现象 ​

  • 集群性能下降，查询响应时间变长
  • 监控显示网络延迟超过 100ms
  • Raft 选举超时频繁发生

诊断过程 ​

  1. 使用 iperf3 测试网络带宽，发现带宽利用率接近 100%
  2. 检查网络流量，发现有大量异常流量
  3. 定位到异常流量源，是一个应用程序异常发送数据

解决方案 ​

  1. 停止异常应用程序
  2. 调整网络 QoS，优先保障 TiDB 集群流量
  3. 升级网络带宽
  4. 验证集群性能恢复正常

案例 3: 网络分区 ​

问题现象 ​

  • 集群被分割成两个子集群
  • 两个子集群都有自己的 PD Leader
  • 数据出现不一致

诊断过程 ​

  1. 检查网络连接，发现交换机故障导致网络分区
  2. 查看 PD 日志，确认脑裂发生
  3. 检查数据一致性，发现部分数据不一致

解决方案 ​

  1. 修复交换机故障，恢复网络连接
  2. 手动干预，确保只有一个 PD Leader
  3. 使用 TiDB Backup & Restore 工具恢复数据一致性
  4. 验证集群恢复正常

常见问题（FAQ） ​

Q1: 如何检测 TiDB 集群中的网络故障？ ​

A1: 可以通过以下方法检测：

  1. 查看 TiDB Dashboard 监控
  2. 检查集群日志中的网络相关错误
  3. 使用网络工具（如 ping、telnet、iperf3）测试节点间连通性
  4. 配置网络监控告警

Q2: 网络故障会导致 TiDB 数据丢失吗？ ​

A2: 在默认配置下，TiDB 保证数据一致性，网络故障不会导致数据丢失。但在极端情况下，如网络分区持续时间过长，可能会导致数据不一致，需要手动干预恢复。

Q3: 如何处理 TiKV 节点网络延迟过高的问题？ ​

A3: 可以尝试以下解决方案：

  1. 检查网络拥塞情况
  2. 调整网络配置参数
  3. 优化网络拓扑
  4. 升级网络硬件
  5. 调整 TiKV 配置，如增加 gRPC 线程数

Q4: 网络分区发生时，如何避免脑裂？ ​

A4: TiDB 通过以下机制避免脑裂：

  1. Raft 协议要求多数派才能提交写请求
  2. PD 采用 etcd 实现，自带脑裂防护
  3. 合理配置副本数，建议使用奇数副本（3或5）

Q5: 如何优化 TiDB 集群的网络性能？ ​

A5: 可以尝试以下优化：

  1. 使用万兆或更高带宽网络
  2. 采用冗余网络架构
  3. 优化网络配置参数
  4. 调整 TiDB、TiKV、PD 的网络相关配置
  5. 合理规划网络拓扑，减少网络跳数

Q6: 如何处理 PD 节点间网络通信故障？ ​

A6: 可以尝试以下解决方案：

  1. 检查 PD 节点间的网络连通性
  2. 查看 PD 日志，分析故障原因
  3. 重启故障 PD 节点
  4. 如无法恢复，考虑移除故障节点并添加新节点

Q7: 网络故障导致 TiKV 节点离线，如何处理？ ​

A7: 可以尝试以下解决方案：

  1. 检查网络连接，修复网络故障
  2. 重启 TiKV 节点
  3. 如无法恢复，使用 tiup cluster scale-in 移除故障节点
  4. 使用 tiup cluster scale-out 添加新节点

Q8: 如何配置 TiDB 集群的网络监控？ ​

A8: 可以通过以下步骤配置：

  1. 确保 Prometheus 和 Grafana 已部署
  2. 导入 TiDB 官方提供的 Grafana 仪表板
  3. 配置网络相关的告警规则
  4. 定期查看监控数据，分析网络性能

Q9: 如何测试 TiDB 集群的网络吞吐量？ ​

A9: 可以使用以下工具测试：

  1. iperf3：测试网络带宽
  2. ping：测试网络延迟
  3. sysbench：测试数据库性能，间接反映网络性能
  4. TiDB 自带的压测工具：如 go-ycsb、tiup bench

Q10: 网络故障恢复后，如何验证 TiDB 集群恢复正常？ ​

A10: 可以通过以下步骤验证：

  1. 检查集群状态：tiup cluster display <cluster-name>
  2. 检查所有节点状态：tiup cluster health <cluster-name>
  3. 运行简单查询测试：select 1;
  4. 运行性能测试：tiup bench tpcc --db tpcc --host <tidb-address> --port 4000 --user root --password <password> --warehouses 10 run --time 300
  5. 检查数据一致性：tiup sync-diff-inspector --config ./sync-diff-config.toml

Q11: 如何处理 TiDB 集群中的防火墙问题？ ​

A11: 可以尝试以下解决方案：

  1. 检查防火墙规则：iptables -L -n
  2. 开放 TiDB 集群所需端口：4000（TiDB）、20160（TiKV）、2379（PD）、20180（TiKV 状态）、2380（PD 节点间通信）
  3. 考虑关闭防火墙（仅在安全环境中）
  4. 使用防火墙白名单，仅允许集群节点通信

Q12: 如何处理 TiDB 集群中的 DNS 问题？ ​

A12: 可以尝试以下解决方案：

  1. 使用 IP 地址代替主机名配置集群
  2. 检查 DNS 配置：cat /etc/resolv.conf
  3. 测试 DNS 解析：nslookup <hostname>
  4. 考虑使用本地 hosts 文件：echo "<ip-address> <hostname>" >> /etc/hosts

Q13: 如何处理 TiKV 节点间的 gRPC 连接问题？ ​

A13: 可以尝试以下解决方案：

  1. 检查 gRPC 端口是否可达：nc -zv <tikv-address> 20160
  2. 查看 TiKV 日志中的 gRPC 相关错误
  3. 调整 TiKV 的 gRPC 配置参数
  4. 检查网络 MTU 设置，确保所有节点一致

Q14: 如何处理 TiDB 客户端连接超时问题？ ​

A14: 可以尝试以下解决方案：

  1. 检查网络连通性：ping <tidb-address>
  2. 检查 TiDB 服务状态：tiup cluster display <cluster-name>
  3. 调整客户端连接超时参数
  4. 增加 TiDB 节点数量，分散连接负载
  5. 检查 TiDB 配置中的最大连接数：max-connections

Q15: 如何规划 TiDB 集群的网络拓扑？ ​

A15: 网络拓扑规划建议：

  1. 使用专用网络进行节点间通信
  2. 采用分层网络架构，核心层、汇聚层、接入层
  3. 确保网络冗余，避免单点故障
  4. 合理规划 VLAN，隔离不同服务
  5. 考虑网络延迟，将相关组件部署在同一机架或机房