Please take a look at my mongodb map at http://postimg.org/image/krzvmep4d/

What synchronizes two delayed replicas, which is part of the replica set, included in sharded cluster? How can I use my delayed backup, if my replicaset "halfs" are not synchronized, because of I have shutdown one of my production servers first (using db.shutdownServer()), and shutdown another my server a few minutes later?

Or my mongo map just not perfect? In this case, please explain what I do wrong.

P.S. Re-added from here https://stackoverflow.com/questions/22715589/what-synchronizes-two-delayed-replicas-which-is-part-of-the-replica-set-includ

  • You have shut down a primary replica set member and want to use one of the delayed replicas to restore?
    – joao
    Commented Mar 31, 2014 at 11:10
  • I expected the original question to be migrated from StackOverflow, but it was closed as off-topic instead. Reposting my answer here, as it is still relevant - your idea of backing up sharded clusters using delayed secondaries is probably not going to work as you are anticipating. You will have a backup of data, but not a proper point-in-time backup of your sharded cluster.
    – Stennie
    Commented Mar 31, 2014 at 13:20

1 Answer 1


There is an obvious problem with your "delayed backup" model, in that your delayed secondaries will reflect the state of each replica set but not the full state of the sharded cluster at a given point in time.

A simple example:

  • there is a chunk migration from shard1 => shard2 in progress
  • documents will exist on both shard1 and shard2 while they are being copied over
  • your "delayed backup" does not have the matching config metadata to interpret the state of the cluster (and it will be changing over time, unless you disable the balancer)

Depending on the length of the replication delay (your diagram mentions "hour" and "week"), multiple changes to the cluster metadata may have happened and the config data will be very out of sync.

While you will have a delayed copy of the "data", if it isn't in sync with the sharded cluster metadata your path to a full restore will be reloading (and resharding) the data. You will also have to worry about resolving duplicate documents which can exist due to in-progress migrations.

For more information see the Backup and Restore Sharded Cluster tutorials in the MongoDB documentation. If you have a large amount of data, you will typically want to use the Filesystem snapshot approach to create an approximate point-in-time backup.

  • It is very sad for real. Hope in future MongoDB will be able to make delayed replicas of whole sharded cluster.
    – pys
    Commented Mar 31, 2014 at 13:59
  • 1
    you can get close with the MMS Backup system which allows you to do approximate point in time snapshots and restore to specific points in time for sharded clusters. For replica sets (not sharded) it supports arbitrary point in time recovery. More here: mms.mongodb.com/learn-more#backup-how-it-works
    – Adam C
    Commented Mar 31, 2014 at 14:54
  • Is it possible to configure the same, but inside my environment, whithout using of any "cloud services"? It just so happened that I have deal with enough big database (about 1 TB, and it is just start of my project). So it means that I have no time to get my backup from the cloud in case of it will needed. Is there just one way - to use lvm snapshots?
    – pys
    Commented Mar 31, 2014 at 15:28
  • @pys: you can take approximate point-in-time backups of your sharded cluster using LVM snapshots, but you need to do those from regular secondaries rather than delayed secondaries and include a snapshot of your config data. If you reconsider your "delayed backup" idea as "archived snapshots", you can still get the desired end result of having full hourly or weekly backups of your sharded cluster.
    – Stennie
    Commented Mar 31, 2014 at 22:10
  • Can I do the same thing, but without using LVM snapshots, simply copy the files of my secondaries, and include a "mongodump" of my config data?
    – pys
    Commented Apr 4, 2014 at 18:13

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.