NoSQL Benchmarks NoSQL use cases NoSQL Videos NoSQL Hybrid Solutions NoSQL Presentations Big Data Hadoop MapReduce Pig Hive Flume Oozie Sqoop HDFS ZooKeeper Cascading Cascalog BigTable Cassandra HBase Hypertable Couchbase CouchDB MongoDB OrientDB RavenDB Jackrabbit Terrastore Amazon DynamoDB Redis Riak Project Voldemort Tokyo Cabinet Kyoto Cabinet memcached Amazon SimpleDB Datomic MemcacheDB M/DB GT.M Amazon Dynamo Dynomite Mnesia Yahoo! PNUTS/Sherpa Neo4j InfoGrid Sones GraphDB InfiniteGraph AllegroGraph MarkLogic Clustrix CouchDB Case Studies MongoDB Case Studies NoSQL at Adobe NoSQL at Facebook NoSQL at Twitter



MongoDB: Handling Master Crashes in Master/Slave Setups

Very informative discussion about handling master server crashed in MongoDB master/slave setups:

Alvin Richards: in the case of an unclean shutdown, you must always

  • remove the lock file
  • start mongod with --repair
  • after the repair is complete, then you can restart mongod

The time a repair takes is a function of the amount of data and indexes and the I/O capability of your system. Right now you need access to double the amount of storage as the repair takes place. We will be optimizing this going forward. You can use the --repairpath to indicate an alternate volume if you need to provision space just for the repair operation.

Original title and link: MongoDB: Handling Master Crashes in Master/Slave Setups (NoSQL databases © myNoSQL)