记一次TokuMX数据库集群恢复

中午在昏睡中接到电话，服务器扩容后数据库启动不了了，于是不假思索的想到了TokuMX需要关闭对透明大页的使用才可以正常启动，而这点恰巧大家都不是很清楚，在这里写下关闭的shell: echo never > /sys/kernel/mm/transparent_hugepage/enabled 一般情况下将其写入开机启动脚本，否则数据库不能正常启动。

然而当我远程查看了服务器后彻底懵逼了，数据库不见了，印象中服务安装在dev挂载点下，于是我翻遍了dev,全盘grep,find和tokumx相关的文件，后来只查到一些无关痛痒的东西，慌了。

谁会大意把数据库删了，或者说是我印象中记错目录了，慌乱中查找了home,opt,etc….等等等等，把整个服务器翻了个遍都没有找到踪迹，一个念头一闪而过，不是每台服务器都做了开机启动吗，里边儿不就有数据库路径。心知这个小问题要被解决掉了，打开rc.local一看：这是个大问题（其实我的内心是崩溃的，千万头羊驼在愉快地奔跑）..我不信，我不接受这个事实，于是又到dev下翻了个遍，各种grep,连find -name命令我都不相信。事实告诉我不信也没用，然而没有就是没有。

我开始怀疑是不是有人删掉了数据库，此时我还是很淡定的，因为我们还有备份机,最差也能找到数据库的正确安装路径吧。每当我沾沾自喜拥有聪明才智时，现实总会将我乱棒打醒。备份机离线了….电话得知为了扩容备份机也关了，于是告知开机取备份。然后，备份机也完蛋了，同样的目录，什么也没有…安排后事吧，死了就得葬，管杀就得管埋，领导负责给客户做好善后工作，我开始埋。到此时我仍然认为是有人无意中觉得这个目录下多了个奇怪的文件夹看着不顺眼删了，而这个目录正好是我们的数据库目录。

于是我开始了漫无目的的查找系统日志，各种搜索文件夹删除日志，linux系统日志，查看了/var/log下的各种日志并没有得到任何有用的内容。

我甚至想到了数据恢复，网上看了各种linux系统下的数据恢复方式和工具，尝试了各种搜索，但是想到了之前一些事情的粗心大意考虑欠稳妥，于是把数据恢复方案作为最后的手段，告一段落。。。

理理思路，因为主服务的数据库装载dev挂载点下，备份机为了保持一致也方便记忆，也没多想都装同一挂载点了，于是改变了搜索关键词:dev子目录丢失，我想我得到了答案

仍然不死心，直到我看到了这个答案后的尝试。mount /dev/mongodb ，各种mount,花式mount，提示在/etc/estab/ 下并没有此挂载点，事实上是没有此挂载点的记录，多次尝试，没用。

为了证明上面说法的真实性，亲手做了实验，在dev下建立了test目录，里面touch了123.txt，reboot，查看，没了。

意思很明确，数据库找不回来了，所有的东西都得从头开始。功夫不负有心人，领导的提示，我想到了补救措施，数据库文件和数据库应该不在同一目录下，欣喜的发现了库里的所有文件一一罗列在此了（这个目录的名称toku拼写错了）

接下来怎么办，想到初来公司时就是因为误改了数据库路径导致了数据库加载不上，然而就算是有这些文件没有原来的集群配置又有什么用。但是想想这么大的公司做出来的软件不应该会这么傻，而当初是因为对linux操作系统和mongodb的不了解和畏惧没有深究导致的，这次不论如何我要把这些数据恢复回去。

此时因为以前用mongodb时试过直接更改配置文件中的dbpath是不管用的，甚至不确定更改了dbpath配置数据库文件会不会被重建，本着谨慎的态度我重装了tokumx，这次将数据库安装指定在home目录下，数据库文件目录也指定在新的tokumx安装目录下:/home/tokumx/data/(感慨一下一键安装真好用，省了不少时间)。

