MongoDB Guide (translation) (7)-developer zone-database commands (2)

Compact command

V1.9 +

The compression command compresses and removes fragments from a set. Indexes are also rebuilt and compressed. This releases space for other collections in the database. It is similar in concept to repairDatabase, but it only acts on a set rather than the entire database.

Run (mongo shell example above ):

> db.runCommand( { compact : 'mycollectionname' } )
OR
> db.mycollection.runCommand( "compact" )

This command will not be returned until all compression is complete. You can view the intermediate progress by viewing the mongod record file or running db. currentOp () in another shell instance.

Because it blocks all activities, this command will not run on the master node of the replication group by default. Otherwise, an error is returned. To forcibly run the command on the master node of the replication group, use the compression command that uses force: true as the parameter.

 

Run a compression

Unlike repairDatabase, the compression command does not require twice the hard disk space. It only requires a small amount of extra space during work. In addition, compression is faster.

Although it is faster than repairDatabase, this command will block all other operations during running and is slow. You can run it during scheduled maintenance.

If you run this command on the secondary node of the replication group, the secondary node will automatically downgrade itself to the "recovery" status until the compression is completed.

 

Cancel one compression

At the beginning of compression, the index of the set will be deleted. After compression, the index is rebuilt. Therefore, if you cancel the compression operation and use killOp or the server fails, the index of your set may be lost. If you use the parameter -- journal to run, there should be no data loss during the compression process, although the index may not exist at startup. (Even so, always back up like this before system maintenance) after index reconstruction, they will be in the index format of version 2.0.

If a crash occurs during the command execution, your data will be safe as long as the log function is enabled. However, a non-recoverable Disk Area remains. The only way to remove this disk is to repair the entire database. However, unless extra space is used, the isolated disk area will not show any problems.

In addition, if the compression operation is interrupted, a large portion of the free space in this set may become unavailable. In this case, we recommend that you perform another compression to complete the compression and restore the free space.

Compression Effect

You may run the collstats command (db. collectionname. Stats () in the shell) before and after compression to check how the storage space of the set has changed.

This command fully compresses the documents without the padding factor in the set. If you often perform the update operation that will increase the document size, this will reduce the update performance because the document needs to be moved frequently.

Compression may increase the total size of your data files to 2 GB. Even in this case, the total storage space used by the collection will decrease.

Details

• Compression may be performed on secondary nodes and slave nodes of the replication group. The compression command is not copied, so each host needs to be compressed separately.
• Currently, compression is the command that is released to mongod. In a partition environment, each partition should be compressed separately as a maintenance operation. (May be changed in future versions, along with other enhancements)
• A set of fixed sizes cannot be compressed. (However, documents in a fixed-size set are not managed by fragments .)

Copy Group

• Compress each member individually.
• The ideal compression is to run on a secondary node (see the above comments about force: true ).
• If the compression is run on the secondary node, the secondary node automatically enters the "recovering" State (to prevent read Operations routed during the compression process ). Once the compression is completed, it will automatically return to the secondary state.

Copy DATABASE Command

MongoDB contains commands to copy a database from one server to another.

These options are faster than the optional methods to execute mongodump and mongorestore, because they skip the step of creating a temporary bson description on the disk.

Copydb command

Copy the entire database named above one server to another server and use another name. Copy a database to another database with the same name on the same server can be omitted <from_hostname>. The Copy command must be sent and executed on the target server.

> // shell helper syntax:
> db.copyDatabase(<from_dbname>, <to_dbname>, <from_hostname>);
> // if you must authenticate with the source database
> db.copyDatabase(<from_dbname>, <to_dbname>, <from_hostname>, <username>, <password>);
> // pure command syntax (runnable from any driver):
> db.runCommand(
... {copydb: 1, fromhost: ... todb: <db>[, slaveOk: <bool>, username: <username>,
... nonce: <nonce>, key: <key>]}";
> // command syntax for authenticating with the source:
> n = db.runCommand( { copydbgetnonce : 1, fromhost: ... } );
db.runCommand( { copydb : 1, fromhost: ..., fromdb: ..., todb: ..., username: ..., nonce: n.nonce,
key: 
CloneDatabase
Similar to copydb, but simplified syntax is used. This method only copies a database to this server and uses the original name.
> db.cloneDatabase(<from_hostname>);
Note:

 

 
  
CopyDatabase can run on slave nodes or secondary nodes (in other words, the source server can be a slave node or secondary node ).
 
  
CopyDatabase has no snapshots in any sense: if the source database is changing during the copy process, the target database will receive documents at different time points.
 
  
This command must be run on the target server.
 
  
This command does not lock the source and target servers during execution. Each segment periodically allows other read/write operations to pass.

 
Fsync command
The fsync command allows us to refresh all pending write operations to data files. More importantly, it also provides lock options to make backup easier.
The fsync Command forces the database to refresh all data files:
> use admin
> db.runCommand({fsync:1});
By default, this command is returned after synchronization is complete. You need to return immediately. Please use:
> db.runCommand({fsync:1,async:true});
To regularly synchronize data, run the -- syncdelay command in the command line option (view mongod -- help output ). By default, a force-complete refresh is performed every 60 s.
Lock, snapshot, and unlock
The synchronization command supports the lock option to securely take snapshots of database data files. When it is locked, all write operations will be blocked, although read operations are still allowed. After the snapshot is complete, use the UNLOCK command to unlock the database and allow locking again. For example:
> use admin
switched to db admin
> db.runCommand({fsync:1,lock:1})
{
"info" : "now locked against writes",
"ok" : 1
}
> db.currentOp()
{
"inprog" : [
],
"fsyncLock" : 1
}
>// do some work here: for example, snapshot datafiles...
>// runProgram("/path/to/my-filesystem-snapshotting-script.sh")
> db.$cmd.sys.unlock.findOne();
{ "ok" : 1, "info" : "unlock requested" }
> // unlock is now requested. it may take a moment to take effect.
> db.currentOp()
{ "inprog" : [ ] }
Additional instructions
It is readable when the database is locked due to a snapshot. If you try to write data, the reader will be blocked because the database uses a read/write lock. This will be processed in the future.
Slave node Snapshot
The above process is for the slave node of the replication group. Slave nodes do not perform any operation during the lock period. In any case, see the appendix description.
Parts
The synchronization command can only be sent to a single node, rather than the entire sharded cluster.
1.9 change
Mongodb1.9 introduces two new shell auxiliary functions: DB. fsynclock () and DB. fsyncunlock (). they are provided for convenience, and they wrap the features described above about this interface. Next, let's take a look at their implementation:
> db.fsyncLock
function () {
return db.adminCommand({fsync:1, lock:true});
}
> db.fsyncUnlock
function () {
return db.getSiblingDB("admin").$cmd.sys.unlock.findOne();
}
The unlock call is blocked now.
It is worth noting that the UNLOCK Command has made a small change. Before 1.9.0, this command will request unlocking and return immediately. In this way, it is difficult to know whether the database has actually been unlocked.
The current command will block the knowledge that the database is unlocked. When it returns, you can determine that the database has synchronized data files to the disk and is ready to receive and write data.