发布于 2015-09-14 14:45:01 | 160 次阅读 | 评论: 0 | 来源: 网络整理
If your sharded cluster comprises a small collection of data, you can connect to a mongos and issue the mongodump command. You can use this approach if the following is true:
It’s possible to store the entire backup on one system or on a single storage device. Consider both backups of entire instances and incremental dumps of data.
The state of the database at the beginning of the operation is not significantly different than the state of the database at the end of the backup.
Your application must be able to operate given a copy of the data that reflects many moments in time. If the data collected by the backup operation is not sufficient to restore from, using mongodump for your back ups is not viable.
The backup can run and complete without affecting the performance of the cluster.
If these conditions are not all true, then this backup method will not support the needs of your deployment. Read Sharded Cluster Backup Considerations for a high-level overview of important considerations as well as a list of alternate backup tutorials.
注解
If you use mongodump without specifying the a database or collection, the output will contain both the collection data and the sharding config metadata from the config servers.
You cannot use the --oplog option for mongodump when dumping from a mongos. This option is only available when running directly against a replica set member.
To perform a backup of a shard cluster by connecting mongodump by connecting directly, use the following operation a your system’s prompt:
mongodump --journal --host mongos3.example.net --port 27017
This will create a database dump of the shard cluster accessible via the mongos listening on port 27017 of the mongos3.example.net mongos instance.
The dump produced by this operation will effectively “unshard” your data: you must re-shard and re-balance the data when you restore.