@@ -17,22 +17,31 @@ Overview
17
17
18
18
For most deployments, a simple 3 node replica set provides a
19
19
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
24
30
additional complexity until your application requires the functionality.
25
31
32
+
33
+
26
34
Requirements
27
35
------------
28
36
29
37
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.
36
45
37
46
Procedure
38
47
---------
@@ -75,9 +84,10 @@ following options for more information: :option:`--port <mongod --port>`,
75
84
option. You will also need to specify the :option:`--bind_ip
76
85
<mongod --bind_ip>` option.
77
86
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: ::
81
91
82
92
mongo localhost:27017
83
93
@@ -104,8 +114,11 @@ replica set.
104
114
rs.add("localhost:27019")
105
115
106
116
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.
109
122
110
123
See the documentation of the following shell functions for more
111
124
information: :func:`rs.initiate()`, :func:`rs.conf()`,
0 commit comments