Mass typo cleanup, ran entire document lib through spell check.

also fixed spelling of several commands and options after verifying
in source (eg: --jsonnp changed to --jsonp)

Author: Ed Costello

.gitignore

@@ -4,3 +4,4 @@ build/*
 \#*#
 *__pycache__*
 *.pyc
+*.bak

source/about.txt

@@ -11,7 +11,7 @@ About MongoDB
 
 MongoDB is a :term:`document`-oriented database management system
 designed for performance, horizontal scalability, high
-availability, and advanced queryabiliy. See the following :wiki:`wiki
+availability, and advanced queryability. See the following :wiki:`wiki
 pages <>` for more information about MongoDB:
 
 - :wiki:`Introduction`
@@ -65,7 +65,7 @@ via "|hardlink|" and you can always reference the commit of the
 current manual in the :hardlink:`release.txt` file.
 
 The most up-to-date, current, and stable version of the manual is
-always avalible at "http://docs.mongodb.org/manual/."
+always available at "http://docs.mongodb.org/manual/."
 
 Contributing to the Documentation
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -100,6 +100,6 @@ necessary Sphinx extensions and build tools, are available in the same
 repository as the documentation.
 
 You can view the documentation style guide and the build instructions
-in reSturctured Text files in the top-level of the `documentation
+in reStructured Text files in the top-level of the `documentation
 repository <https://github.com/mongodb/docs>`_. If you have any
 questions, please feel free to open a :issue:`Jira Case <DOCS>`.

source/administration/backups.txt

@@ -108,7 +108,7 @@ reliably, and typically provide the easiest backup systems method to
 implement.
 
 Snapshots work by creating pointers between the live data and a
-special snapshot volume: these pointers are theoretically equivelent
+special snapshot volume: these pointers are theoretically equivalent
 to "hard links." Then, as the working data diverges from the snapshot,
 the snapshot process uses a copy-on-write strategy. As a result the snapshot
 only stores modified data.
@@ -469,7 +469,7 @@ example:
 
 .. code-block:: sh
 
-   mongodump --host mongodb1.example.net --port 3017 --username user --password pass /opt/backup/mongodumpm-2011-10-24
+   mongodump --host mongodb1.example.net --port 3017 --username user --password pass /opt/backup/mongodump-2011-10-24
 
 On any :program:`mongodump` command you may, as above specify username
 and password credentials to specify database authentication.
@@ -495,7 +495,7 @@ the dump. Consider the following example:
 
 .. code-block:: sh
 
-   mongorestore --host mongodb1.example.net --port 3017 --username user --password pass /opt/backup/mongodumpm-2011-10-24
+   mongorestore --host mongodb1.example.net --port 3017 --username user --password pass /opt/backup/mongodump-2011-10-24
 
 On any :program:`mongorestore` command you may, as above specify
 username and password credentials as above.

source/administration/configuration.txt

@@ -15,7 +15,7 @@ While both interfaces provide access 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
 your operating system, you likely already have a configuration file
-located at ``/etc/mogondb.conf``. Confirm this by checking the content
+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 configuration file (see below.)

source/administration/monitoring.txt

@@ -428,7 +428,7 @@ Balancing and Chunk Distribution
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 The most effective :term:`shard clusters <shard cluster>` require that
-:term:`chunks <chunk>` are evenly balanaced between the shards. MongoDB
+:term:`chunks <chunk>` are evenly balanced between 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 :func:`db.printShardingStatus()` or :func:`sh.status()`

source/administration/replica-sets.txt

@@ -321,7 +321,7 @@ This operation sets the following:
 
    If your replica set has an even number members, add an
    :ref:`arbiter <replica-set-arbiters>` to ensure that
-   nodes wil be able to quickly obtain a majority of votes in an
+   nodes will be able to quickly obtain a majority of votes in an
    :ref:`election <replica-set-elections>` for primary.
 
 .. seealso:: ":data:`members[n].priority`" and ":ref:`Replica Set

source/administration/sharding.txt

@@ -396,7 +396,7 @@ The procedure to remove a shard is as follows:
 
    .. code-block:: javascript
 
-      { msg: "remove shard completed succesfully" , stage: "completed", host: "mongodb0", ok : 1 }
+      { msg: "remove shard completed successfully" , stage: "completed", host: "mongodb0", ok : 1 }
 
 Once the value of the ``stage`` field is "completed," you may safely
 stop the processes comprising the ``mongodb0`` shard.
@@ -516,7 +516,7 @@ To modify the chunk size, use the following procedure:
    To eliminate confusion you should *always* set chunk size using the
    above procedure and never use the runtime options.
 
-Modifying the chunk size has serveral limitations:
+Modifying the chunk size has several limitations:
 
 - Automatic splitting only occurs when inserting :term:`documents
   <document>` or updating existing documents.
@@ -668,7 +668,7 @@ be able to migrate chunks:
 
       use config
 
-#. Use an operation modeled on the folloiwng example :func:`update()
+#. Use an operation modeled on the following example :func:`update()
    <db.collection.update()>` operation to modify the balancer's
    window:
 

source/core/replication.txt

@@ -49,7 +49,7 @@ Member Configurations
 
 All replica sets at most use a single :term:`primary` member and one or
 more :term:`secondary` members. Replica sets allow you to configure
-secondary members in a variey of ways. This section describes uses and
+secondary members in a variety of ways. This section describes uses and
 functions of all the replica set member configurations.
 
 .. seealso:: ":ref:`Replica Set Node Configurations

source/core/sharding-internals.txt

@@ -102,7 +102,7 @@ key, all insert operations will be storing data into a single chunk, and
 therefore, a single shard. As a result, the write capacity of this shard
 will define the effective write capacity of the cluster.
 
-A shard key that increases monotonically will not hinder perforamnce
+A shard key that increases monotonically will not hinder performance
 if you have a very low insert rate, or if most of your write
 operations are :func:`update() <db.collection.update()>` operations
 distributed through your entire data set. Generally, choose shard keys
@@ -202,7 +202,7 @@ are:
 - to ensure that :program:`mongos` can isolate most queries to a specific
   :program:`mongod`.
 
-Furethermore:
+Furthermore:
 
 - Each shard should be a :term:`replica set`, if a specific
   :program:`mongod` instance fails, the replica set members will elect

source/faq/developers.txt

@@ -79,7 +79,7 @@ disk more frequently, so that the above values resents a theoretical
 maximum.
 
 However, by default, MongoDB uses a "lazy" strategy to write to
-disk. This is advantegous in situations where the database receives a
+disk. This is advantageous in situations where the database receives a
 thousand increments to an object within one second, MongoDB only needs
 to flush this data to disk once. In addition to the aforementioned
 configuration options, you can also use :dbcommand:`fsync` and
@@ -147,7 +147,7 @@ Why are MongoDB's data files so large?
 
 MongoDB aggressively preallocates data files to reserve space and
 avoid file system fragmentation. You can use the :setting:`smallfiles`
-flag to modify the file prealocation strategy.
+flag to modify the file preallocation strategy.
 
 .. seealso:: This wiki page that address :wiki:`MongoDB disk use <Excessive+Disk+Space>`.