【最近一次/印象最深的运维 TiDB 时的误操作】
日志表过大，想着rename然后重建表，在命令行操作的，结果默认值那些comment信息没带上，导致默认值无法填写，程序报错
【最后是怎么解决的】
表删除通过navicat重建
【给小伙伴们一些避坑建议吧～】
mysql命令行重建表，需要加-C，否则有些特殊用法不包含
执行计划变动，受到mvcc影响。
加hint解决
【最近一次/印象最深的运维 TiDB 时的误操作】
误删一张表，恢复数据的时候吧原id也恢复了，导致新数据插入冲突
【最后是怎么解决的】
重新恢复数据不带id主键
【给小伙伴们一些避坑建议吧～】
谨慎操作
我apt install mysql-client 装的最新客户端默认带注释了
没发生过很严重的误操作
【最近一次/印象最深的运维 TiDB 时的误操作】
误删数据
【最后是怎么解决的】
利用备份恢复
【给小伙伴们一些避坑建议吧～】
操作前谨慎操作，多做备份
【最近一次/印象最深的运维 TiDB 时的误操作】
好像没有
【最后是怎么解决的】
不用解决
【给小伙伴们一些避坑建议吧～】
操作前，吧步骤写好，想好备用方案或者恢复方案，在动手为好～
【最近一次/印象最深的运维 TiDB 时的误操作】
误删多张表。
【最后是怎么解决的】
延长 GC 保留时间后，通过FLASHBACK TABLE t;恢复。
【给小伙伴们一些避坑建议吧～】
别怕误删，怕的是没准备。
暂无
遇到最多的问题是慢查询，优化SQL
建议操作前检查命令，还有备份，备份，备份，重要的事情说3遍！[呲牙]
【最近一次/印象最深的运维 TiDB 时的误操作】
在数据源连接串中增加了预编译的参数，导致触发jdbc驱动bug，出现小数位丢失
【最后是怎么解决的】
回退连接串配置
【给小伙伴们一些避坑建议吧～】
生产中的变更务必在测试环境中验证
【最近一次/印象最深的运维 TiDB 时的误操作】
删除了本地的数据文件
【最后是怎么解决的】
从binlog日志恢复备份
【给小伙伴们一些避坑建议吧～】
删除前做好备份
【最近一次/印象最深的运维 TiDB 时的误操作】
目前没有误操作,而且测试环境偏多
【最后是怎么解决的】
没有
【给小伙伴们一些避坑建议吧～】
生产环境需要输入的命令先整理好，认真，仔细，不要着急
【最近一次/印象最深的运维 TiDB 时的误操作】
清理磁盘空间时候，目录为多次确认，结果误删除了 tikv 的数据目录
【最后是怎么解决的】
最后还是使用缩容与扩容的节点方式
【给小伙伴们一些避坑建议吧～】
rm -rf 一定慎重执行，rm -rf 一定慎重执行，rm -rf 一定慎重执行，
【最近一次/印象最深的运维 TiDB 时的误操作】
误删测试数据
【最后是怎么解决的】
使用备份恢复
【给小伙伴们一些避坑建议吧～】
配置定期备份
【最近一次/印象最深的运维 TiDB 时的误操作】
这个没有呢。好多年前运维Oracle倒是发生一件至今难忘的事。
【最后是怎么解决的】
无。
【给小伙伴们一些避坑建议吧～】
无。
【最近一次/印象最深的运维 TiDB 时的误操作】
无
【最后是怎么解决的】
无。
【给小伙伴们一些避坑建议吧～】
数据库操作要慎之又慎，仔细检查再操作。
【最近一次/印象最深的运维 TiDB 时的误操作】
GC关闭了忘记打开
【最后是怎么解决的】
打开GC
【给小伙伴们一些避坑建议吧～】
加上GC延迟告警
最近一次大的误操作是在mysql 上，用mysql dump 备份出来的整库备份来重建一套新的库表结构，结果把同实例上老库清空了
原因是，mysql dumper 备份出来的整库表结构，具体内容如下；
use database1;
drop table1
create table1
我实际的想法是，想在这个实例上，重新创建database2
然后在里面创建一整套表结构
结果把线上database1 全部清空了
我们金融行业
教训：
1、开盘期间不要上生产环境实例进行操作
2、用小权限账号操作，单次变更，可以仅仅创建最小化账号操作
3、多个环境的数据库，不要混合在生产环境实例上。现在没问题，后期也可能又资源竞争问题
4、一定要有备份，定期检验备份可用性。【增加监控、告警，检查XX库可用备份数】
1 个赞
【最近一次/印象最深的运维 TiDB 时的误操作】
当年测试的时候，给执行错命令，linux里给chmod -R 777 /,搞得权限不对啦
【最后是怎么解决的】
克隆 其他机器，重新安装
【给小伙伴们一些避坑建议吧～】
慎用高权限用户
2 个赞