mongodb 持久化(2)

在生产环境下，我们强烈推荐开启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脚本不会等待它关闭，很粗暴的硬关机。

原文地址：mongodb 持久化(2), 感谢原作者分享。