Back Up a Sharded Cluster with Database Dumps
Changed in version 3.2: Starting in MongoDB 3.2, the following procedure can be used with the MMAPv1 and the WiredTiger storage engines. With previous versions of MongoDB, the procedure applied to MMAPv1 only.
You may alternatively use file system snapshots to capture the backup data. File system snapshots may be more efficient in some situations if your system configuration supports them.
To capture a point-in-time backup from a sharded cluster you must stop all writes to the cluster. On a running production system, you can only capture an approximation of point-in-time snapshot.
backup role provides the required privileges to perform backup on a sharded cluster that has access control enabled.
To create backups of a sharded cluster, you will stop the cluster balancer, take a backup of the config database, and then take backups of each shard in the cluster using
mongodump to capture the backup data. To capture a more exact moment-in-time snapshot of the system, you will need to stop all application writes before taking the filesystem snapshots; otherwise the snapshot will only approximate a moment in time.
For approximate point-in-time snapshots, you can minimize the impact on the cluster by taking the backup from a secondary member of each replica set shard.
For more information, see the Disable the Balancer procedure.
If you do not stop the balancer, the backup could have duplicate data or omit data as chunks migrate while recording backups.
Lock a secondary member of each replica set in the sharded cluster, and one secondary of the config server replica set (CSRS).
If locking a secondary of the CSRS, confirm that the member has replicated data up to some control point. To verify, first connect a
mongo shell to the CSRS primary and perform a write operation with
"majority" write concern on a control collection:
The operation should return either the newly inserted document or the updated document:
If the secondary member contains the latest control document, it is safe to lock the member. Otherwise, wait until the member contains the document or select a different secondary member that contains the latest control document.
To lock the secondary member, run
db.fsyncLock() on the member: