DOCS-1148 fixing stale links

Author: Sam Kleinman

source/administration/journaling.txt

@@ -180,7 +180,7 @@ journal directory before the server becomes available. If MongoDB must
 replay journal files, :program:`mongod` notes these events in the log
 output.
 
-There is no reason to run :dbcommand:`repair` in these situations.
+There is no reason to run :dbcommand:`repairDatabase` in these situations.
 
 .. _journaling-internals:
 

source/administration/monitoring.txt

@@ -303,7 +303,7 @@ performance.
 If :data:`globalLock.totalTime <serverStatus.globalLock.totalTime>` is
 high in context of :data:`~serverStatus.uptime` then the database has
 existed in a lock state for a significant amount of time. If
-:data:`globalLock.ratio` is also high, MongoDB has likely been
+:data:`globalLock.ratio <serverStatus.globalLock.ratio>` is also high, MongoDB has likely been
 processing a large number of long running queries. Long queries are
 often the result of a number of factors: ineffective use of indexes,
 non-optimal schema design, poor query structure, system architecture

source/administration/replica-set-architectures.txt

@@ -59,13 +59,15 @@ conditions are true:
 
 - The set has no more than 7 voting members at a time.
 
-- Members that cannot function as primaries in a :term:`failover`
-  have their :data:`priority <members[n].priority>` values set to ``0``.
+- Members that cannot function as primaries in a :term:`failover` have
+  their :data:`~local.system.replset.members[n].priority` values set to
+  ``0``.
 
-  If a member cannot function as a primary because of
-  resource or network latency constraints a :data:`priority <members[n].priority>` value
-  of ``0`` prevents it from being a primary. Any member with a
-  ``priority`` value greater than ``0`` is available to be a primary.
+  If a member cannot function as a primary because of resource or
+  network latency constraints a
+  :data:`~local.system.replset.members[n].priority>` value of ``0``
+  prevents it from being a primary. Any member with a ``priority``
+  value greater than ``0`` is available to be a primary.
 
 - A majority of the set's members operate in the main data center.
 
@@ -78,9 +80,10 @@ Geographically Distributed Sets
 
 A geographically distributed replica set provides data recovery should
 one data center fail. These sets include at least one member in a
-secondary data center. The member has its :data:`priority
-<members[n].priority>` :ref:`set <replica-set-reconfiguration-usage>` to
-``0`` to prevent the member from ever becoming primary.
+secondary data center. The member has its
+:data:`~local.system.replset.members[n].priority`
+:ref:`set <replica-set-reconfiguration-usage>` to ``0`` to prevent the
+member from ever becoming primary.
 
 In many circumstances, these deployments consist of the following:
 
@@ -91,8 +94,8 @@ In many circumstances, these deployments consist of the following:
   This member can become the primary member at any time.
 
 - One secondary member in a secondary data center. This member is
-  ineligible to become primary. Set its :data:`members[n].priority` to
-  ``0``.
+  ineligible to become primary. Set its
+  :data:`local.system.replset.members[n].priority` to ``0``.
 
 If the primary is unavailable, the replica set will elect a new primary
 from the primary data center.
@@ -126,10 +129,11 @@ You might create such a member to provide backups, to support reporting
 operations, or to act as a cold standby. Such members fall into one or
 more of the following categories:
 
