【 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的框架里上去的
第二，流程肯定比大多数公司要正规化支付公司 受到的攻击比较多
- 生产环境上线sql之前最好在测试环境测试，如果没有测试环境最好做下审核
2.tidb集群中如果通过scale-in收缩了tikv节点，节点会处于offline状态，但是集群还是可以用的，只要添加节点进去，让数据转移到新的节点上，然后移除offline的就可以了。如果是物理删除了那就只能通过备份进行恢复了，所以备份很重要。 - 机房断电之后，来电之后如果开启了自动启动，集群会自动启动。如果起不来需要手动启动，这些东西是没法避免的，也是DBA存在的价值。
1.甩锅开发
2.甩锅运维
3.甩锅机房运维
1 个赞
系统软件内部机制故障：无法避免，选型，测试，交付，维护每个环节做到优+
人为操作故障：通过访问控制，权限细分管理，操作记录，操作流程规范，AB审核
这种被挂其实和机器多少无关 但灰天鹅。需要一个流程避免故障
简单总结就是两个词，规范+高可用
我们现在是会把数据脱敏了，导入准生产环境，如果要上线，需要在准生产环境验证的
业务最简单的是我看到的云效 devops系统 表代码都会自动同步
遇到过运维见服务器空间不够了，觉得oracle 数据文件占的最大，然后全删了
备份不可或缺
我也遇到过
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。