Copy edits: typos and edits for style

draft/reserved-keywords.txt

@@ -0,0 +1,14 @@
+.. _reserved_keywords:
+
+=========================
+MongoDB Reserved Keywords
+=========================
+
+.. default-domain:: mongodb
+
+stats
+
+   In the :program:`mongo` shell, the collection name ``stats``
+   is reserved by the :method:`db.stats()` method.  To reference
+   a collection named ``stats`` in the :program:`mongo` shell you
+   must use :method:`db.runCommand()`.

source/administration/backups.txt

@@ -5,7 +5,7 @@ Backup Strategies for MongoDB Systems
 .. default-domain:: mongodb
 
 Backups are an important part of any operational disaster recovery
-plan. A good backup plan must be able to reproducible capture data in
+plan. A good backup plan must be able to capture data in
 a consistent and usable state, and operators must be able to automate
 both the backup and the recovery operations. Also test all components
 of the backup system to ensure that you can recover backed up data as
@@ -42,7 +42,7 @@ the following factors:
   substantial system resources. It is important to consider the time of
   the backup schedule relative to peak usage and maintenance windows.
 
-- System capabilities. Some of the block-level snapshot tools requires
+- System capabilities. Some of the block-level snapshot tools require
   special support on the operating-system or infrastructure level.
 
 - Database configuration. :term:`Replication` and :term:`sharding
@@ -65,7 +65,7 @@ instances. Creating binary "dumps" of the database using
 methodologies have advantages and disadvantages:
 
 - binary database dumps are comparatively small, because they don't
-  include index content pre-allocated free space, and :ref:`record
+  include index content or pre-allocated free space, and :ref:`record
   padding <write-operations-padding-factor>`. However, it's impossible to
   capture a copy of a running system that reflects a single moment in
   time using a binary dump.

source/administration/configuration.txt

@@ -13,9 +13,9 @@ controlling the operation of the database system. This document
 provides an overview of common configurations and examples of
 best-practice configurations for common use cases.
 
-While both interfaces provide access the same collection of options
+While both interfaces provide access to the same collection of options
 and settings, this document primarily uses the configuration file
-interface. If you run MongoDB using a control script or packaged for
+interface. If you run MongoDB using a control script or 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
@@ -99,9 +99,9 @@ following explanation:
   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
-   setting may be redundant.
+  Journaling ensures single instance write-durability. 64-bit builds
+  of :program:`mongod` enable journaling by default. Thus, this
+  setting may be redundant.
 
 Given the default configuration, some of these values may be
 redundant. However, in many situations explicitly stating the
@@ -135,13 +135,13 @@ Consider the following explanation for these configuration decisions:
   servers. At the same time it's important to limit these interfaces
   to interfaces controlled and protected at the network layer.
 
-- ":setting:`nounixsocket`" is  ``true`` which disables the
+- ":setting:`nounixsocket`" to ``true`` disables the
   UNIX Socket, which is otherwise enabled by default. This limits
   access on the local system. This is desirable when running MongoDB
-  on with shared access, but in most situations has minimal impact.
+  on systems with shared access, but in most situations has minimal impact.
 
-- ":setting:`auth`" is ``true`` which enables the authentication
-  system within MongoDB. If enabled you will need to log in, by
+- ":setting:`auth`" is ``true`` enables the authentication
+  system within MongoDB. If enabled you will need to log in by
   connecting over the ``localhost`` interface for the first time to
   create user credentials.
 
@@ -179,9 +179,9 @@ following option:
    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`
-   instances that connect to the set. The keyfile must be less one
+   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
-   file must not have group or "world" permissions on UNIX systems.
+   the file must not have group or "world" permissions on UNIX systems.
 
 .. seealso:: The ":ref:`Replica set Reconfiguration
    <replica-set-reconfiguration-usage>`" section for information regarding
@@ -258,7 +258,7 @@ Running Multiple Database Instances on the Same System
 ------------------------------------------------------
 
 In many cases running multiple instances of :program:`mongod` on a
-single system is not recommended, on some types of deployments
+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.
 
@@ -274,7 +274,7 @@ The :setting:`dbpath` value controls the location of the
 :program:`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
