I have a Mongo replica set with a few secondaries. A box, which hosts a secondary instance, crashed and lost the database.

I started the secondary Mongo instance again and now it's stuck in STARTUP2 for more than 12 hours. Does it make sense ? The docs say Mongo should be in STARTUP2 for a short period of time before entering the RECOVERING state

What does STARTUP2 exactly mean ? Is it copying the database from the primary ? How can I verify it (assuming the Mongo is running in Linux) ?


The answer of eoinbrazil is partly incorrect. A new Node can be in STARTUP2 for a long time. The link the posted says:

Each member of a replica set enters the STARTUP2 state as soon as mongod finishes loading that member’s configuration, at which time it becomes an active member of the replica set. The member then decides whether or not to undertake an initial sync. If a member begins an initial sync, the member remains in STARTUP2 until all data is copied and all indexes are built. Afterwards, the member transitions to RECOVERING.

I'm administering a 700 GB collection and, when I add a new node the STARTUP2 state remains well over 24 hours. But you can still see if there is something happening, by watching if the database grows. You can see the size of the database on the new node with

show databases

or you can also observe the data directory, to see if it is still growing. (on linux with the commands ls, df, du, iotop, etc ....)


The STARTUP2 state means the node cannot vote. A member of a RS enters this state once the MongoD process completes loading it's configuration. In this state, the member has created threads to handle the internal replication operations but it has yet to change state to Recovering and onwards from that to Secondary (see the [state and their details in the docs]).

If your node has been in this state for more than a brief period then you are encountering some strange behaviour. This is pretty much impossible to analyse without the logs to determine why it is stuck. Running rs.status() and db.printSlaveReplicationInfo() will give you some details on the local picture on the node.

The normal approach to resolve this would be to shutdown the node, wipe its data files (those files in the dbpath), and restart it. This will restart the initial sync process and it should move to SECONDARY. If it gets stuck in STARTUP2 again, you'll need to look at the logs to gather more information as to why - there are a range of causes but one that can happen is a flaky network or some local resource contention.

One point to note is that whilst an initial sync is underway the node will remain in STARTUP2 so depending on the amount of data being synced this could be a considerable amount of time (potentially days).

  • Thanks. We removed the data and restarted the Mongo. It is still in STARTUP2. It looks like the Mongo is working. It is consuming CPU and as I see in db.stats the database is growing. The log says that some objects cloned. I am still looking for possible causes of this problem. – Michael Feb 12 '14 at 14:07
  • 1
    If this is still an issue, you may just want to do a copy from another node (see this procedure - docs.mongodb.org/manual/tutorial/resync-replica-set-member/…). If you can attach the logs highlights and details on which version you are using, it might point to a cause but equally this is unusual behaviour. Have you tried pinging between the nodes to see what the network latency is like ? – eoinbrazil Feb 12 '14 at 14:32
  • Mongo 2.4.6 ping between the hosts is Ok. – Michael Feb 12 '14 at 14:34
  • What are the ping times like as it may be intermittent networking issues ? In this case, it is much easier if you could add some of the log outputs as this is non-standard behaviour and the logs are the prime source of truth when trying to determine what exactly is occurring. – eoinbrazil Feb 12 '14 at 17:39
  • I am afraid I cannot show the logs here. However I noticed it tries to connect to another secondary member, which is down. Can it be the cause of the problem ? – Michael Feb 12 '14 at 19:27

One possible cause is that your secondary become "stale" as stated here .

When you are resyncing a member, make sure the RS is not under heavy load.


STARTUP2 state could be due to not enough disc space. Well, since there is no where to sync, it can only stay @ STARTUP2 state.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.