2

I am reading the document upgrade config servers to use WiredTiger. In the section of "change config server to use WiredTiger", the second step is "stop the last config server listed in the mongos' configDB setting". But the 5th step is to restart the second config server with WiredTiger. I am confused by the sequence of stopping and restarting. Is there problem on this document?

Another question, why the data in config servers should be exported and uploaded manually? Why the data in replicate set should not be exported and uploaded manually? Instead, the data in replicate set can be imported by "Resync a Member of a Replica Set" please see official doc

Improve this question
3
  • Can you show us the document you're using?
    – LowlyDBA - John M
    Mar 13, 2015 at 13:28
  • Sorry, re-edited my question again.
    – BAE
    Mar 13, 2015 at 13:59
  • 1
    Config servers are not a replica set yet. They are standalone mongod. I am curious why you want to change a config server to WT?
    – Antonios
    Mar 13, 2015 at 22:49

1 Answer 1

Reset to default
4

The current wording in the documented steps may be somewhat confusing given the relative references to first/last/second config servers.

I've added some context for the documented steps below, but you should consider the manual the definitive source. It's also worth noting that you do not have to upgrade the config servers to use WiredTiger (even if your shards are using WiredTiger). Config servers typically have a small data set and are not under high write load.

Annotated version of the steps from the MongoDB 3.0 Upgrade Guide

  1. Disable the balancer.

    Disabling the balancer ensures any active migrations have completed.

  2. Stop the last config server listed in your mongos' configDB setting (will call that config3 for the purpose of these steps):

    At this stage you should have:

    • config1 (running mmap)
    • config2 (running mmap)
    • config3 (stopped)

    Stopping one of the config servers ensures there are no changes to the metadata in the cluster (chunk splits or migrations cannot be committed without all three config servers available).

  3. Use mongodump to export the config database from config2

    After running the mongodump you should have a dump directory with bson files.

  4. Create a new data directory on config2.

    The storage format for WiredTiger data is different from the existing mmap data, and cannot use the same dbpath as mmap.

  5. Restart the config2 server with the WiredTiger and appropriate storage options:

    mongod --storageEngine wiredTiger --dbpath <newWiredTigerDBPath> ...

    At this stage you should have:

    • config1 (running mmap)
    • config2 (running WiredTiger with no data)
    • config3 (stopped)

    Note that config2 doesn't have any data yet, because it has just been started up with the new WiredTiger dbpath.

  6. Use mongorestore to load the config database backup you created in step 3.

    At this stage you should have:

    • config1 (running mmap)
    • config2 (running WiredTiger)
    • config3 (stopped)

  7. Shut down config2:

    At this stage you should have:

    • config1 (running mmap)
    • config2 (stopped)
    • config3 (stopped)

    config2 is stopped at this point to ensure no metadata changes can happen when we start config3 up in the next step.

  8. Restart config3.

    At this stage you should have:

    • config1 (running mmap)
    • config2 (stopped)
    • config3 (running mmap)

(steps 9-15) These steps are just repeating the same mongodump and mongorestore for each config server. There's a bit of shuffling to ensure you always have at least one config server available, and do not have all three up while you are still migrating data.

  1. Upload the data into config1

    At this stage you should have:

    • config1 (running WiredTiger)
    • config2 (stopped)
    • config3 (running WiredTiger)

  2. Start config2

    With all three config servers are available & upgraded, changes to the sharded cluster metadata can now resume.

  3. Re-enable the balancer so normal balancing activity & chunk migration can resume.

Improve this answer
6
  • Thanks. "you do not have to upgrade the config servers to use WiredTiger (even if your shards are using WiredTiger)." I am afraid that in the far future (not mongodb 3.0, maybe mongodb 4.0 ), I have to upgrade the config server to use WiredTiger.... If so, I would like to do it now....
    – BAE
    Mar 16, 2015 at 13:25
  • It seems that the three config servers have the same copy of the meta data. Why should I export and import the meta data manually? The data should be re-sync-ed to the config server without data?
    – BAE
    Mar 16, 2015 at 13:36
  • Config servers do not run as replica sets, so there is no automatic process to sync them. To convert data between storage engine formats you need to mongodump the data from an mmap instance and then mongorestore into a WiredTiger instance. Given the config servers have to be consistent, you could take a different approach and copy the first mongodump to each config server .. but that involves network transfer for data that should already be local to each config server (but not in the desired storage engine format).
    – Stennie
    Mar 16, 2015 at 13:44
  • Hi, When I went to step 6. I tried to use "sudo mongorestore --port 27019 --username allDBsadmin --password esentire --authenticationDatabase admin /var/data/config1/mongodump-15-03-16/" to restore the data. But the error is "2015-03-16T16:36:01.205-0400 Failed: error connecting to db server: server returned error on SASL authentication step: Authentication failed." I have no idea. @Stennie
    – BAE
    Mar 16, 2015 at 21:00
  • For the auth failed error I would check your credentials by trying to login using the mongo shell. Have you upgraded your authSchema? Can you also make sure you are using a 3.0 mongorestore (mongorestore --version)? FYI, there should be no need to run sudo for mongorestore or mongodump (better to fix the file/directory permissions, if incorrect).
    – Stennie
    Mar 16, 2015 at 22:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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