-places it's :term:`pid` file. As this tracks the specific
+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
 labeled to make it easy to start and stop these processes.
 

source/administration/import-export.txt

@@ -23,7 +23,7 @@ with the database itself.
    :program:`mongod` instance, they can impact the performance of your
    running database.
 
-   Not only do these backup processes create traffic for a running
+   Not only do these processes create traffic for a running
    database instance, they also force the database to read all data
    through memory. When MongoDB reads infrequently used data, it can
    supplant more frequently accessed data, causing a deterioration in
@@ -34,9 +34,9 @@ with the database itself.
    a superset of :term:`JSON`. Thus, :program:`mongoimport` and
    :program:`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 the
-   ":wiki:`MongoDB Extended JSON <Mongo+Extended+JSON>`" wiki page for
-   more information about Use with care.
+   with these tools may lose some measure of fidelity. See
+   :doc:`/reference/mongodb-extended-json` for more information about
+   MongoDB Extended JSON.
 
 .. seealso:: See the ":doc:`/administration/backups`" document for
    more information on backing up MongoDB instances. Additionally,
@@ -48,8 +48,8 @@ with the database itself.
    - :doc:`/reference/mongodump`
 
    If you want to transform and process data once you've imported it
-   in MongoDB consider the topics in :doc:`/aggregation`, including: 
-   
+   in MongoDB consider the topics in :doc:`/aggregation`, including:
+
    - :doc:`/applications/map-reduce` and
    - :doc:`/applications/aggregation`.
 
@@ -135,7 +135,7 @@ JSON.
 Data Import and Export and Backups Operations
 ---------------------------------------------
 
-For resilient and non-disruptive backups, 
+For resilient and non-disruptive backups,
 use a file system or block-level disk snapshot function, such as the
 methods described in the ":doc:`/administration/backups`" document. The
 tools and operations discussed provide functionality that's useful in
@@ -215,7 +215,7 @@ 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`
-per MongoDB document. Specify the 
+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

source/administration/journaling.txt

@@ -49,7 +49,7 @@ To enable journaling, start :program:`mongod` with the
 :option:`--journal <mongod --journal>` command line option.
 
 If no journal files exist, when :program:`mongod` starts, it must
-preallocates new journal files. During this operation, the
+preallocate new journal files. During this operation, the
 :program:`mongod` is not listening for connections until preallocation
 completes: for some systems this may take a several minutes. During
 this period your applications and the :program:`mongo` shell are not
@@ -70,13 +70,10 @@ Disable Journaling
 To disable journaling, start :program:`mongod` with the
 :option:`--nojournal <mongod --nojournal>` command line option.
 
-To disable journaling, shut down :program:`mongod` cleanly and restart
-with :option:`--nojournal <mongod --nojournal>`.
-
 Get Commit Acknowledgment
 ~~~~~~~~~~~~~~~~~~~~~~~~~
 
-You can get commit acknowledgement with the
+You can get commit acknowledgment with the
 :dbcommand:`getLastError` command and the ``j`` option. For details, see
 :ref:`write-concern-operation`.
 

source/administration/master-slave.txt

@@ -124,7 +124,7 @@ you start the :setting:`master` instance, by adding the
 :program:`mongod`. If you do not specify
 :option:`--oplogSize <mongod --oplogSize>`, :program:`mongod` will
 allocate 5% of available disk space on start up to the oplog, with a
-ominimum of 1GB for 64bit machines and 50MB for 32bit machines.
+minimum of 1GB for 64bit machines and 50MB for 32bit machines.
 
 Run time Master-Slave Configuration
 -----------------------------------

source/administration/monitoring.txt

