Database Reference
In-Depth Information
■
You must
not
use the
SIG_KILL(-9)
signal to terminate a server, because this could result in a corrupted
database, and you will probably have to repair the server.
Warning
It might be that you have a particularly active server with a lot of write activity, and you have reconfigured the
server so it has a large sync delay. If that's the case, then the server may not respond immediately to a termination
request, because it is writing out all the in-memory changes to the disk. A little patience goes a long way here.
Using MongoDB Logfiles
By default, MongoDB writes its entire log output to
stdout
; however, you can use the
logpath
option described
previously to redirect the log output to a file instead.
You can use the contents of the logfile to spot problems such as excessive connections from individual machines
and other error messages that may indicate problems with your application logic or data.
Validating and Repairing Your Data
It is possible that your data will be left in a damaged or incomplete state if your server unexpectedly reboots or your
MongoDB server crashes for any reason.
Here are some indications that your data has been compromised:
•
Your database server refuses to start, stating that the datafiles are corrupted.
asserts
in your server log files or a high assert count when using the
db.
serverStatus()
command.
•
You start seeing
•
You get strange or unexpected results from queries.
•
The record counts on collections don't match up with your expectations.
Any of these signs may indicate problems with your application or, more worryingly, corruption or inconsistency
in your data.
Fortunately, MongoDB ships with tools to assist you in repairing or recovering your database server.
Nevertheless, you might still suffer the loss of some data, so please remember the golden rule of making sure you have
either a good backup of your data or a replication slave.
Repairing a Server
Before you initiate the server repair process, you must be aware that running the
repair
command is a costly
operation that can take significant time, and it requires up to twice the space taken by your MongoDB data files as all
your data is cloned out to new files and fully re-created, this is effectively a rebuild of all your datafiles. This is one of
the best arguments for using replica sets: you don't have to fully stop your replica set from servicing your clients if you
have to take one machine offline to repair it.
To initiate the repair process, just use the manual server startup process (as described previously in this chapter).
However, this time you need to add the
--repair
option to the end of the command, as in the following example:
$ mongod --dbpath /data/db --repair
Wed Sep 18 21:21:21.364 [initandlisten] MongoDB starting : pid=5973 port=27017 dbpath=/data/db
64-bit host=Pixl.local
Wed Sep 18 21:21:21.364 [initandlisten]
