【最近一次/印象最深的运维 TiDB 时的误操作】
线上删除操作where条件写错了，导致误删整个表的数据…
【最后是怎么解决的】
修改gc时间，然后将操作前的数据dump下来重新导入，然后进行修复
【给小伙伴们一些避坑建议吧～】
线上操作时候一定要小心谨慎！
【最近一次/印象最深的运维 TiDB 时的误操作】
线上CR被删掉（非误操作，程序bug）
【最后是怎么解决的】
好在是 tidb 的 operator 不删 pvc，通过重建同样的 cr 恢复了，业务中断了一段时间，但是数据没丢
【给小伙伴们一些避坑建议吧～】
pvc 不要立即随着 cr 删掉，保留一段时间。
【最近一次/印象最深的运维 TiDB 时的误操作】
无
【最后是怎么解决的】
无
【给小伙伴们一些避坑建议吧～】
备份、权限管理一定要做好，任何敏感操作之前都要再三确认再去执行。
pd挂了，最后根据官方文档使用日志，重建pd好了
【最近一次/印象最深的运维 TiDB 时的误操作】
kv数据盘使用率达到 95%，db节点突然无法接受新连接，重启 db 节点也无效
【最后是怎么解决的】
阔盘，见 无法连接至 tidb，重启 tidb 节点报错，系统表 cop 时间过长
【给小伙伴们一些避坑建议吧～】
一定及时扩容
【最近一次/印象最深的运维 TiDB 时的误操作】
误删 .tiup 文件夹
【最后是怎么解决的】
参考帖子 tiup工具如果丢失后有重塑的方案么？
【给小伙伴们一些避坑建议吧～】
备份吧，一定要备份。
【最近一次/印象最深的运维 TiDB 时的误操作】
没有
【最后是怎么解决的】
无
【给小伙伴们一些避坑建议吧～】
最小化权限管控，定期备份
【最近一次/印象最深的运维 TiDB 时的误操作】
最近出现过一次某个tikv节点io流量断崖式下跌，在top sql中没有执行语句。
【最后是怎么解决的】
扩缩容节点解决
【给小伙伴们一些避坑建议吧～】
及时监控
【最近一次/印象最深的运维 TiDB 时的误操作】
误删测试数据
【最后是怎么解决的】
使用备份还原
【给小伙伴们一些避坑建议吧～】
定期备份数据
【最近一次/印象最深的运维 TiDB 时的误操作】
晚上给客户升级tidb版本，好像是4.0的版本升级到5.0，很久之前的事情了；升级完之后，简单的查询都比较慢，蒙蔽了，因为马上客户要到营业时间了
【最后是怎么解决的】
重启集群
【给小伙伴们一些避坑建议吧～】
低版本的问题估计不少，7.5.1目前看还是比较稳定
【最近一次/印象最深的运维 TiDB 时的误操作】
没有误操作
【最后是怎么解决的】
没有误操作
【给小伙伴们一些避坑建议吧～】
每次执行前，都先检查一下
【最近一次/印象最深的运维 TiDB 时的误操作】
同事把低版本的数据库升级到横跨好几个大版本号的最新版本
【最后是怎么解决的】
回归到一个相对变化较小的版本
【给小伙伴们一些避坑建议吧～】
做一些操作时，谨慎谨慎谨慎
【最近一次/印象最深的运维 TiDB 时的误操作】
目前没有误操作
【最后是怎么解决的】
没有
【给小伙伴们一些避坑建议吧～】
做任何操作先开启录屏，生产环境需要输入的命令先整理好，二个及以上的相关人员检查后再复制输入
【最近一次/印象最深的运维 TiDB 时的误操作】
误删测试表为生产表
【最后是怎么解决的】
上游找回数据
【给小伙伴们一些避坑建议吧～】
变更双人复核，严格区分生产测试环境
就在最近吧，9月底
【最近一次 / 印象最深的运维 TiDB 时的误操作】上周做 TiKV 节点扩容后，想清理旧节点的残留数据，结果手滑把 正在运行的新 TiKV 节点数据目录（/data/tidb-data/tikv-20160） 删了 —— 当时没注意节点 IP 输错了，执行 rm -rf /data/tidb-data/tikv-20160/* 后，监控瞬间报 “TiKV 实例离线”，集群部分 Region 变成 “不可用” 状态，业务查询开始超时。
【最后是怎么解决的】
- 第一时间停止该 TiKV 节点（
tiup cluster stop tidb-test --node 172.20.20.11:20160），避免残留进程干扰； - 查看 PD 日志确认该节点的 Region 分布，发现有 32 个 Region 的 Leader 或 Follower 在这个节点上，且均有其他副本（因为是 3 副本架构）；
- 在原节点重新初始化 TiKV 数据目录：先删除残留的
store.id文件（rm /data/tidb-deploy/tikv-20160/conf/store.id），再启动 TiKV（tiup cluster start tidb-test --node 172.20.20.11:20160），让 PD 重新分配 Region 副本； - 启动后通过
tiup ctl pd -u http://172.20.20.22:2379 region check监控 Region 恢复进度，约 15 分钟后所有 Region 均恢复 “健康” 状态，业务查询恢复正常； - 事后用
tiup cluster audit查看操作记录，确认是 IP 输错导致误删，同时补了数据目录备份脚本（每天凌晨备份store.id和关键元数据）。
【最近一次/印象最深的运维 TiDB 时的误操作】
未出现过
【最后是怎么解决的】
未出现过
【给小伙伴们一些避坑建议吧～】
对生产规范操作和需要有敬畏之心
【最近一次/印象最深的运维 TiDB 时的误操作】
未出现过
【最后是怎么解决的】
未出现过
【给小伙伴们一些避坑建议吧～】
备份配置，备份数据，谨慎谨慎
【最近一次/印象最深的运维 TiDB 时的误操作】
没有误操作，最近一次忘记了部署监控，机器宕了不知道，影响了业务
【最后是怎么解决的】
完善监控
【给小伙伴们一些避坑建议吧～】
谨慎操作，做好备份，敬畏生产。
【最近一次/印象最深的运维 TiDB 时的误操作】
当年测试的时候，给执行错命令，linux里给chmod -R 777 /,搞得权限不对啦
【最后是怎么解决的】
克隆 其他机器，重新安装
【给小伙伴们一些避坑建议吧～】
慎用高权限用户
【最近一次/印象最深的运维 TiDB 时的误操作】
错误删除数据
【最后是怎么解决的】
开24小时gc ，用dumlping备份指定时间数据，再导入
【给小伙伴们一些避坑建议吧～】
如果没性能问题，gc时间可以长点