PD 节点启动报 etcd server 超时通常由网络不通、磁盘 IO 过高或时间不同步导致。优先检查 pd.log 日志和网络连通性，若数据目录损坏需清理后重启，但清理数据前需确认集群状态以避免数据丢失。
先说结论：PD 内嵌 etcd 组件，启动超时多为基础设施问题，先排查网络和磁盘，最后再考虑清理数据。
- 先确认：服务器时间是否同步、磁盘空间是否充足、端口是否被占用。
- 先处理：修复网络连通性、清理异常锁文件、重置损坏的数据目录。
- 再验证：使用 pd-ctl 检查集群状态、观察日志不再报错。
命令速用版
# 查看 PD 日志末尾报错
tail -n 100 /tidb-data/pd/log/pd.log
# 检查服务器时间同步
date
# 检查磁盘使用率
df -h
# 检查 PD 端口监听情况
netstat -nltp | grep 2379
# 尝试重启 PD 服务（使用 tiup 或 systemd）
(tiup cluster restart <cluster-name> -R pd) 或 (systemctl restart pd.service)为什么会这样
PD 服务依赖内嵌的 etcd 存储元数据，etcd 对网络延迟和磁盘 IO 非常敏感。报错 etcd server 超时意味着 PD 节点无法在指定时间内完成 leader 选举或与 peers 建立连接。常见原因包括服务器之间网络抖动、磁盘写入延迟过高、系统时间偏差超过容忍阈值，或者本地数据目录存在脏数据导致 etcd 无法加载。
分步处理
步骤 1：检查基础资源状态
登录报错的 PD 节点，执行 df -h 确认磁盘未满，执行 date 对比其他节点时间偏差。若时间偏差超过 500ms，需配置 NTP 同步。若磁盘使用率超过 90%，需清理空间。
步骤 2：检查网络连通性
使用 ping 和 telnet 测试该节点与其他 PD 节点的 IP 及端口（默认 2379 和 2380）。若端口不通，检查防火墙规则或安全组设置，确保集群内网互通。
步骤 3：查看具体日志报错
打开 pd.log 搜索 "timeout" 或 "etcd" 关键字。若看到 "data directory corrupted" 或 "wal 文件损坏"，说明本地数据不可用。
步骤 4：清理数据目录（高风险操作）
若确认数据损坏且无法修复，需清空该节点的 PD 数据目录。操作前务必确认集群中其他 PD 节点正常，避免集群不可用。停止 PD 服务后，删除 data 目录下的内容，然后重新启动服务。
步骤 5：调整启动参数（可选）
若因磁盘慢导致超时，可在启动配置中适当增加 etcd 的超时参数，但公开资料中没有看到可靠的量化数据建议具体数值，需根据实际日志调整。
怎么验证是否生效
启动完成后，再次查看 pd.log，确认没有新的 "timeout" 报错。使用 pd-ctl 工具连接集群，执行 member 命令查看该节点是否出现在成员列表且状态健康。若使用 TiUP 管理，执行 tiup cluster display <cluster-name> 确认所有 PD 节点状态为 UP。
常见坑
1. 勿同时清理所有 PD 数据： 若集群多节点同时报错，切勿同时清空所有节点数据目录，否则会导致元数据丢失，集群无法恢复。
2. 时间同步必须严格： etcd 对时钟漂移敏感，即使网络通畅，时间不同步也会导致选举失败。
3. 注意宿主机负载： 若宿主机 CPU 或 IO 满载，etcd 心跳包可能无法及时处理，引发假性超时。
常见问题
PD 节点重启后依然报超时怎么办？
检查是否有残留进程占用端口，使用 lsof -i :2379 确认端口释放情况，必要时强制杀死旧进程后再启动。
清理数据目录会丢失业务数据吗？
PD 只存储元数据不存储业务行数据，但丢失元数据会导致集群无法调度，需确保其他 PD 节点有完整元数据副本。
能否直接调大超时参数解决？
调大参数仅能掩盖性能问题，若根本原因是磁盘故障或网络中断，调大参数可能导致故障检测延迟，建议优先修复基础设施。
参考来源
- PingCAP 官方文档 - TiDB 运维指南，页面标题：PD 运维常见故障处理，URL：https://docs.pingcap.com/zh/tidb/stable
- etcd 官方文档 - 故障排查，页面标题：etcd troubleshooting，URL：https://etcd.io/docs/latest/op-guide/failures/