Databases Reference
In-Depth Information
Make sure that you do not change
rs4
's
_id
to 2. This will confuse the replica set. If
you are adding new nodes to the set, use JavaScript's
push
function to add elements
with
_id
s 4, 5, etc. If you are both adding and removing nodes, you can dive into the
confusion that is the JavaScript
splice
function (or you can just use
push
and
slice
).
Now increment the version number (
config.version
). This tells the other servers that
this is the new configuration and they should update themselves accordingly.
Now triple-check over your config document.
If you mess up the config, you can com-
pletely hose your replica set configuration.
To be clear: nothing bad will happen to your
data, but you may have to shut everything down and blow away the
local
database on
all of the servers. So make sure this config references the correct servers, no one's
_id
has changed out from under them, and you haven't made any non-arbiters arbiters or
visa versa.
Once you're absolutely, completely sure that this is the configuration that you want,
shut down the server. Then, restart it with its usual options (
--replSet
and its standard
port). In a few seconds, the other member(s) will connect to it, update their configu-
ration, and elect a new master.
Further reading:
•
Using
slice
•
Using
push
•
Possible replica set options
Tip #43: --shardsvr and --configsvr aren't required
The documentation seems to imply that these are required when you set up sharding,
but they are not. Basically, they just change the port (which can seriously mess up an
existing replica set):
--shardsvr
changes the port to 27018 and
--configsvr
changes it
to 27019. If you are setting up multiple servers across multiple machines, this is to help
you connect the right things together: all
mongos
processes on 27017, all shards on
27018, all config servers on 27019. This setup does make everything a lot easier to keep
track of if you're building a cluster from scratch, but don't worry too much about it if
you have an existing replica set that you're turning into a shard.
--configsvr
not only changes the default port but turns on the
diaglog
, a log that keeps
every action the config database performs in a replayable format, just in case. If you're
using version 1.6, you should use
--port
27019 and
--diaglog
, as
--configsvr
only
turns on the diaglog in 1.6.5+. If you're using 1.8, use
--port
27019 and
--journal
(instead of
--diaglog
). Journaling gives you much the same effect as the diaglog with
less of a performance hit.