@@ -12,7 +12,7 @@ allow you to diagnose issues as you encounter them, rather than
 waiting for a crisis or failure.
 
 This document provides an overview of the available tools and data
-provided by MongoDB as well as introduction to diagnostic strategies,
+provided by MongoDB as well as an introduction to diagnostic strategies,
 and suggestions for monitoring instances in MongoDB's replica sets and
 sharded clusters.
 
@@ -89,7 +89,7 @@ MongoDB provides a number of commands that return
 statistics about the state of the MongoDB instance. These data may
 provide finer granularity regarding the state of the MongoDB instance
 than the tools above. Consider using their output in scripts and
-programs to develop custom alerts, or modifying the behavior of your
+programs to develop custom alerts, or to modify the behavior of your
 application in response to the activity of your instance.
 
 ``serverStatus``
@@ -203,7 +203,7 @@ on your own servers, usually open source.
      - `mikoomi-mongodb <https://code.google.com/p/mikoomi/wiki/03>`_
      - Monitors availability, resource utilization, health, performance and other important metrics.
 
-Also consider `dex <https://github.com/mongolab/dex>`_, and index and
+Also consider `dex <https://github.com/mongolab/dex>`_, an index and
 query analyzing tool for MongoDB that compares MongoDB log files and
 indexes to make indexing recommendations.
 
@@ -233,10 +233,10 @@ Process Logging
 During normal operation, :program:`mongod` and :program:`mongos`
 instances report information that reflect current operation to
 standard output, or a log file. The following runtime settings
-methods to control these options.
+control these options.
 
 - :setting:`quiet`. Limits the amount of information written to the
-  log our output.
+  log or output.
 
 - :setting:`verbose`. Increases the amount of information written to
   the log or output.
@@ -260,6 +260,7 @@ methods to control these options.
    </reference/mongos>`
 
 Additionally, the following :term:`database commands <database command>`
+affect logging:
 
 - :dbcommand:`getLog`. Displays recent messages from the :program:`mongod` process log.
 
@@ -270,7 +271,7 @@ Diagnosing Performance Issues
 -----------------------------
 
 Degraded performance in MongoDB can be the result of an array of
-causes, and is typically a function of the relationship between the
+causes, and is typically a function of the relationship amongst the
 quantity of data stored in the database, the amount of system RAM, the
 number of connections to the database, and the amount of time the
 database spends in a lock state.
@@ -281,19 +282,20 @@ the host system for virtualized environments. Some users also
 experience performance limitations as a result of inadequate or
 inappropriate indexing strategies, or as a consequence of poor schema
 design patterns. In other situations, performance issues may indicate
-that the database may be operating at capacity and that it's time to
+that the database may be operating at capacity and that it is time to
 add additional capacity to the database.
 
 Locks
 ~~~~~
 
-MongoDB uses a locking system to ensure consistency; however, if
+MongoDB uses a locking system to ensure consistency. However, if
 certain operations are long-running, or a queue forms, performance
 slows as requests and operations wait for the lock. Because lock
 related slow downs can be intermittent, look to the data in the
 :ref:`globalLock` section of the :dbcommand:`serverStatus` response to
-asses if the lock has been a challenge to your performance. If
-:data:`globalLock.currentQueue.total <serverStatus.globalLock.currentQueue.total>` is consistently high, then
+assess if the lock has been a challenge to your performance. If
+:data:`globalLock.currentQueue.total <serverStatus.globalLock.currentQueue.total>`
+is consistently high, then
 there is a chance that a large number of requests are waiting for a
 lock. This indicates a possible concurrency issue that might affect
 performance.
@@ -343,6 +345,8 @@ check for page faults, see the :data:`extra_info.page_faults
 :dbcommand:`serverStatus` command. This data is only available on
 Linux systems.
 
+.. we should reverify the previous statement as the info is appearing on OS X as well
+
 Alone, page faults are minor and complete quickly; however, in
 aggregate, large numbers of page fault typically indicate that MongoDB
 is reading too much data from disk and can indicate a number of