-- **Low-Priority**: These members have :data:`members[n].priority`
-  settings such that they are either unable to become :term:`primary` or
-  *very* unlikely to become primary. In all other respects these
-  low-priority members are identical to other replica set member. (See:
+- **Low-Priority**: These members
+  have :data:`local.system.replset.members[n].priority` settings such
+  that they are either unable to become :term:`primary` or *very*
+  unlikely to become primary. In all other respects these low-priority
+  members are identical to other replica set member. (See:
   :ref:`replica-set-secondary-only-members`.)
 
 - **Hidden**: These members cannot become primary *and* the set excludes
@@ -204,7 +208,7 @@ receive no traffic beyond what replication requires. While hidden members
 are not electable as primary, they are still able to *vote* in elections
 for primary. If your operational parameters requires this kind of
 reporting functionality, see :ref:`Hidden Replica Set Nodes
-<replica-set-hidden-members>` and :data:`members[n].hidden` for more
+<replica-set-hidden-members>` and :data:`local.system.replset.members[n].hidden` for more
 information regarding this functionality.
 
 Cold Standbys
@@ -233,7 +237,7 @@ primary *and* a quorum of voting members in the main facility.
 .. note::
 
    If your set already has ``7`` members, set the
-   :data:`members[n].votes` value to ``0`` for these members, so that
+   :data:`local.system.replset.members[n].votes` value to ``0`` for these members, so that
    they won't vote in elections.
 
 .. seealso:: :ref:`Secondary Only <replica-set-secondary-only-members>`,

source/administration/replica-sets.txt

@@ -498,7 +498,7 @@ The first operation uses :method:`rs.conf()` to set the local variable
 is a :term:`document`. The next three operations change the
 :data:`~local.system.replset.settings.members[n].priority` value in the ``cfg`` document for the
 first three members configured in the :data:`members
-<rs.conf.members>` array. The final operation
+<local.system.replset.members>` array. The final operation
 calls :method:`rs.reconfig()` with the argument of ``cfg`` to initialize
 the new configuration.
 
@@ -667,7 +667,7 @@ You can use the following sequence of commands:
    cfg.settings.chainingAllowed = true
    rs.reconfig(cfg)
 
-.. note:: 
+.. note::
 
    If chained replication is disabled, you still can use
    :dbcommand:`replSetSyncFrom` to specify that a secondary replicates
@@ -745,11 +745,11 @@ To resync the stale member:
    At this point, the :program:`mongod` will perform an initial
    sync. The length of the initial sync may process depends on the
    size of the database and network connection between members of the
-   replica set. 
+   replica set.
 
    Initial sync operations can impact the other members of the set and
    create additional traffic to the primary, and can only occur if
-   another member of the set is accessible and up to date. 
+   another member of the set is accessible and up to date.
 
 .. index:: replica set; resync
 .. _replica-set-resync-by-copying:
@@ -758,14 +758,14 @@ Resync by Copying All Datafiles from Another Member
 ```````````````````````````````````````````````````
 
 This approach uses a copy of the data files from an existing member of
-the replica set, or a back of the data files to "seed" the stale member. 
+the replica set, or a back of the data files to "seed" the stale member.
 
 The copy or backup of the data files **must** be sufficiently recent
 to allow the new member to catch up with the :term:`oplog`, otherwise
 the member would need to perform an initial sync.
 
-.. note:: 
-   
+.. note::
+
    In most cases you cannot copy data files from a running
    :program:`mongod` instance to another, because the data files will
    change during the file copy operation. Consider the
@@ -795,12 +795,12 @@ Additionally, MongoDB provides an authentication mechanism for
 replica sets. These instances enable authentication but specify a
 shared key file that serves as a shared password.
 
-.. versionadded:: 1.8 
+.. versionadded:: 1.8
    Added support authentication in replica set deployments.
 
 .. versionchanged:: 1.9.1
    Added support authentication in sharded replica set deployments.
-                 
+
 
 To enable authentication add the following option to your configuration file:
 
@@ -1155,20 +1155,20 @@ the oplog has the wrong data type in the ``ts`` field.
    .. code-block:: javascript
 
       { "ts" : {t: 1347982456000, i: 1},
-        "h" : NumberLong("8191276672478122996"), 
-        "op" : "n", 
-        "ns" : "", 
+        "h" : NumberLong("8191276672478122996"),
+        "op" : "n",
+        "ns" : "",
         "o" : { "msg" : "Reconfig set", "version" : 4 } }
 
    And the second query returns this as the last entry where ``ts``
    has the ``Timestamp`` type:
 
    .. code-block:: javascript
 
-      { "ts" : Timestamp(1347982454000, 1), 
-        "h" : NumberLong("6188469075153256465"), 
-        "op" : "n", 
-        "ns" : "", 
+      { "ts" : Timestamp(1347982454000, 1),
+        "h" : NumberLong("6188469075153256465"),
+        "op" : "n",
+        "ns" : "",
         "o" : { "msg" : "Reconfig set", "version" : 3 } }
 
    Then the value for the ``ts`` field in the last oplog entry is of the
@@ -1179,7 +1179,7 @@ use an update operation that resembles the following:
 
 .. code-block:: javascript
 
-   db.oplog.rs.update( { ts: { t:1347982456000, i:1 } }, 
+   db.oplog.rs.update( { ts: { t:1347982456000, i:1 } },
                        { $set: { ts: new Timestamp(1347982456000, 1)}})
 
 Modify the timestamp values as needed based on your oplog entry. This
@@ -1232,4 +1232,4 @@ primary and the set will become read only. To avoid this situation,
 attempt to place a majority of instances in one data center with a
 minority of instances in a secondary facility.
 
-.. see:: :ref:`replica-set-election-internals`. 
+.. see:: :ref:`replica-set-election-internals`.

source/core/data-modeling.txt

@@ -250,7 +250,7 @@ start.
 The :option:`--nssize <mongod --nssize>` sets the size for *new*
 ``<database>.ns`` files. For existing databases, after starting up the
 server with :option:`--nssize <mongod --nssize>`, run the
-:dbcommand:`db.repairDatabase()` command from the :program:`mongo`
+:method:`db.repairDatabase()` command from the :program:`mongo`
 shell.
 
 Indexes

source/core/geospatial-indexes.txt

@@ -180,9 +180,9 @@ area in order to improve performance for queries limited to that area.
 Each bucket in a haystack index contains all the documents within a
 specified proximity to a given longitude and latitude. Use the
 ``bucketSize`` parameter of :method:`ensureIndex()
-<db.command.ensureIndex()>` to determine proximity. A ``bucketSize``
-of ``5`` creates an index that groups location values that are within
-5 units of the specified longitude and latitude.
+<db.collection.ensureIndex()>` to determine proximity. A
+``bucketSize`` of ``5`` creates an index that groups location values
+that are within 5 units of the specified longitude and latitude.
 
 ``bucketSize`` also determines the granularity of the index. You can
 tune the parameter to the distribution of your data so that in general
@@ -191,7 +191,7 @@ space. Furthermore, the areas defined by buckets can overlap: as a
 result a document can exist in multiple buckets.
 
 To build a haystack index, use the ``bucketSize`` parameter in the
-:method:`ensureIndex() <db.command.ensureIndex()>` method, as in the
+:method:`ensureIndex() <db.collection.ensureIndex()>` method, as in the
 following prototype:
 
 .. code-block:: javascript

source/core/object-id.txt

@@ -47,11 +47,11 @@ and methods:
 
    The hexadecimal string value of the ``ObjectId()`` object.
 
-- :method:`getTimestamp() <ObjectId.getTimestamp()>`
+- :method:`~ObjectId.getTimestamp()`
 
    Returns the timestamp portion of the ``ObjectId()`` object as a Date.
 
-- :method:`toString() <ObjectId.toString()>`
+- :method:`~ObjectId.toString()`
 
    Returns the string representation of the ``ObjectId()`` object. The
    returned string literal has the format "``ObjectId(...)``".
@@ -128,7 +128,7 @@ Consider the following uses ``ObjectId()`` class in the
      507f191e810c19729de860ea
 
 - To return the string representation of an ``ObjectId()`` object, use
-  the :method:`toString() <ObjectId.toString()>` method as follows:
+  the :method:`~ObjectId.toString()` method as follows:
 
   .. code-block:: javascript
 
@@ -141,7 +141,7 @@ Consider the following uses ``ObjectId()`` class in the
      ObjectId("507f191e810c19729de860ea")
 
 - To return the value of an ``ObjectId()`` object as a hexadecimal
-  string, use the :method:`valueOf() <ObjectId.valueOf()>` method as
+  string, use the :method:`~ObjectId.valueOf()` method as
   follows:
 
   .. code-block:: javascript

source/core/read-operations.txt

@@ -875,7 +875,7 @@ Consider the following behaviors related to cursors:
 
   - As you iterate through the cursor and reach the end of the returned
     batch, if there are more results, :method:`cursor.next()` will
-    perform a :data:`getmore operation <currentop.op>` to retrieve the next batch.
+    perform a :data:`getmore operation <currentOp.op>` to retrieve the next batch.
 
     To see how many documents remain in the batch as you iterate the
     cursor, you can use the :method:`~cursor.objsLeftInBatch()` method,
@@ -966,7 +966,7 @@ operations for more basic data aggregation operations:
 
 - :dbcommand:`count` (:method:`~cursor.count()`)
 
-- :dbcommand:`distinct` (:method:`~cursor.distinct()`)
+- :dbcommand:`distinct` (:method:`db.collection.distinct()`)
 
 - :dbcommand:`group` (:method:`db.collection.group()`)
 

source/core/replication.txt

@@ -141,14 +141,14 @@ Member Priority
 In a replica set, every member has a "priority," that helps determine
 eligibility for :ref:`election <replica-set-elections>` to
 :term:`primary`. By default, all members have a priority of ``1``,
-unless you modify the :data:`members[n].priority` value. All members
+unless you modify the :data:`~local.system.replset.members[n].priority` value. All members
 have a single vote in elections.
 
 .. warning::
 
-   Always configure the :data:`members[n].priority` value to control
+   Always configure the :data:`~local.system.replset.members[n].priority` value to control
    which members will become primary. Do not configure
-   :data:`members[n].votes` except to permit more than 7 secondary
+   :data:`~local.system.replset.members[n].votes` except to permit more than 7 secondary
    members.
 
 For more information on member priorities, see the
@@ -468,8 +468,9 @@ The architecture and design of the :term:`replica set` deployment can
 have a great impact on the set's capacity and capability. This section
 provides a general overview of the architectural possibilities for
 replica set deployments.  However, for most production deployments a
-conventional 3-member replica set with :data:`members[n].priority`
-values of ``1`` are sufficient.
+conventional 3-member replica set with
+:data:`~local.system.replset.members[n].priority` values of ``1`` are
+sufficient.
 
 While the additional flexibility discussed is below helpful for
 managing a variety of operational complexities, it always makes sense

source/core/write-operations.txt

@@ -361,7 +361,7 @@ more efficient than those updates that cause document growth. Use
 document growth when possible.
 
 For complete examples of update operations, see
-:doc:`/applications/update`. 
+:doc:`/applications/update`.
 
 .. _write-operations-padding-factor:
 
@@ -396,7 +396,7 @@ padding for new inserts and moves.
    but does not eliminate, document movements.
 
 To check the current :data:`~collStats.paddingFactor` on a collection, you can
-run the :dbcommand:`db.collection.stats()` command in the
+run the :method:`db.collection.stats()` operation in the
 :program:`mongo` shell, as in the following example:
 
 .. code-block:: javascript