做dba的故障大家来说说怎么防范.

【 TiDB 使用环境`】生产环境
【 TiDB 版本】
【遇到的问题】
问题1
开发上线了一个sql.突然把生产库搞垮了
问题2
运维动服务器.把tikv节点都删除了
问题3
机房断电了.pd起不来了

你们说奇葩不奇葩.怪事都让我遇到了

【复现路径】做过哪些操作出现的问题
【问题现象及影响】

【附件】

请提供各个组件的 version 信息,如 cdc/tikv,可通过执行 cdc version/tikv-server --version 获取。

本来想写代码摸鱼的 结果忙成狗

泡妹子的时间都浪费在tidb上

银行里一般这么管库
1、架构层面做好容灾和高可用
2、业务上线流程中加入SQL审核环节
3、对生产库做好监控,有慢查询或者故障时及时发现
4、做好运维人员的权限管理,并以运维工单审批模式进行授权

一般做好权限分离,重大操作双人复核

问题1
这种是设定审核规则。上线前全审核,有工具的用工具,没工具的想办法,人肉也要审核。

问题2
变更要经过相关流程的审核,总能审核出来这些命令是不是高危的。所有人都审核不出来,说明都是糊涂。该出问题了。但是一般来说不会。

问题3
基础设施要有UPS,发电机等。如果这些都用了还不行。数据库容灾要考虑。这种比起前面来说概率低。

还需要大家集思广益

前两条毋庸置疑了,很多公司都这样做,我们也是。

第一,其实发生情况的时候审核工具也有了 sql是藏在spring boot的框架里上去的
第二,流程肯定比大多数公司要正规化支付公司 受到的攻击比较多

  1. 生产环境上线sql之前最好在测试环境测试,如果没有测试环境最好做下审核
    2.tidb集群中如果通过scale-in收缩了tikv节点,节点会处于offline状态,但是集群还是可以用的,只要添加节点进去,让数据转移到新的节点上,然后移除offline的就可以了。如果是物理删除了那就只能通过备份进行恢复了,所以备份很重要。
  2. 机房断电之后,来电之后如果开启了自动启动,集群会自动启动。如果起不来需要手动启动,这些东西是没法避免的,也是DBA存在的价值。

1.甩锅开发
2.甩锅运维
3.甩锅机房运维
:joy:

1 个赞

系统软件内部机制故障:无法避免,选型,测试,交付,维护每个环节做到优+

人为操作故障:通过访问控制,权限细分管理,操作记录,操作流程规范,AB审核

这种被挂其实和机器多少无关 但灰天鹅。需要一个流程避免故障

简单总结就是两个词,规范+高可用

我们现在是会把数据脱敏了,导入准生产环境,如果要上线,需要在准生产环境验证的

业务最简单的是我看到的云效 devops系统 表代码都会自动同步

遇到过运维见服务器空间不够了,觉得oracle 数据文件占的最大,然后全删了:sweat_smile:

备份不可或缺

我也遇到过

此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。