Backing up and restoring MongoDB Shard cluster data

1. Backing up small shards of cluster data using Mongodump

If the dataset for a shard cluster is small, you can use Mongodump to connect to the MONGOs instance for data backup. By default, mongodump to non-primary nodes for data queries.

Such as:

Mongodump--host 192.168.100.200--port 28018-d taiwan_game1-o mongorestore--host 192.168.100.200--port 28018 taiwan_ Game1

It is important to note that if you do not specify a library name or a collection name when using Mongodump, Mongodump will get the collection data and the metadata of the Shard cluster directly from the config server

Mongodump--host 192.168.100.200--port 28018mongodump--host 192.168.100.200--port 28018-o.

You cannot use the--oplog parameter to get data from MONGOs, otherwise it will be an error.

Can ' t use ' local ' database through MONGOs

If you want to get backup data at a certain point in the cluster, you need to stop writing for the entire cluster.

The data that is backed up by Mongodump does not reflect the fast data and the data distribution of the collection in the cluster. You can restore the data to any MongoDB instance, or a single MongoDB instance, MongoDB Replica set or a new shard cluster.

2. Backing up shard cluster data from a file system snapshot

If you want to back up point-in-time real-time cluster data, you must stop all writes in the cluster, and in a production environment, you can only get near real-time data backups.

1) The balancer process is stopped and the uniform distribution of data between the Shard is stopped.

It is essential to stop the balancer process before making a backup, and if the balancer process is not stopped at the time of the backup, the data that is backed up may be duplicated or lost because there may be data block migrations when the backup occurs.

Mongos> use config;switched to DB configmongos> sh.stopbalancer (); Waiting for active hosts ... Waiting for the balancer lock ... Waiting again for active hosts after Balancer is off ...

2) lock one secondary member in each replica set in each shard. So the data that is backed up at this point can be closest to one real-time data. Use Db.fsynclock () to flush all pending write data to disk and then lock the MongoDB instance.

3) Back up one of the config server data. Backing up config server data is the backup of the entire cluster's metadata. Only one of the data needs to be backed up, because the data for each config server is the same.

You can use the following two ways to back up:

A. Create a file system snapshot. See Backup and Restore with Filesystem snapshots

B. Use Mongodump to back up the config server data.

Connect to one of the config servers

Mongodump--host 192.168.100.65--port 28018--oplog-o.

4) Back up the locked replica set member data . Backup and Restore with Filesystem snapshots.

5) Unlock the replica set member that is locked. Using Db.fsyncunlock ()

6) Restart the balancer process

Mongos> use config;switched to DB configmongos> sh.setbalancerstate (TRUE);

3.

This article is from the Linux SA John blog, so be sure to keep this source http://john88wang.blog.51cto.com/2165294/1621654

Backing up and restoring MongoDB Shard cluster data