【最近一次/印象最深的运维 TiDB 时的误操作】业务高峰期往同步到下游mysql数据库的大表添加索引，造成同步表有三小时的延时同步，相关报表业务全错
【最后是怎么解决的】 实时监控，查看数据是不是还在同步，防止下游堆积过多同步宕机
【给小伙伴们一些避坑建议吧～】执行索引之前看表大小，执行时避开出报表时机，提前预估执行时间，给下游数据使用侧打预防针
【最近一次/印象最深的运维 TiDB 时的误操作】
当年测试的时候，给执行错命令，linux里给chmod -R 777 /,搞得权限不对啦
【最后是怎么解决的】
克隆 其他机器，重新安装
【给小伙伴们一些避坑建议吧～】
慎用高权限用户
2 个赞
把tiup的隐藏目录.tiup目录给删除了
最后是从其他相同版本的环境给构建出来
【最近一次/印象最深的运维 TiDB 时的误操作】
个人测试使用失误，误删数据
【最后是怎么解决的】
备份还原啦
【给小伙伴们一些避坑建议吧～】
操作需谨慎，记得备份
【最近一次/印象最深的运维 TiDB 时的误操作】
误删除部分联表数据
【最后是怎么解决的】
备份数据进行恢复
【给小伙伴们一些避坑建议吧～】
定时备份很重要，留一手
批量删除数据的时候脚本没写好，放在了crontab里面结果大面积堵塞延迟。
立马把脚本停了，然后进程里面一直kill kill kill
删除脚本先小量测试，最后在大批量执行。
记忆中没啥，以其事后补救还不如事前谨慎一些
印象最深的TiDB误操作：误删PD节点导致集群短暂不可用
事件经过：
执行PD缩容时，误将最后一个PD节点下线（未保留旧节点），导致TiKV无法访问PD获取元信息，集群查询超时，业务请求失败约10分钟。
原因：
未遵循“缩容PD时保留至少一个旧节点”的规范，且未检查TiKV缓存的PD列表状态。
恢复：
紧急重启PD服务并手动指定新Leader，恢复后升级集群版本启用自动PD节点更新机制。
教训：
操作前必须核对节点状态，缩容需分步验证，避免集中下线关键组件。
突然这么一问，忘记了 
【最近一次/印象最深的运维 TiDB 时的误操作】
高峰时段扩缩容多台KV，集群拥堵的时候reload重启
【最后是怎么解决的】
等待消化
【给小伙伴们一些避坑建议吧～】
千万不要做以上错误操作- -！
【最近一次/印象最深的运维 TiDB 时的误操作】
由于安装了操作系统的一个桌面组件，把内核改了，导致系统重启登陆不上
【最后是怎么解决的】
通过扩容的方式重新搭建了一个节点
【给小伙伴们一些避坑建议吧～】
谨慎谨慎再谨慎
【最近一次/印象最深的运维 TiDB 时的误操作】
最近一次不是误操作，而是主控云服务器丢失，导致 TiDB 集群无法通过 TiUP 运维
【最后是怎么解决的】
最后是记得几个月以前备份过 TiUP 元数据文件，通过手动处理一些文件配置，重新将集群接入到 TiUP 管理
【给小伙伴们一些避坑建议吧～】
备份很重要
【最近一次/印象最深的运维 TiDB 时的误操作】
与其他服务共享的主机资源，导致性能不足引起tidb响应缓慢
【最后是怎么解决的】
将其他服务迁移出去
【给小伙伴们一些避坑建议吧～】
数据库服务独立服务器运行，配备足够的资源
【最近一次/印象最深的运维 TiDB 时的误操作】
误删库
【最后是怎么解决的】
参考官方文档进行数据恢复
【给小伙伴们一些避坑建议吧～】
一定要谨慎操作
config.yaml中使用了默认配置文件
应该进行实际调整，同时修改前备份文件
最近一次/印象最深的运维 TiDB 时的误操作】
在一次业务高峰期，我需要为一个大表添加索引来优化查询性能。由于时间紧迫，我直接在生产环境执行了 CREATE INDEX语句，没有充分评估影响。结果这个 DDL 操作导致了 TiKV 节点 CPU 使用率飙升，大量慢查询涌现，业务响应时间明显变慢。
【最后是怎么解决的】
紧急干预：首先使用 ADMIN CANCEL DDL JOBS <job_id>取消了正在进行的索引创建任务
流量降级：临时与业务方沟通，降低了部分非核心业务的写入流量
择机重做：在业务低峰期（凌晨2点）重新执行索引创建，并使用了 ALGORITHM=INPLACE参数减少锁表时间
监控恢复：密切观察 TiDB Dashboard 和 Grafana 监控指标，确保集群性能恢复正常
【给小伙伴们一些避坑建议吧~】
避开高峰：DDL 操作一定要选择业务低峰期进行，提前与业务团队协调时间窗口
测试先行：在测试环境先验证大表 DDL 操作的影响和耗时
使用工具：考虑使用 TiDB 的在线 DDL 相关工具或分批次执行策略
监控预警：操作前设置好告警阈值，操作期间实时关注集群关键指标
备份预案：重要变更前做好数据备份和回滚预案
这次经历让我深刻体会到，即使是 TiDB 支持在线 DDL，对于大数据量的表操作仍需谨慎规划，做好充分准备才能确保业务稳定性。
符合活动要求的参与格式，期待与各位 TiDBer 交流更多运维经验！
我的错误简单 IP地址少打了一位 整个tikv都清了。。。
【最近一次/印象最深的运维 TiDB 时的误操作】
update错数据
【最后是怎么解决的】
使用备份数据回滚
【给小伙伴们一些避坑建议吧～】
操作一定要记得备份
误删除数据
【最后是怎么解决的】
使用恢复命令将误删除的数据进行恢复
【给小伙伴们一些避坑建议吧～】
备份（数据和配置文件）；两人操作，相互监督
目前没有，运维要胆大心细，敬畏生产