【GreatSQL 茶话会 02】在运维过程中你遇到过哪些头大的问题

感谢大家的参与，本次茶话会已结束，根据点赞数量统计公布获奖名单：

点赞最多奖：MySQL DBA工作笔记；
获奖用户名：hufeng719；

精华回帖奖：社区金币 500 个；
获奖用户名：beon；yejr；aontimer；flywiththewind；

参与回帖奖：社区金币 300 个；
获奖用户名：臧喜运；sunli8523；王权富贵；刘西瓜；guohaohub；shynodes；

第三期茶话会将于 4 月中旬开始，欢迎大家继续参与~

运维过单实例30+TB，存储的是一些历史数据，但是经常做一些分析查询和数据导入。

由于实例体量大，导致运维压力很大，包括常规的备份、主从数据一致性校验、切换和重启等都不敢执行(因为历史上曾经有一次重启花费了6小时)。

后期可能会借助贵司的gt-checksum进行主从的数据同步，与局方讨论删除过期数据降低数据量，并增加监控等方式减小运维难度，增强系统高可用。

1、技术与人员，资金与单位的全方位支持，这些都是各个单位的通病，也是运维工作的多年的诟病！

遇到搞不定的问题，每天都在反思，我究竟是哪里错了。。

写文档，尤其是遇到不会的方面，还要必须写出文档来，1个头10个大。根本写不出来。

生产遇到过的问题，有的时候很难再复现，这个就很头疼，不知道下回啥时候再出现。还有客户的现场不能远程，只能一点点发图片看，也很头疼。

两次，都是其他同事搞出来的飞机
1、要更新几行记录，结果忘了加where条件，直接变成全表更新，最后只好通过备份进行恢复。
2、和第一次类似，也是忘了写where条件，全表删除。

因此养成了一个习惯，重要操作前，会先把相关命令提前写好在外部文档，再复制进去执行。
同时，写任何SQL前，都先把where条件写好，再写前面的内容。

1、生产环境，虚拟化中数据库服务器虚拟机单机运行，因底层存储池空间满，造成部分虚拟机无法进入系统。尤其是部分windows系统的虚拟机无法进入操作系统，业务还一直打电话，相信这个时候无论哪个运维人员都会慌。没办法先利用备份恢复数据库到一台其他在用的windows环境先考虑恢复业务，再查原因。恢复数据库又面临一个部分数据丢失的问题，幸亏当时对sqlserver的事务日志每小时也做了备份，最多只能丢失1小时的数据，这也造成了部分过完一检的车辆无法回皮现象。没办法只能人工处理。所以得出的教训：重要的业务数据库最好集群部署给自己省麻烦，不然你为公司考虑的降低投入成本公司看不到价值体现，反而如果真出了问题，却是运维人员自己兜着。

给数百家公司做过维护。

其实最头大的是每一家公司都没有监控系统。包括浙江电力都是裸奔的。
然后我从头搭建监控系统。通过跟大神学习。掌握了怎么部署监控。学习怎么运营数据库。最后也感谢一路上帮助过我的老师
后期可能会借助贵司的gt-checksum进行主从的数据同步，与局方讨论删除过期数据降低数据量，并增加监控等方式减小运维难度，增强系统高可用。
你给公司保存好数据就是你最大的能力。在数据保存完整的情况下再谈高可用什么的

表的数据量太大。需要定期晚上做数据分表操作，而且每次执行sql语句，都要sql优化.