数据库管理-第五十三期 新春快乐（20230122）

第五十三期 新春快乐

本来这周正值新年，是准备休息1-2周的，但是想了想还是咬咬牙坚持写点东西。

1 拜个年

首先呢，在这辞旧迎新之际，祝大家“兔”飞猛进，大展宏“兔”，前“兔”似锦，前“兔”无量，“兔” be No.1！
其实今年也是我去移动驻场这么多年第一次大年三十现场值守，从早上9点半到晚上12点，其实什么事情都是做好准备了的，整体也十分平稳。今年和往年不同，客户管饭了，整体菜品还是很丰盛的，也算是和客户及友商一次吃了一次年夜饭。到晚上也是电视放着春晚（真心不好看），一遍挂着监控（偶尔两把游戏,3060不能浪费了=_=）。

2 干好本职

作为一个 “苦逼”的小外包，其实我还是做好了自己的事情，把涉及项目技术层面的事情给做好了，不出问题。当然再此基础上，还作为公司“间谍”从客户那获取机会，一半销售一半售前，再过去的一年里还是为接下来的一年扩展了不少的“工作内容”，产生了一定的价值。
回到驻场本身，刚开始的时候其实我也挺难的，人生地不熟，交接只有3天，说白了只知道有哪些服务器和关键客户，其余就啥都不知道了。还好技术“扎实”，给熬过来了。刚开始驻场的时候，有些东西也是“小白”，有些东西总想在技术上争个输赢然后也就造成了20年一季度的一次考核扣款，原因虽是12.2私网异常发包引起私网拥塞节点踢出集群的bug。但是一开始我并没有重视，总想从数据库之外的地方，比如网络、网卡、操作系统等层面找原因，最后无功而返，打了补丁解决问题。（从这时候开始，超出自己能力范围的问题我也无条件的相信MOS了）
从那时起，我就想明白了，作为个技术服务行业工作者，帮客户解决问题才是首要的，纯纯技术上的所谓的“输赢”，都仅仅是锦上添花。能够让自己维护的那一亩三分地不出问题，其实才是对客户最大的负责（当然我也看到有些客户总要一些那所谓的“工作量”）。
在我的工作过程接触到一些事情，其实挺极端的。

• 第一件事，相同版本的MySQL，在物理机、虚拟机上运行完全没问题，但是在客户提供的容器平台上运行总会出现内存溢出的问题要定时重启避免问题，然而现场的项目经理、技术“大拿”仅仅从数据库本身出发去查看问题，其实容器跑MySQL虽然不建议在很多地方都有，也没见出什么问题，既然数据库查不出问题，完全没人去检查容器平台的问题，叫排查容器平台是不是有问题还是我和项目里一哥们聊天听到给的建议。虽然没有最终结论，但是听说客户使用的容器平台核心版本很老，查到了一些关联的问题文章了。当然在这个项目里面容器只是一方面，另一方面还有项目里的某些人，总在和客户在某些技术的细枝末节上争输赢，虽然客户里有人是把Paxos而不是半同步复制当做MGR同步方式的，但是依然没有争赢，因为其实客户不在乎技术，特别是技术的各种细节，客户要的是解决问题。最终在客户那名声没了，一些之前花大力气推进的东西也没了。
• 第二件事是另外一个地方，是使用的ClickHouse，运行总有问题，怀疑是操作系统的问题，现场项目经理解决不了，找了操作系统的二线支持，从操作系统日志分析还是觉得CH有点问题，希望继续详查，但是现场项目经理非常确定不可能是CH的问题，一杆子把建议打了回来，由于暂时没有可用的订阅，也没法更深层次的或者帮助，因此又根据实际情况给了另外三板斧：1.升级操作系统或重装，2.卸载桌面，3.检查IPv6配置。但是现场项目经理依然觉得不相干，继续和客户干耗着，甚至还觉得二线支持不给力在打马虎眼。

其实以上两件事情都是没有从客户角度出发，要么总在自己的圈圈里面绕不出去，要么就总要把问题排除到自己圈圈之外，两个极端说真的都是不负责任。这里我还想重申一点，作为一个DBA，不要仅仅只懂数据库，还要了解其他的，特别是操作系统。

3.RHEL/CentOS/OracleLinux 6.6

最近还协助处理了个问题，java程序跑着跑着就假死了，程序日志也没有任何报错，到点就直接卡主不输出了。经过排查是红帽系Linux操作系统6.6版本在使用2.6.32-504.el6.x86_64版本内核的时候会出现Java进程异常的bug（如果可以的话，查看该网页https://groups.google.com/forum/#!topic/mechanical-sympathy/QbmpZxp6C64）。这里也算是一个分享吧。

总结

最后我还是想说一点，我写的文章，尽可能的都是干货，和我工作态度一样，都是为了解决实际问题而写的。
没有老规矩，新春大吉。