当前位置:Gxlcms > mysql > mongodb持久化(2)

mongodb持久化(2)

时间:2021-07-01 10:21:17 帮助过:40人阅读

在生产环境下,我们强烈推荐开启journal。但是,在某些情况下,可能就希望将其关闭掉。journal影响mongodb的写入速度,即使没有j选项。如果可以容忍数据丢失或更着重速度,那么就禁用journal。禁用journal日志记录会有个问题,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脚本不会等待它关闭,很粗暴的硬关机。

人气教程排行