@@ -355,7 +359,7 @@ this also improves overall throughput.
 If possible, increasing the amount of RAM accessible to MongoDB may
 help reduce the number of page faults. If this is not possible, you
 may want to consider deploying a :term:`sharded cluster` and/or
-adding one or more :term:`shards <shard>`  to your deployment to
+adding one or more :term:`shards <shard>` to your deployment to
 distribute load among :program:`mongod` instances.
 
 Number of Connections
@@ -440,7 +444,7 @@ The following profiling levels are available:
 ===========  ======================================
 
 See the output of the profiler in the ``system.profile`` collection of
-your database. You can specify the :setting:`slowms` to set a
+your database. You can specify the :setting:`slowms` setting to set a
 threshold above which the profiler considers operations "slow" and
 thus included in the level ``1`` profiling data. You may configure
 :setting:`slowms` at runtime, as an argument to the
@@ -472,7 +476,7 @@ Replication and Monitoring
 --------------------------
 
 The primary administrative concern that requires monitoring with
-replica sets, beyond the requirements for any MongoDB instance is
+replica sets, beyond the requirements for any MongoDB instance, is
 "replication lag." This refers to the amount of time that it takes a
 write operation on the :term:`primary` to replicate to a
 :term:`secondary`. Some very small delay period may be acceptable;
@@ -551,7 +555,7 @@ Balancing and Chunk Distribution
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 The most effective :term:`sharded cluster` deployments require that
-:term:`chunks <chunk>` are evenly balanced between the shards. MongoDB
+:term:`chunks <chunk>` are evenly balanced among the shards. MongoDB
 has a background :term:`balancer` process that distributes data such that
 chunks are always optimally distributed among the :term:`shards <shard>`.
 Issue the :method:`db.printShardingStatus()` or :method:`sh.status()`

source/administration/operational-segregation.txt

@@ -11,7 +11,7 @@ MongoDB includes a cluster features that allow database administrators
 and developers to segregate application operations to MongoDB
 deployments by functional or geographical groupings. This capability
 provides "data center awareness," where application operations target
-he MongoDB deployment with consideration of the location of
+the MongoDB deployment with consideration of the location of
 :program:`mongod` instances in multi-data center deployments. In
 single data center deployments, users can use these features to
 provide "rack awareness," that allows users to control operations
@@ -26,12 +26,12 @@ collection only exist on specific shards.
 Specifically, with MongoDB, you can:
 
 - ensure write operations propagate to specific members of a replica
-  set, or specific members of replica sets.
+  set, or to specific members of replica sets.
 
 - ensure that specific members of a replica set respond to queries.
 
 - ensure that specific ranges of your :term:`shard key` balance onto and
-  reside on specific :term:`shard`.
+  reside on specific :term:`shards <shard>`.
 
 - combine the above features in a single distributed deployment, on a
   per-operation (for read and write operations) and collection (for
@@ -41,17 +41,16 @@ For full documentation of these features see the following
 documentation in the MongoDB Manual:
 
 - :ref:`Read Preferences <read-preference>`, which controls how drivers
-  help applications target read operations to members of a replica
-  set.
+  help applications target read operations to members of a replica set.
 
 - :ref:`Write Concerns <replica-set-write-concern>`, which controls
   how MongoDB ensures that write operations propagate to members of a
   replica set.
 
 - :ref:`Replica Set Tags <replica-set-configuration-tag-sets>`, which
-  controls how applications create and interact with custom groupings
-  of replica set members to create custom application specific a read
-  preference and write concerns.
+  control how applications create and interact with custom groupings
+  of replica set members to create custom application specific read
+  preferences and write concerns.
 
 - :ref:`Tag Aware Sharding <tag-aware-sharding>`, which allows MongoDB
   administrators to define an application specific balancing policy,