【GreatSQL 茶话会 02】在运维过程中你遇到过哪些头大的问题
GreatSQL 茶话会第二期来啦！！！本期话题：在运维过程中你遇到过哪些令人头大的故障/问题？
在本帖下参与互动回复，即可获得对应的活动奖励，更有机会获取社区定制周边一件！快来说说你的想法吧~
活动奖励
[*]参与讨论者（回复内容 20 字以上）：社区金币 300 个；
[*]回复的内容获得点赞数最多者（点赞数需不小于 5）：数据库书籍 / GreatSQL 保温杯（黑/白）/ 卫衣 1 件。
活动时间
点赞数量统计截止时间：2023.4.2 24:00
GreatSQL 保温杯（黑/白）/ 卫衣 ：
数据库书籍：
感谢大家的参与，本次茶话会已结束，根据点赞数量统计公布获奖名单：
点赞最多奖：MySQL DBA工作笔记；
获奖用户名：hufeng719；
精华回帖奖：社区金币 500 个；
获奖用户名：beon；yejr；aontimer；flywiththewind；
参与回帖奖：社区金币 300 个；
获奖用户名：臧喜运；sunli8523；王权富贵；刘西瓜；guohaohub；shynodes；
第三期茶话会将于 4 月中旬开始，欢迎大家继续参与~
本帖最后由 beon 于 2023-3-21 14:42 编辑
运维过单实例30+TB，存储的是一些历史数据，但是经常做一些分析查询和数据导入。
由于实例体量大，导致运维压力很大，包括常规的备份、主从数据一致性校验、切换和重启等都不敢执行(因为历史上曾经有一次重启花费了6小时)。
后期可能会借助贵司的gt-checksum进行主从的数据同步，与局方讨论删除过期数据降低数据量，并增加监控等方式减小运维难度，增强系统高可用。
1、技术与人员，资金与单位的全方位支持，这些都是各个单位的通病，也是运维工作的多年的诟病！ 遇到搞不定的问题，每天都在反思，我究竟是哪里错了。。 写文档，尤其是遇到不会的方面，还要必须写出文档来，1个头10个大。根本写不出来。 生产遇到过的问题，有的时候很难再复现，这个就很头疼，不知道下回啥时候再出现。还有客户的现场不能远程，只能一点点发图片看，也很头疼。 两次，都是其他同事搞出来的飞机
1、要更新几行记录，结果忘了加where条件，直接变成全表更新，最后只好通过备份进行恢复。
2、和第一次类似，也是忘了写where条件，全表删除。
因此养成了一个习惯，重要操作前，会先把相关命令提前写好在外部文档，再复制进去执行。
同时，写任何SQL前，都先把where条件写好，再写前面的内容。 1、生产环境，虚拟化中数据库服务器虚拟机单机运行，因底层存储池空间满，造成部分虚拟机无法进入系统。尤其是部分windows系统的虚拟机无法进入操作系统，业务还一直打电话，相信这个时候无论哪个运维人员都会慌。没办法先利用备份恢复数据库到一台其他在用的windows环境先考虑恢复业务，再查原因。恢复数据库又面临一个部分数据丢失的问题，幸亏当时对sqlserver的事务日志每小时也做了备份，最多只能丢失1小时的数据，这也造成了部分过完一检的车辆无法回皮现象。没办法只能人工处理。所以得出的教训：重要的业务数据库最好集群部署给自己省麻烦，不然你为公司考虑的降低投入成本公司看不到价值体现，反而如果真出了问题，却是运维人员自己兜着。 本帖最后由 aontimer 于 2023-3-29 12:03 编辑
给数百家公司做过维护。
其实最头大的是每一家公司都没有监控系统。包括浙江电力都是裸奔的。
然后我从头搭建监控系统。通过跟大神学习。掌握了怎么部署监控。学习怎么运营数据库。最后也感谢一路上帮助过我的老师
后期可能会借助贵司的gt-checksum进行主从的数据同步，与局方讨论删除过期数据降低数据量，并增加监控等方式减小运维难度，增强系统高可用。
你给公司保存好数据就是你最大的能力。在数据保存完整的情况下再谈高可用什么的
表的数据量太大。需要定期晚上做数据分表操作，而且每次执行sql语句，都要sql优化.
页:
[1]
2