编译rocksdb源码导致的部署失败

这几天经历了一次心酸的历程，使用了rocksdb第三方库，编译器是7.2，rocksdb是20190701从github上取下来的，由于rocksdb自己的CMakeList.txt中使用了-march=native编译参数，强制使用了编译代码服务器的cpu指令集，由于是一个集群，集群中的服务器cpu型号信息不一定都一致，导致集群中部分服务器起不来。引起了大领导的关注，自己一下子提起了精神

事情的经过是这样的：

我们发布了一款数据库产品，部署在一个大的集群中，集群中大概有200台服务器，但是部分服务器节点的进程启动不起来。在一台服务器A上编译打包之后部署到其他的服务器，当时其他的服务器是一个大集群里面有几十台服务器，就用B来代表其中的一台服务器吧，但是B启动时直接失败，可以看到的有用信息比较少。

(1)、后来改成了可以调试的版本，优先分析coredump，可以看到，有用的gdb信息比较少，直接在进程启动时就崩溃了。

(2)、尝试在main函数入口处加打印来获取崩溃的模块的信息，但是在测试过程中main函数中的打印一个也没有出现，log文件也没有生成，我个人直接崩溃

(3)、跟其他组的资深同事聊了半天，也没有得到实质的帮助，此时2天已经过去了，MP催了几次了

(4)、直接领导也给了一些帮助，让加一些编译参数，经过漫长的尝试测试结果也是失败了

经过直接领导的指导，应该调整下测试的方式，但是领导也不清楚具体原因，我也懵了，让自己研究，作为入职公司16个月的资深工程师来说觉得应该好好深入的研究下rocksdb的源码

(1)、各大网站一顿查找，国内网站没有给什么帮助，stackflow给了一部分帮助

(2)、开始研究rocksdb源码中编译部分，经过一整夜的研究查找资料，最后得出的是rocksdb内部开启的对cpu指令集的调整参数-march=native，修改rocksdb的编译参数，编译下代码这个过程比较长，这时已经早上6：:55，就让机器自己编译吧，洗了把脸去外面找点吃的，回来经过2小时的验证，就是这个问题。由于需要在各种版本上验证，因此需要考虑各种情况。

(3)、经过测试ok了

 

总结：

      本人以前是搞通信的，硕士毕业，最早是做C开发的，现在从事分布式数据库方面的工作，这次居然使用到了了os + 计算机组成原理+CPU架构等方面的知识，由于以前基础知识扎实，这次得到了应用，帮助本人发散了思维，有利于问题的解决