Update program to binary directive

Author: kay-kim

source/administration/backups.txt

@@ -67,7 +67,7 @@ Approaches to Backing Up MongoDB Systems
 
 There are two main methodologies for backing up MongoDB
 instances. Creating binary "dumps" of the database using
-:program:`mongodump` or creating filesystem level snapshots. Both
+:binary:`~bin.mongodump` or creating filesystem level snapshots. Both
 methodologies have advantages and disadvantages:
 
 - binary database dumps are comparatively small, because they don't
@@ -83,7 +83,7 @@ methodologies have advantages and disadvantages:
 
 The best option depends on the requirements of your deployment and
 disaster recovery needs. Typically, filesystem snapshots are because
-of their accuracy and simplicity; however, :program:`mongodump` is a
+of their accuracy and simplicity; however, :binary:`~bin.mongodump` is a
 viable option used often to generate backups of MongoDB systems.
 
 The following topics provide details and procedures on the two approaches:

source/administration/configuration.txt

@@ -26,7 +26,7 @@ a package for your operating system, you likely already have a
 configuration file located at ``/etc/mongodb.conf``. Confirm this by
 checking the content of the ``/etc/init.d/mongod`` or
 ``/etc/rc.d/mongod`` script to insure that the :term:`control scripts
-<control script>` start the :program:`mongod` with the appropriate
+<control script>` start the :binary:`~bin.mongod` with the appropriate
 configuration file (see below.)
 
 To start MongoDB instance using this configuration issue a command in
@@ -63,7 +63,7 @@ configuration. It makes several assumptions, but consider the
 following explanation:
 
 - :setting:`fork` is ``true``, which enables a
-  :term:`daemon` mode for :program:`mongod`, which detaches (i.e. "forks")
+  :term:`daemon` mode for :binary:`~bin.mongod`, which detaches (i.e. "forks")
   the MongoDB from the current session and allows you to run the
   database as a conventional server.
 
@@ -93,21 +93,21 @@ following explanation:
 - :setting:`dbpath` is ``/srv/mongodb``, which
   specifies where MongoDB will store its data files. ``/srv/mongodb``
   and ``/var/lib/mongodb`` are popular locations. The user account
-  that :program:`mongod` runs under will need read and write access to this
+  that :binary:`~bin.mongod` runs under will need read and write access to this
   directory.
 
 - :setting:`logpath` is ``/var/log/mongodb/mongod.log``
-  which is where :program:`mongod` will write its output. If you do not set
-  this value, :program:`mongod` writes all output to standard output
+  which is where :binary:`~bin.mongod` will write its output. If you do not set
+  this value, :binary:`~bin.mongod` writes all output to standard output
   (e.g. ``stdout``.)
 
 - :setting:`logappend` is ``true``, which ensures that
-  :program:`mongod` does not overwrite an existing log file
+  :binary:`~bin.mongod` does not overwrite an existing log file
   following the server start operation.
 
 - :setting:`journal` is ``true``, which enables :term:`journaling <journal>`.
   Journaling ensures single instance write-durability. 64-bit builds
-  of :program:`mongod` enable journaling by default. Thus, this
+  of :binary:`~bin.mongod` enable journaling by default. Thus, this
   setting may be redundant.
 
 Given the default configuration, some of these values may be
@@ -120,7 +120,7 @@ Security Considerations
 -----------------------
 
 The following collection of configuration options are useful for
-limiting access to a :program:`mongod` instance. Consider the
+limiting access to a :binary:`~bin.mongod` instance. Consider the
 following:
 
 .. code-block:: cfg
@@ -169,7 +169,7 @@ among all members of the set. Consider the following:
    replSet = set0
 
 Use descriptive names for sets. Once configured use the
-:program:`mongo` shell to add hosts to the replica set.
+:binary:`~bin.mongo` shell to add hosts to the replica set.
 
 .. seealso:: :ref:`Replica set reconfiguration <replica-set-reconfiguration-usage>`.
 
@@ -185,7 +185,7 @@ following option:
    Setting :setting:`keyFile` enables authentication and specifies a key
    file for the replica set member use to when authenticating to each
    other. The content of the key file is arbitrary, but must be the same
-   on all members of the :term:`replica set` and :program:`mongos`
+   on all members of the :term:`replica set` and :binary:`~bin.mongos`
    instances that connect to the set. The keyfile must be less than one
    kilobyte in size and may only contain characters in the base64 set and
    the file must not have group or "world" permissions on UNIX systems.
@@ -205,7 +205,7 @@ following option:
 Sharding Configuration
 ~~~~~~~~~~~~~~~~~~~~~~
 
-Sharding requires a number of :program:`mongod` instances with
+Sharding requires a number of :binary:`~bin.mongod` instances with
 different configurations. The config servers store the cluster's
 metadata, while the cluster distributes data among one or more shard
 servers.
@@ -216,7 +216,7 @@ servers.
    sets <replica set>`.
 
 To set up one or three "config server" instances as :ref:`normal
-<base-config>` :program:`mongod` instances, and then add the following
+<base-config>` :binary:`~bin.mongod` instances, and then add the following
 configuration option:
 
 .. code-block:: cfg
@@ -229,9 +229,9 @@ configuration option:
 This creates a config server running on the private IP address
 ``10.8.0.12`` on port ``27001``. Make sure that there are no port
 conflicts, and that your config server is accessible from all of your
-":program:`mongos`" and ":program:`mongod`" instances.
+":binary:`~bin.mongos`" and ":binary:`~bin.mongod`" instances.
 
-To set up shards, configure two or more :program:`mongod` instance
+To set up shards, configure two or more :binary:`~bin.mongod` instance
 using your :ref:`base configuration <base-config>`, adding the
 :setting:`shardsvr` setting:
 
@@ -240,7 +240,7 @@ using your :ref:`base configuration <base-config>`, adding the
    shardsvr = true
 
 Finally, to establish the cluster, configure at least one
-:program:`mongos` process with the following settings:
+:binary:`~bin.mongos` process with the following settings:
 
 .. code-block:: cfg
 
@@ -251,7 +251,7 @@ You can specify multiple :setting:`configdb` instances by
 specifying hostnames and ports in the form of a comma separated
 list. In general, avoid modifying the :setting:`chunkSize` from
 the default value of 64, [#chunksize]_ and *should* ensure this setting is consistent
-among all :program:`mongos` instances.
+among all :binary:`~bin.mongos` instances.
 
 .. [#chunksize] :term:`Chunk` size is 64 megabytes by default, which
    provides the ideal balance between the most even distribution of
@@ -264,10 +264,10 @@ among all :program:`mongos` instances.
 Running Multiple Database Instances on the Same System
 ------------------------------------------------------
 
-In many cases running multiple instances of :program:`mongod` on a
+In many cases running multiple instances of :binary:`~bin.mongod` on a
 single system is not recommended. On some types of deployments
 [#multimongod]_ and for testing purposes you may need to run more than
-one :program:`mongod` on a single system.
+one :binary:`~bin.mongod` on a single system.
 
 In these cases, use a :ref:`base configuration <base-config>` for each
 instance, but consider the following configuration values:
@@ -278,11 +278,11 @@ instance, but consider the following configuration values:
    pidfilepath = /srv/mongodb/db0.pid
 
 The :setting:`dbpath` value controls the location of the
-:program:`mongod` instance's data directory. Ensure that each database
+:binary:`~bin.mongod` instance's data directory. Ensure that each database
 has a distinct and well labeled data directory. The
-:setting:`pidfilepath` controls where :program:`mongod` process
+:setting:`pidfilepath` controls where :binary:`~bin.mongod` process
 places it's :term:`process id <pid>` file. As this tracks the specific
-:program:`mongod` file, it is crucial that file be unique and well
+:binary:`~bin.mongod` file, it is crucial that file be unique and well
 labeled to make it easy to start and stop these processes.
 
 Create additional :term:`control scripts <control script>` and/or
@@ -291,14 +291,14 @@ needed to control these processes.
 
 .. [#multimongod] Single-tenant systems with :term:`SSD` or other high
    performance disks may provide acceptable performance levels for
-   multiple :program:`mongod` instances. Additionally, you may find that
+   multiple :binary:`~bin.mongod` instances. Additionally, you may find that
    multiple databases with small working sets may function acceptably
    on a single system.
 
 Diagnostic Configurations
 -------------------------
 
-The following configuration options control various :program:`mongod`
+The following configuration options control various :binary:`~bin.mongod`
 behaviors for diagnostic purposes. The following settings have default
 values that tuned for general production purposes:
 
@@ -327,7 +327,7 @@ needed:
   has a value, queries are not profiled.
 
 - :setting:`verbose` enables a verbose logging mode that
-  modifies :program:`mongod` output and increases logging to include a
+  modifies :binary:`~bin.mongod` output and increases logging to include a
   greater number of events. Only use this option if you are
   experiencing an issue that is not reflected in the normal logging
   level. If you require additional verbosity, consider the following
@@ -347,13 +347,13 @@ needed:
 - :setting:`diaglog` enables :term:`diagnostic logging <diagnostic log>`. Level ``3``
   logs all read and write options.
 
-- :setting:`objcheck` forces :program:`mongod` to validate all
+- :setting:`objcheck` forces :binary:`~bin.mongod` to validate all
   requests from clients upon receipt. Use this option to ensure that
   invalid requests are not causing errors, particularly when running a
   database with untrusted clients. This option may affect database
   performance.
 
-- :setting:`cpu` forces :program:`mongod` to report the percentage of
+- :setting:`cpu` forces :binary:`~bin.mongod` to report the percentage of
   the last interval spent in :term:`write-lock`. The interval is
   typically 4 seconds, and each output line in the log includes both
   the actual interval since the last report and the percentage of

source/administration/import-export.txt

@@ -26,7 +26,7 @@ with the database itself.
 .. warning::
 
    Because these tools primarily operate by interacting with a running
-   :program:`mongod` instance, they can impact the performance of your
+   :binary:`~bin.mongod` instance, they can impact the performance of your
    running database.
 
    Not only do these processes create traffic for a running
@@ -35,10 +35,10 @@ with the database itself.
    supplant more frequently accessed data, causing a deterioration in
    performance for the database's regular workload.
 
-   :program:`mongoimport` and :program:`mongoexport` do not reliably
+   :binary:`~bin.mongoimport` and :binary:`~bin.mongoexport` do not reliably
    preserve all rich :term:`BSON` data types, because :term:`BSON` is
-   a superset of :term:`JSON`. Thus, :program:`mongoimport` and
-   :program:`mongoexport` cannot represent :term:`BSON` data
+   a superset of :term:`JSON`. Thus, :binary:`~bin.mongoimport` and
+   :binary:`~bin.mongoexport` cannot represent :term:`BSON` data
    accurately in :term:`JSON`. As a result data exported or imported
    with these tools may lose some measure of fidelity. See
    :doc:`/reference/mongodb-extended-json` for more information about
@@ -184,16 +184,16 @@ portion thereof, to a file in a :term:`JSON` or :term:`CSV` format.
    If you want to simply copy a database or collection from one
    instance to another, consider using the :dbcommand:`copydb`,
    :dbcommand:`clone`, or :dbcommand:`cloneCollection` commands, which
-   may be more suited to this task. The :program:`mongo` shell
+   may be more suited to this task. The :binary:`~bin.mongo` shell
    provides the :method:`db.copyDatabase()` method.
 
 These tools may also be useful for importing data into a MongoDB database
 from third party applications.
 
-Collection Export with :program:`mongoexport`
+Collection Export with :binary:`~bin.mongoexport`
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-With the :program:`mongoexport` utility you can create a backup
+With the :binary:`~bin.mongoexport` utility you can create a backup
 file. In the most simple invocation, the command takes the following
 form:
 
@@ -204,7 +204,7 @@ form:
 This will export all documents in the collection named
 ``collection`` into the file ``collection.json``. Without the
 output specification (i.e. ":option:`--out collection.json
