- Administration >
- Administration Tutorials >
- Backup and Recovery >
- Backup and Restore Sharded Clusters >
- Backup a Sharded Cluster with Database Dumps
Backup a Sharded Cluster with Database Dumps¶
On this page
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.
Overview¶
This document describes a procedure for taking a backup of all components of a sharded cluster. This procedure uses mongodump to create dumps of the mongod instance. An alternate procedure uses file system snapshots to capture the backup data, and may be more efficient in some situations if your system configuration allows file system backups.
For more information on backups in MongoDB and backups of sharded clusters in particular, see MongoDB Backup Methods and Backup and Restore Sharded Clusters.
Prerequisites¶
Important
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.
Access Control¶
The backup role provides the required privileges to perform backup on a sharded cluster that has access control enabled.
Changed in version 3.2.1: The backup role provides additional privileges to back up the system.profile collections that exist when running with database profiling. Previously, users required an additional read access on this collection.
Consideration¶
To create these backups of a sharded cluster, you will stop the cluster balancer and 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.
Procedure¶
Disable the balancer process.¶
To disable the balancer, connect the mongo shell to a mongos instance and run sh.stopBalancer() in the config database.
use config
sh.stopBalancer()
For more information, see the Disable the Balancer procedure.
Warning
If you do not stop the balancer, the backup could have duplicate data or omit data as chunks migrate while recording backups.
Lock one secondary member of each replica set.¶
Lock a secondary member of each replica set in the sharded cluster, and, if your sharded cluster uses a replica set for the config servers, one secondary of the config server replica set (CSRS).
Ensure that the oplog has sufficient capacity to allow these secondaries to catch up to the state of the primaries after finishing the backup procedure. See Oplog Size for more information.
Lock shard replica set secondary.¶
For each shard replica set in the sharded cluster, connect a mongo shell to the secondary member’s mongod instance and run db.fsyncLock().
db.fsyncLock()
When calling db.fsyncLock(), ensure that the connection is kept open to allow a subsequent call to db.fsyncUnlock().
Lock config server replica set secondary.¶
If locking a secondary of the CSRS, confirm that the member recognizes that the balancer is disabled and the last migration has finished. Connect a mongo shell to the secondary member’s mongod instance. To confirm that the member recognizes that the balancer is disabled:
use config
rs.slaveOk()
db.settings.find({ "_id" : "balancer", "stopped" : true })
If the member recognizes that the balancer is disabled, the query should return a document. Otherwise, wait until the query returns a document.
To confirm that the CSRS secondary member has replicated past the last completed migration, check the changelog collection in the config database. The last logged moveChunk operation should be a commit.
use config;
db.changelog.find({what:/^moveChunk/}).sort({time:-1}).next().what"
The query should return "moveChunk.commit". If not, wait until the chunk migration completes.
If the secondary member recognizes that the balancer is disabled and the last migration is complete, lock the member.
db.fsyncLock()
When calling db.fsyncLock(), ensure that the connection is kept open to allow a subsequent call to db.fsyncUnlock().
Backup one config server.¶
Run mongodump against a config server mongod instance to back up the cluster’s metadata. You only need to back up one config server. If you are using CSRS config servers and locked a config server secondary in the previous step, perform this step against the locked config server.
Use mongodump with the --oplog option to backup one of the config servers.
mongodump --oplog
If your deployment uses CSRS config servers, unlock the config server node before proceeding to the next step. To unlock the CSRS member, use db.fsyncUnlock() method in the mongo shell used to lock the instance.
db.fsyncUnlock()
Unlock replica set members for each shard.¶
To unlock the replica set members, use db.fsyncUnlock() method in the mongo shell. For each locked member, use the same mongo shell used to lock the instance.
db.fsyncUnlock()
Allow these members to catch up with the state of the primary.
Re-enable the balancer process.¶
To re-enable to balancer, connect the mongo shell to a mongos instance and run sh.setBalancerState().
use config
sh.setBalancerState(true)
Additional Resources¶
See also MongoDB Cloud Manager for seamless automation, backup, and monitoring.
Thank you for your feedback!
We're sorry! You can Report a Problem to help us improve this page.