Permalink
Browse files

mongodb: editing and cross referencing and tweaking the replication s…

…ection.
  • Loading branch information...
1 parent 0d04b4d commit 6b614beafff7c3d1ba294edff777b4b30fb26088 @tychoish tychoish committed Dec 5, 2011
@@ -8,9 +8,11 @@ Administration
administration/backups
administration/import-export
administration/monitoring
- administration/replica-sets
administration/security
administration/configuration
administration/hardware-platform
administration/operating-systems
- administration/replication-architecture
+
+.. seealso:: For more information on administering :term:`replica sets
+ <replica set>`, see ":doc:`administration/replication-architecture`" and
+ ":doc:`administration/replica-sets`."
@@ -141,8 +141,8 @@ Snapshots have some limitations:
With Journaling
~~~~~~~~~~~~~~~
-If your system has a snapshot capability and ``mongod`` instance has
-journaling enabled then you can use any kind of file system or
+If your system has a snapshot capability and :option:`mongod` instance
+has journaling enabled then you can use any kind of file system or
volume/block level snapshot tool to create backups.
.. note::
@@ -2,13 +2,15 @@
Monitoring Database Systems
===========================
-Monitoring is a crucial component of all database administration
-work. A firm grasp of MongoDB's monitoring capabilities will enable
-you to effectively assess and maintain your deployment proactively,
-and also efficiently diagnose any issues that you encounter. This
-document provides an overview of the tools you may use for monitoring
-MongoDB, an introduction to diagnostic strategies, and suggestions for
-monitoring instances in MongoDB's replica sets and shard clusters.
+Monitoring is a critical component in all database administration
+work. A firm grasp of MongoDB's reporting approach allow you to
+effectively assess and maintain your deployment proactively.
+Additionally, a sense of MongoDB's and normal parameters will allow
+you to capably diagnose issues as you encounter them. This document
+provides an overview of the available tools and data provided by
+MongoDB as well as introduction to diagnostic strategies, and
+suggestions for monitoring instances in MongoDB's replica sets and
+shard clusters.
.. seealso::
@@ -37,12 +39,19 @@ monitoring instances in MongoDB's replica sets and shard clusters.
Monitoring Tools
----------------
-MongoDB provides a number of ways to collect data about the state and
-condition of a running MongoDB instance. Each method provides a
-different set of information, and is useful in a different
-context. This section provides an overview of these utilities and
-statistics, along with an example of the kinds of questions that each
-method is most suited to help you address.
+MongoDB provides two main methods and several operation for collecting
+that reflects the state and condition of a running MongoDB
+instance. First, there are a set of tools accessible from the system
+shell that provide real time reporting of activity on the
+database. Second, several :doc:`database commands
+</reference/commands>` return fine grained statistics about the
+current database state. Each method provides a data that answer a
+different set of questions, and are useful for monitoring different
+context kinds of activity.
+
+This section provides an overview of these utilities and statistics,
+along with an example of the kinds of questions that each method is
+most suited to help you address.
Utilities
~~~~~~~~~
@@ -55,7 +64,7 @@ current issues with the database.
mongotop
````````
-:command:`mongotop` tracks and reports the current read and write
+:option:`mongotop` tracks and reports the current read and write
activity of a MongoDB instance. ``mongotop`` provides per-collection
visibility into use. Use ``mongotop`` to verify that activity and use
match expectations.
@@ -6,21 +6,9 @@ these all address: how to deploy a specific replica set configuration,
and how to maintain it in the long run over time. Link to
":doc:`replication-architecture` for reasons.
-Node Types
+Procedures
----------
-Delayed Replication
-~~~~~~~~~~~~~~~~~~~
-
-Hidden Nodes
-~~~~~~~~~~~~
-
-Arbiter Nodes
-~~~~~~~~~~~~~
-
-Processes
----------
-
Adding Members
~~~~~~~~~~~~~~
@@ -41,3 +29,4 @@ Replication Lag
Failover and Recovery
~~~~~~~~~~~~~~~~~~~~~
+
@@ -15,9 +15,6 @@ documents.
The overall organization of this document will be topical/usecase
centered.
-Two Node Sets
--------------
-
Three Node Sets
---------------
@@ -0,0 +1,10 @@
+=========================================
+Application Development with Replica Sets
+=========================================
+
+-- connecting to replica sets,
+-- failing over on application
+-- read scaling
+-- setting read preference "slaveOk"
+-- write concern
+-- tagging
View
@@ -13,6 +13,8 @@ MongoDB Manual Contents
replication
+ administration
+
schema-design
optimization
@@ -22,9 +24,7 @@ MongoDB Manual Contents
core/journaling
core/capped-collections
- administration
-
- mongo-shell
+ mongo
reference
@@ -2,14 +2,46 @@
Replication Fundamentals
========================
+This document provides an overview of the core concepts that underpin
+MongoDB's replication functionality, known as ":term:`replica sets`."
+In these configurations, multiple :option:`mongod` run and maintain
+the same set of data in parallel. Having multiple copies of a database
+updated at the same time, adds redundancy, increases "read
+capacity," and increases the availability of a database in the case of
+issues with one or more nodes.
+
+.. seealso:: The ":doc:`/replication`" document for a list of all
+ documents in this resource that information on the operation and
+ use of MongoDB's replica sets.
+
Introduction
------------
+
+Fundamentally, MongoDB provides "master/slave," replication where one,
+"*master*," node accepts write operations while one or more "*slave*"
+nodes mirror or replicate all write operations and thus maintain
+data sets that are identical to the master. MongoDB's "replica set"
+functionality provides an additional convince, by allowing the
+
(how replication works)
Core Concepts
-------------
+Node Types
+~~~~~~~~~~
+
+Delayed Nodes
+```````
+
+Hidden Nodes
+````````````
+
+Arbiter Nodes
+~~~~~~~~~~~~~
+
+
Architecture
~~~~~~~~~~~~
(brief)
@@ -34,14 +66,9 @@ Security
.. seealso:: Link to notional section in /administration/security
on security and replica sets.
-Deploying Replica Sets
-----------------------
+Deployment Overview
+-------------------
This section needs a better title and will address:
- Should you deploy a replica set or not?
- When to add nodes to an existing replica set.
-
-Using Replicated MongoDB Instances
-----------------------------------
-- How drivers represent and handle replication
-- Special Behaviors
View
@@ -22,7 +22,7 @@ Major Topics
------------
.. toctree::
- :maxdepth: 2
+ :maxdepth: 3
replication
administration
@@ -41,6 +41,7 @@ User Guides
schema-design
optimization
+ mongo
- Tutorials
- Guides
@@ -80,7 +81,7 @@ MongoDB Shell
.. toctree::
:maxdepth: 3
- mongo-shell
+ mongo
Developing MongoDB
------------------
File renamed without changes.
@@ -2,15 +2,14 @@
Collection Statistics Reference
===============================
-.. default-domain: mongodb
.. highlight:: javascript
Synopsis
--------
MongoDB can report data reflecting the current state of the current
-collection. To dbstats ``run`` issue a command in the shell that
-resembles the following: ::
+collection. To fetch collection statistics, issue a command in the
+:option:`mongod` shell that resembles the following: ::
db.collection.stats()
db.runCommand( { collStats: "collection" } )
@@ -23,8 +22,8 @@ form: ::
db.collection.stats(1024)
db.runCommand( { collStats: "collection", scale: 1024 } )
-The above commands are equivalent. See :command:`colStats` for more
-information.
+The above commands are equivalent. See :mongodb:command:`colStats` for
+more information.
Fields
------
@@ -118,11 +118,53 @@ Sharding
.. describe:: removeshard
-TODO document removeshard
+ Controls the process of removing a shard from a :term:`shard
+ cluster`. This is a multi-stage process. Begin by issuing a command
+ in the following form: ::
+
+ { removeshard : "shardName" }
+
+ Where "``shardName``` refers to the name of the shard that you wish
+ to remove. The balancer will then begin migrating chunks from this
+ shard to other shards in the cluster. This process happens slowly,
+ to avoid placing unrequited load on a production cluster, and
+ requires that the balancer be enabled. The command returns
+ immediately, with the following message: ::
+
+ { msg : "draining started successfully" , state: "started" , shard: "shardName" , ok : 1 }
+
+ If you run the command again, you will see the following progress
+ output: ::
+
+ { msg: "draining ongoing" ,  state: "ongoing" , remaining: { chunks: 23 , dbs: 1 }, ok: 1 }
+
+ The ``remaining`` :term:`document <JSON document>`" specifies how
+ many chunks and databases remain on the shard. Use
+ :mongodb:command:`printShardingStatus` to list the databases that
+ must moved from the shard.
+
+ Database must be moved manually using the
+ :mongodb:command:`moveprary`.
+
+ Once all chunks and databases have been removed from the shard, you
+ may issue the command again, to return: ::
+
+ { msg: "remove shard completed successfully , stage: "completed", host: "shardName", ok : 1 }
.. describe:: moveprimary
-TODO document moveprimary
+ In a :term:`shard cluster`, this command moves the primary database
+ to a specified shard. The command takes the following form: ::
+
+ { moveprimary : "test", to : "shard0001" }
+
+ When the command returns the database's primary location has
+ shifted to the designated :term:`shard`. To fully decomission a
+ shard, return to the :mongodb:command:`removeshard`.
+
+ .. warning:: Do not use :mongodb:command:`moveprimary` if you have
+ sharded collections and the :term:`draining` process has not
+ completed.
Aggregation
~~~~~~~~~~~
@@ -423,8 +465,10 @@ Replication
should always perform these operations during scheduled
maintenance periods.
- - In some situations, a ``replSetReconfig`` can cause the current
- shell to disconnect. Do not be alarmed.
+ - In some cases, ``replSetReconfig`` forces the current primary to
+ step down and forces an election for primary among the members of
+ the replica set. When this happens the set will drop all current
+ collections.
.. slave-ok, admin-only
@@ -442,6 +486,10 @@ Replication
``<seconds>``, ``replSetStepDown`` will attempt to avoid reelection
to primary for 60 seconds.
+ .. warning:: This will force all clients currently connected to the
+ database to disconnect, while the set elects a new primary
+ node.
+
.. slave-ok, admin-only
Geolocation
@@ -920,21 +968,23 @@ Administration
The ``copydb`` command copies a database from another host to the
current host. This provides similar functionality to
:command:`clone`, but provides additional flexibility. The command
- takes the following syntax: ::
+ uses the following syntax: ::
{ copydb: 1:
fromhost: <hostname>,
fromdb: <db>,
todb: <db>,
slaveOk: <bool>,
username: <username>,
+ password: <password>,
nonce: <nonce>,
key: <key> }
The following arguments are optional:
- slaveOK
- username
+ - password
- nonce
- key
@@ -953,8 +1003,6 @@ Administration
``copydb`` operation, and ``copydb`` will occasionally yield to
other operations.
-TODO is the password an option here?
-
.. describe:: logout
The ``logout`` command forces the current session to end the
Oops, something went wrong.

0 comments on commit 6b614be

Please sign in to comment.