到这里两台服务器的tokumx重装完毕，集群貌似有点小问题，手动处理了一下将集群恢复。

这次和之前不一样的地方在于，数据库是以集群的方式运转的，假设只恢复了数据那么集群是否还能正常运转？不管怎么样先弄好一台服务器用standalone模式也行，于是我搜索各种mongodb数据导入方式，得知用mongoimport,用mongoimport –h查看了帮助，告知用--dbpath指定导入文件夹。于是./mongoimport --dbpath /home/cdasTuko/data/ 结果呢，mongoimport只支持json,csv等等类型的导入。于是接着搜索如何直接加载数据库文件，像sqlserver的分离和加载那样，得不到任何有用的答案。Mongorestore也不适用。

后来想了想TokuMX毕竟不是Mongodb，它有更多人性化的一面，何不尝试一下直接修改dbpath，万一能加载上呢，就算没了还有备份机呢。给自己壮了壮胆，确认了备份机上的数据库文件存在后开始动手。

理了下思路，大概是这样的：为了不影响集群，先修改standalone模式的配置文件，以非集群的方式启动，如果能加载上就把集群的配置文件做同样修改，如果集群启动不了就删除一台机器的数据库让集群自动同步过去。

停止数据库服务

./mongod –shutdown –f tokuShard.cfg

修改standalone的配置文件

vi tokumx.cfg

修改:dbpath=/home/cdasTuko/data/

重新启动，用standalone的配置

./mongod –f tokumx.cfg

启动完成，赶紧查了查数据，一个不少都在。成功！激动万分！

接下来的工作就简单了，数据在，数据库在，集群搭起来不就好了，于是按照上述方法修改了tokuShard.cfg 将里面的dbpath更变成旧的数据库路径，备份机的也一样。修改完成，分别以集群配置文件启动两台服务器的TokuMX，万分幸运，成功了。此时虽已凌晨却因高兴完全没睡意，兴冲冲的连接到集群看了看状态

STARTUP2是个什么鬼？能吃吗？？？搜索了关于Mongo集群的stateStr的各种含义，等待，1分钟，2分钟，5分钟，10分钟过去了，仍然是STARTUP2，心想不好，有事情要发生。赶紧打开RoboMongo查了查库，果不其然，两台服务器都不能查询，处于假死状态，任何操作都不管用。再一次心灰意冷。

仔细看了看上面显示的时间，又懵了，完全对不上号，于是用date命令查看了两台服务器的时间，相差1分钟左右，会不会是因为这里导致同步不了，用date –s 命令手动修改了两台服务器时间，让其保持相差在10秒之内(时间同步服务可能没有起作用)。

date –s 02:44

然后shutdown集群，重新启动。情况没有转变，再看了看rs.status(),看到状态:

replSet initial sync pending

集群初始化同步挂起…于是按照此关键词搜索了一堆文章，有人提出使用rs.SlaveOK(),分别在两台服务器上执行，无果。想到了集群的特殊性，是否不能直接去修改数据库路径，否则影响到集群正常运转，是否有其它配置记录在admin或者local库里，于是我翻遍了两台服务器的local和admin库的表，得到唯一感觉不大对的是集群操作日志表中的dbpath字段还记录着安装时的/home/tokumx/data/ ，虽然是日志感觉没什么用吧，反正已经到这一步了，就把看到的dbpath都替换成旧的数据库文件路径(/home/cdasTuko/data/)。

想了想觉得正常的集群配置和现在的是不是有什么差别，于是打开了本地的虚拟机，查看了虚拟机上的local库，发现并无差异。

可能是兴奋冲昏了头脑，许久才想起来还有日志，为了清晰明了，我清空了日志文件夹，重新启动集群，5分钟后赶紧打开了log文件cat /home/tokumx/log/tokumx.log

我看到了几行非常有意思的话：