Skip to content

Commit 74fb250

Browse files
committed
fixes to the dev replset tutorial
1 parent 245e8c9 commit 74fb250

File tree

1 file changed

+28
-15
lines changed

1 file changed

+28
-15
lines changed

source/tutorial/deploy-replica-set.txt

Lines changed: 28 additions & 15 deletions
Original file line numberDiff line numberDiff line change
@@ -17,22 +17,31 @@ Overview
1717

1818
For most deployments, a simple 3 node replica set provides a
1919
sufficient redundancy to survive most network partitions and other
20-
system failures. A replica set of this size provides sufficient
21-
capacity to host many distributed read operations. While MongoDB's
22-
replica set functionality provides a great deal of flexibility and
23-
specific definable node behaviors or types, it's best to avoid this
20+
system failures. A replica set of this also size provides sufficient
21+
capacity to host many distributed read operations.
22+
23+
.. Whoa, Whoa, Whoa... Is 10gen really recommending against redundancy?
24+
.. As a SysAd, I personally disagree with this notion; what I typically
25+
.. recommend is absolutely to implement a basic ReplSet in Prod, but not
26+
.. get into Sharding unless you find that it's really necessary.
27+
28+
While MongoDB's replica set functionality provides a great deal of flexibility
29+
and specific definable node behaviors or types, it's best to avoid this
2430
additional complexity until your application requires the functionality.
2531

32+
33+
2634
Requirements
2735
------------
2836

2937
Three distinct systems, so that each system can run its own instance
30-
of :program:`mongod`. For test systems you can run all three instances
31-
of the :program:`mongod` process on a local system. e.g. a laptop) or
32-
within a virtual instance. For production environments, you should
33-
endeavor to maintain as much separation between the nodes: Deploy
34-
replica set members on distinct hardware, and on systems that draw
35-
power from different circuits, to the greatest extent possible.
38+
of :program:`mongod`. For development systems you may run all three
39+
instances of the :program:`mongod` process on a local system. (e.g. a
40+
laptop) or within a virtual instance. For production environments, you
41+
should endeavor to maintain as much separation between the nodes. For
42+
instance: Deploy replica set members on distinct hardware, and on
43+
systems that draw power from different circuits, to the greatest extent
44+
possible.
3645

3746
Procedure
3847
---------
@@ -75,9 +84,10 @@ following options for more information: :option:`--port <mongod --port>`,
7584
option. You will also need to specify the :option:`--bind_ip
7685
<mongod --bind_ip>` option.
7786

78-
Log in with the :program:`mongo` shell to the first host. If you're
79-
accessing this command remotely, modify the hostname. using the
80-
following command: ::
87+
Connect to the mongod instance with the :program:`mongo` shell to the
88+
first host. If you're accessing this command remotely, replace
89+
"localhost" with the approriate hostname. Open a new terminal session
90+
and enter the following: ::
8191

8292
mongo localhost:27017
8393

@@ -104,8 +114,11 @@ replica set.
104114
rs.add("localhost:27019")
105115

106116
Congratulations, after these commands return you will have a fully
107-
functional replica set. You may have to wait several moments for the
108-
new replica set to successfully elect a :term:`primary` node.
117+
functional replica set. Within a couple moments the new replica set
118+
should successfully elect a :term:`primary` node.
119+
120+
At any time, you may check the status of your replica set with the
121+
:func:`rs.status()` command.
109122

110123
See the documentation of the following shell functions for more
111124
information: :func:`rs.initiate()`, :func:`rs.conf()`,

0 commit comments

Comments
 (0)