mongodb 持久化(2)

  • A+
所属分类:mongodb

在生产环境下,我们强烈推荐开启journal。但是,在某些情况下,可能就希望将其关闭掉。journal影响mongodb的写入速度,即使没有j选项。如果可以容忍数据丢失或更着重速度,那么就禁用journal。

禁用journal日志记录会有个问题,mongodb崩溃后数据的完整性没法保证了。没有journal情况下崩溃,数据可能被破坏了,必须进行修复或更换了。也可能该台的数据没法使用了,或使用过程中突然停止工作了,某些数据损坏丢失了。

如果希望崩溃后,可以继续正常工作,有以下方法:

1. 更换数据文件

这是最好的选择。删除所有的数据目录文件,从备份中恢复,从一个干净的成员中做个快照,或从复制集重新复制,得到一份新的数据。

如果有一个复制集并且是少量的数据,从新复制或许是最好的选择,停止这台,删除数据目录文件,并重新启动复制。

2. 修复数据文件

如果没有备份,没有副本,没有复制集,尽一切的办法补救数据,能恢复多少就是多少了,死马当活马医了。所以,一定要备份数据且保证备份数据可用,这是最后的救命稻草了。

这个情况下,需要使用repair命令了,该命令会删除任何损坏的数据。mongod附带两种修复工具:mongod本身内嵌的和mongodump内嵌的。

mongodump修复可能会发现更多的数据,但是需要很长的时间。此外,如果使用mongodump修复,仍然需要再次启动之前恢复数据的。因此,应该判定多少时间恢复数据是可以接受的。

使用mongod内置的修复,运行mongod加上--repair选项:

# mongod --dbpath /path/to/corrupt/data --repair

当运行在修复状态下,mongodb无法启动监听端口27017,但是可以查看日志,看看在做什么。

请注意:修复过程需要占用大量的磁盘空间,确保磁盘可用空间多于数据大小。如80G的数据需要80G的可用空间。如果当前磁盘空间不够,可通过--repairpath选项指定到挂载的新盘上。

# mongod --dbpath /path/to/corrupt/data  --repair --repairpath /media/external-hd/data/db

如果在修复过程中被killed或磁盘空间不足而退出,不会有任何影响的。因为,修复的所有输出是写入到新的文件中,不会更改原始文件直到最后一刻。

mongodump使用repair选项:

# mongodump --repair

3. mongod.lock文件

mongodb数据目录下有一个特殊的文件,就是mongod.lock文件。当运行在禁用journal情况下,它是很重要的。

当正常关闭mongod时,会清除mongod.lock文件,下次启动时知道上次是完全关闭的。相反,如果lock文件没有被清除,mongod没有正常的关闭。

如果mongod检测到没有正常的关闭,不会让你再次启动,需要你复制一份数据。然而,有些人已经意识到,可以通过删除这个lock文件来绕过这个检查。但是,请不要怎么干。在启动时删除lock文件意味着你不知道或不关心你的数据是否已经损坏。除非是这种情况下,请尊重lock文件。如果阻止你启动mongod,修复你的数据,而不是删除lock文件。

4. 异常关机

不要删除锁定文件的一个重要原因是,你甚至可能不会注意到硬盘崩溃。假设重启服务器,初始化脚本在服务器关闭前停止mongod,然而,初始化会尝试优雅关闭进程,如果关不掉就会硬杀掉它。在繁忙的系统,mongodb可能需要更长的时间来关闭,init脚本不会等待它关闭,很粗暴的硬关机。

weinxin
微信公众号
扫一扫关注运维生存时间公众号,获取最新技术文章~

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: