To run mongomirror, you must specify the source replica
set and the target Atlas replica set. For Atlas, you must
specify a user in the Atlas cluster with
appropriate privileges and the
corresponding password. If the source replica set requires
authentication, you must specify a user with
appropriate privileges.

When tailing the oplog, mongomirror logs the lag time,
in seconds, between the most recent oplog entry on the source and the
last processed oplog entry on the target. For example:

2016-12-12T16:22:17.027-0800 Current lag from source: 6s

A lag time of 6 seconds means that the last oplog entry
mongomirror processed was 6 seconds behind the most
recent one available on the source.

Note

The amount of time it takes mongomirror to catch up
completely may be greater or lesser than 6 seconds, depending on
how many entries arrive per second.

A lag time of 0 seconds indicates that mongomirror is
processing entries that arrived less than one second before the latest
oplog entry.

If there are indexes on the source cluster, mongomirror builds the
same indexes on the target cluster. The progress log shows the start
time and end time of the index building process, but does not display
the iterative progress of the process. To check on the progress
of the index builds, you can either:

Use the
currentOp
command on the primary node of the target cluster. The command
field shows information about the currently running operation.
Index building entries look similar to the following:

If the source replica set requires authentication, you must include
user credentials when running mongomirror. You must
specify a MongoDB user that has the backup role. If no
such user exists, create the user in your source MongoDB replica set.
For example, if the source replica set uses SCRAM-SHA1
authentication:

If the source replica set requires authentication, the name of a user
in the source replica set with privileges to read any database,
including the local database. A user with the backup role provides
the appropriate privileges. For details on the specific privileges
required, see Required Access on Source Replica Set.

Name of a MongoDB user in the Atlas cluster with privileges to
read, write, and admin any database.
A user with the Atlas admin role
provides the appropriate privileges. For details on the specific
privileges required, see Required Access on Destination Cluster.

Disables the validation of the hostnames in TLS/SSL certificates presented by the source replica set.
Allows mongomirror to connect to the source replica set if the
hostname in the certificates does not match the specified hostname.

Bypasses the validation checks for certificates presented by the source replica set and allows
the use of invalid certificates. When using the
--allowInvalidCertificates setting, MongoDB logs as a warning the
use of the invalid certificate.

Enables mongomirror to buffer the initial sync oplog window to disk.
When you specify a value for this option, mongomirror streams the
source oplog entries to the specified directory in a single
file: <oplogPath>/oplog-mongomirror.bson.sz. After the entire
oplog file is replayed to the destination cluster, mongomirror
removes the file and starts tailing the source oplog without
buffering.

By default, mongomirror streams oplog entries from the source
and applies them to the destination cluster. However, the
migration may fail if the source oplog is not large enough to
contain the entire initial sync oplog window. To avoid this
error, you can either increase the size of the source oplog, or specify this option to ensure
that the source oplog will not run out of space during the migration
process.

Important

There must be enough disk space to accommodate all of the source
oplog entries that occur during the initial mongomirror sync.

Example

If the source oplog is 10 GB and covers 24 hours of changes,
and mongomirror’s sync is estimated to take 48 hours, there
must be at least 20 GB of free disk space in the specified
directory.

Directs mongomirror to start an HTTP server on port 8080. You can
retrieve the current status of mongomirror by issuing an HTTP GET request
to http://localhost:8080.

When running with --httpStatusPort, mongomirror does not exit when it encounters an
error. Instead, it logs the error as normal and reports the error over HTTP.

mongomirror returns a document in response to the HTTP request. The following
example syntax represents all the possible output fields - the actual
response may only return a subset of these fields. See the subsequent table
for a description of the fields and when to expect them.

Support for buffering the oplog to disk during initial sync. This
ensures that the source oplog will not run out of space during the
migration process. For more information, see the documentation for
the new --oplogPath command line option.