翻译或纠错本页面

Back Up a Sharded Cluster with File System Snapshots

On this page

在 3.2 版更改: Starting in MongoDB 3.2, the procedure can be used with the MMAPv1 and the WiredTiger storage engines. With previous versions of MongoDB, the procedure applied to MMAPv1 only.

概述

This document describes a procedure for taking a backup of all components of a sharded cluster. This procedure uses file system snapshots to capture a copy of the mongod instance. An alternate procedure uses mongodump to create binary database dumps when file-system snapshots are not available. See Back Up a Sharded Cluster with Database Dumps for the alternate procedure.

重要

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.

要对集群进行精确的某个时间点的备份, 必须 停止集群中所有的写入.在一个运行的生产环境系统中,一般只能备份 近似 在某个时间点的数据.

Considerations

Balancer

It is essential that you stop the balancer before capturing a backup.

备份一个 配置服务器 以备份集群的元信息.由于所有配置服务器存储的数据完全一样,所以只需要备份一台的数据即可.

Precision

In this procedure, you will stop the cluster balancer and take a backup up of the config database, and then take backups of each shard in the cluster using a file-system snapshot tool. If you need an exact moment-in-time snapshot of the system, you will need to stop all application writes before taking the file system 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.

Consistency

If the journal and data files are on the same logical volume, you can use a single point-in-time snapshot to capture a consistent copy of the data files.

If the journal and data files are on different file systems, you must use db.fsyncLock() and db.fsyncUnlock() to ensure that the data files do not change, providing consistency for the purposes of creating backups.

Snapshots with Amazon EBS in a RAID 10 Configuration

If your deployment depends on Amazon’s Elastic Block Storage (EBS) with RAID configured within your instance, it is impossible to get a consistent state across all disks using the platform’s snapshot tool. As an alternative, you can do one of the following:

Procedure

1

Disable the balancer.

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.

2

If necessary, lock one secondary member of each replica set.

If your secondary does not have journaling enabled or its journal and data files are on different volumes, you must lock the secondary’s mongod instance before capturing a backup.

If your secondary has journaling enabled and its journal and data files are on the same volume, you may skip this step.

重要

If your deployment requires this step, you must perform it on one secondary of each shard and 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大小 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 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:

use config
db.BackupControl.findAndModify(
   {
     query: { _id: 'BackupControlDocument' },
     update: { $inc: { counter : 1 } },
     new: true,
     upsert: true,
     writeConcern: { w: 'majority', wtimeout: 15000 } }
   }
);

The operation should return the modified (or inserted) control document:

{ "_id" : "BackupControlDocument", "counter" : 1 }

Query the CSRS secondary member for the returned control document. Connect a mongo shell to the CSRS secondary to lock and use db.collection.find() to query for the control document:

rs.slaveOk();
use config;

db.BackupControl.find(
   { "_id" : "BackupControlDocument", "counter" : 1 }
).readConcern('majority');

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:

db.fsyncLock()

When calling db.fsyncLock(), ensure that the connection is kept open to allow a subsequent call to db.fsyncUnlock().

3

Back up one of the config servers.

注解

Backing up a config server backs up the sharded cluster’s metadata. You only need to back up one config server, as they all hold the same data. Perform this step against the locked CSRS secondary member.

To create a file-system snapshot of the config server, follow the procedure in 创建一个快照.

4

Back up a replica set member for each shard.

If you locked a member of the replica set shards, perform this step against the locked secondary.

You may back up the shards in parallel. For each shard, create a snapshot, using the procedure in Back Up and Restore with Filesystem Snapshots.

5

Unlock all locked replica set members.

If you locked any mongod instances to capture the backup, unlock them.

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()
6

Enable the balancer.

To re-enable to balancer, connect the mongo shell to a mongos instance and run sh.setBalancerState().

sh.setBalancerState(true)

Additional Resources

See also MongoDB Cloud Manager for seamless automation, backup, and monitoring.

© MongoDB, Inc 2008-2017. MongoDB, Mongo, and the leaf logo are registered trademarks of MongoDB, Inc.

Report a Problem