-<mongoexport --out>`",) :program:`mongoexport` writes output to
+<mongoexport --out>`",) :binary:`~bin.mongoexport` writes output to
 standard output (i.e. "stdout.") You can further narrow the results by
 supplying a query filter using the ":option:`--query <mongoexport --query>`"
 and limit results to a single database using the
@@ -220,14 +220,14 @@ of ``1``. Enclose the query in single quotes (e.g. ``'``) to ensure
 that it does not interact with your shell environment. The resulting
 documents will return on standard output.
 
-By default, :program:`mongoexport` returns one :term:`JSON document`
+By default, :binary:`~bin.mongoexport` returns one :term:`JSON document`
 per MongoDB document. Specify the
 ":option:`--jsonArray <mongoexport --jsonArray>`" argument to return
 the export as a single :term:`JSON` array. Use the ":option:`--csv
 <mongoexport --csv>`" file to return the result in CSV (comma
 separated values) format.
 
-If your :program:`mongod` instance is not running, you can use the
+If your :binary:`~bin.mongod` instance is not running, you can use the
 ":option:`--dbpath <mongoexport --dbpath>`" option to specify the
 location to your MongoDB instance's database files. See the following
 example:
@@ -237,8 +237,8 @@ example:
    mongoexport --db sales --collection contacts --dbpath /srv/MongoDB/
 
 This reads the data files directly. This locks the data directory to
-prevent conflicting writes. The :program:`mongod` process must *not* be
-running or attached to these data files when you run :program:`mongoexport`
+prevent conflicting writes. The :binary:`~bin.mongod` process must *not* be
+running or attached to these data files when you run :binary:`~bin.mongoexport`
 in this configuration.
 
 The ":option:`--host <mongoexport --host>`" and ":option:`--port
@@ -249,15 +249,15 @@ to connect to capture the export. Consider the following example:
 
    mongoexport --host mongodb1.example.net --port 37017 --username user --password pass --collection contacts --file mdb1-examplenet.json
 
-On any :program:`mongoexport` command you may, as above specify username and
+On any :binary:`~bin.mongoexport` command you may, as above specify username and
 password credentials as above.
 
-Collection Import with :program:`mongoimport`
+Collection Import with :binary:`~bin.mongoimport`
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-To restore a backup taken with :program:`mongoexport`. Most of the
-arguments to :program:`mongoexport` also exist for
-:program:`mongoimport`. Consider the following command:
+To restore a backup taken with :binary:`~bin.mongoexport`. Most of the
+arguments to :binary:`~bin.mongoexport` also exist for
+:binary:`~bin.mongoimport`. Consider the following command:
 
 .. code-block:: sh
 
@@ -266,11 +266,11 @@ arguments to :program:`mongoexport` also exist for
 This imports the contents of the file ``collection.json`` into the
 collection named ``collection``. If you do not specify a file with
 the ":option:`--file <mongoimport --file>`" option,
-:program:`mongoimport` accepts input over standard input
+:binary:`~bin.mongoimport` accepts input over standard input
 (e.g. "stdin.")
 
 If you specify the ":option:`--upsert <mongoimport --upsert>`" option,
-all of :program:`mongoimport` operations will attempt to update
+all of :binary:`~bin.mongoimport` operations will attempt to update
 existing documents in the database and insert other documents. This
 option will cause some performance impact depending on your
 configuration.
@@ -281,9 +281,9 @@ MongoDB instance is not running, use the ":option:`--dbpath
 <mongoimport --dbpath>`" option to specify the location of your
 MongoDB instance's database files. Consider using the
 ":option:`--journal <mongoimport --journal>`" option to ensure that
-:program:`mongoimport` records its operations in the journal. The
+:binary:`~bin.mongoimport` records its operations in the journal. The
 ``mongod`` process must *not* be running or attached to these data
-files when you run :program:`mongoimport` in this configuration.
+files when you run :binary:`~bin.mongoimport` in this configuration.
 
 Use the ":option:`--ignoreBlanks <mongoimport --ignoreBlanks>`" option
 to ignore blank fields. For :term:`CSV` and :term:`TSV` imports, this

source/administration/indexes.txt

@@ -258,7 +258,7 @@ List all Indexes for a Database
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 To return a list of all indexes on all collections in a database, use
-the following operation in the :program:`mongo` shell:
+the following operation in the :binary:`~bin.mongo` shell:
 
 .. code-block:: javascript
 
@@ -399,7 +399,7 @@ secondaries while they build the index.
 
 Secondaries will begin building indexes *after* the
 :term:`primary` finishes building the index. In :term:`sharded clusters
-<sharded cluster>`, the :program:`mongos` will send :method:`ensureIndex()
+<sharded cluster>`, the :binary:`~bin.mongos` will send :method:`ensureIndex()
 <db.collection.ensureIndex()>` to the primary members of the replica
 set for each shard, which then replicate to the secondaries after the
 primary finishes building the index.
@@ -413,15 +413,15 @@ the following procedure to build indexes on secondaries:
    the following procedure for each replica set that provides each
    :term:`shard`.
 
-#. Stop the :program:`mongod` process on one secondary. Restart the
-   :program:`mongod` process *without* the :option:`--replSet <mongod --replSet>`
+#. Stop the :binary:`~bin.mongod` process on one secondary. Restart the
+   :binary:`~bin.mongod` process *without* the :option:`--replSet <mongod --replSet>`
    option and running on a different port. [#different-port]_ This
    instance is now in "standalone" mode.
 
-#. Create the new index or rebuild the index on this :program:`mongod`
+#. Create the new index or rebuild the index on this :binary:`~bin.mongod`
    instance.
 
-#. Restart the :program:`mongod` instance with the
+#. Restart the :binary:`~bin.mongod` instance with the
    :option:`--replSet <mongod --replSet>` option. Allow replication
    to catch up on this member.
 
@@ -444,7 +444,7 @@ the following procedure to build indexes on secondaries:
    time. However, this procedure will only affect one member of the
    set at a time rather than *all* secondaries at the same time.
 
-.. [#different-port] By running the :program:`mongod` on a different
+.. [#different-port] By running the :binary:`~bin.mongod` on a different
    port, you ensure that the other members of the replica set and all
    clients will not contact the member while you are building the
    index.
@@ -460,11 +460,11 @@ Monitor and Control Index Building
    completion of DOCS-162
 
 To see the status of the indexing processes, you can use the
-:method:`db.currentOp()` method in the :program:`mongo` shell. The value
+:method:`db.currentOp()` method in the :binary:`~bin.mongo` shell. The value
 of the ``query`` field and the ``msg`` field will indicate if the
 operation is an index build. The ``msg`` field also indicates the
 percent of the build that is complete.
 
 You can only terminate a background index build. If you need to
 terminate an ongoing index build, You can use the
-:method:`db.killOp()` method in the :program:`mongo` shell.
+:method:`db.killOp()` method in the :binary:`~bin.mongo` shell.