Upgrade MongoDB from single node to Master-Slave

MongoDB的replication有两种方式，一种是Master-Slave；另外一个就是Replica-Set；

MongoDB supports asynchronous replication of data between servers for failover and redundancy. Only one server (in the set/shard) is active for writes (the primary, or master) at a given time. With a single active master at any point in time, strong consistency
semantics are available. One can optionally send read operations to the slaves/secondaries when eventual consistency semantics are acceptable.

个人推荐使用Replica-Set，因为Replica-Set更加灵活，特别是当Replica-Set的primary节点挂了的时候，会自动从剩下的secondary节点中选举出新的primary节点，但是Master-Slave模式的MongoDB，当Master挂了以后Slave节点不会自动成为Master的。但是Master-Slave模式的MongoDB在某些情况下还是很有用的，比如当你需要将一个节点的数据同步到另外一个节点上面去（因为Replica-Set至少需要3个节点，或者至少第三个节点只参与选举，而不存储数据）。

下面走一下从single node升级为Master-Slave模式的MongoDB来完成数据同步：

（MongoDB官网上有更详细的介绍：http://www.mongodb.org/display/DOCS/Master+Slave）

1）开始的时候只有一个MongoDB节点，存储一些数据进去：

USER@ubuntu:~/data/masterdb$ pwd
/home/USER/data/masterdb

USER@ubuntu:~/data/masterdb$ mongod --dbpath /home/USER/data/masterdb/data --logpath /home/USER/data/masterdb/logs/shard.log --port 3000 --fork
forked process: 2491
all output going to: /home/USER/data/masterdb/logs/shard.log

USER@ubuntu:~/data/masterdb$ mongo localhost:3000
MongoDB shell version: 1.8.2
connecting to: localhost:3000/test
> db.city_info.save({id:1,name:'beijing'})
> db.city_info.save({id:2,name:'shanghai'})
> db.city_info.save({id:2,name:'hangzhou'})
> db.city_info.find()
{ "_id" : ObjectId("4e3d0776c8a94fbd9bb4d8cb"), "id" : 1, "name" : "beijing" }
{ "_id" : ObjectId("4e3d077ec8a94fbd9bb4d8cc"), "id" : 2, "name" : "shanghai" }
{ "_id" : ObjectId("4e3d0782c8a94fbd9bb4d8cd"), "id" : 3, "name" : "hangzhou" }

2）如果要将single node升级为Master-Slave模式的MongoDB还是需要使用--master来启动MongoDB的，所以需要先将单点的MongoDB kill掉（千万不要用kill -9啊！不然你重启就要面对漫长的repairDatabase命令），然后重新用--master来启动

USER@ubuntu:~/data/masterdb$ mongod --master --dbpath /home/USER/data/masterdb/data --logpath /home/USER/data/masterdb/logs/shard.log --port 3000 --fork
forked process: 2511
all output going to: /home/USER/data/masterdb/logs/shard.log

3）查看一下上面存储的数据，一切都OK!

USER@ubuntu:~/data/masterdb$ mongo localhost:3000
MongoDB shell version: 1.8.2
connecting to: localhost:3000/test
> show collections
system.indexes
city_info
> db.city_info.find()
{ "_id" : ObjectId("4e3d0776c8a94fbd9bb4d8cb"), "id" : 1, "name" : "beijing" }
{ "_id" : ObjectId("4e3d077ec8a94fbd9bb4d8cc"), "id" : 2, "name" : "shanghai" }
{ "_id" : ObjectId("4e3d0782c8a94fbd9bb4d8cd"), "id" : 3, "name" : "hangzhou" }
> exit
bye

4）接下来就是启动slave节点了，然后查看一下数据是否已经同步过来了，我们这里只有一丁点数据，所以很快，如果数据量很大应该需要更长的时间。

USER@ubuntu:~/data/slavedb$ mongod --slave --source localhost:3000 --dbpath /home/USER/data/slavedb/data --logpath /home/USER/data/slavedb/logs/shard.log --port 3001 --fork --autoresync
forked process: 2528
all output going to: /home/USER/data/slavedb/logs/shard.log

USER@ubuntu:~/data/masterdb$ mongo localhost:3001
MongoDB shell version: 1.8.2
connecting to: localhost:3001/test
> show collections
system.indexes
city_info
> db.city_info.find()
{ "_id" : ObjectId("4e3d0776c8a94fbd9bb4d8cb"), "id" : 1, "name" : "beijing" }
{ "_id" : ObjectId("4e3d077ec8a94fbd9bb4d8cc"), "id" : 2, "name" : "shanghai" }
{ "_id" : ObjectId("4e3d0782c8a94fbd9bb4d8cd"), "id" : 3, "name" : "hangzhou" }
> exit
bye

5）查看一下server的状态

USER@ubuntu:~/data/masterdb$ mongo localhost:3000
MongoDB shell version: 1.8.2
connecting to: localhost:3000/test
> db.printReplicationInfo()
configured oplog size:   47.6837158203125MB
log length start to end: 524secs (0.15hrs)
oplog first event time:  Sat Aug 06 2011 17:25:35 GMT+0800 (CST)
oplog last event time:   Sat Aug 06 2011 17:34:19 GMT+0800 (CST)
now:                     Sat Aug 06 2011 17:34:21 GMT+0800 (CST)
> exit
bye
USER@ubuntu:~/data/slavedb$ mongo localhost:3001
MongoDB shell version: 1.8.2
connecting to: localhost:3001/test
> db.printSlaveReplicationInfo()
source:   localhost:3000
syncedTo: Sat Aug 06 2011 17:34:49 GMT+0800 (CST)
= 5secs ago (0hrs)
> exit
bye

6）更多有意思的东西直接看英文吧！

Administrative Tasks

Failing over to a Slave (Promotion)

To permanently fail over from a down master (A) to a slave (B):

shut down A

stop mongod on B

backup or delete local.* datafiles on B

restart mongod on B with the --master option

Note that is a one time cutover and the "mirror" is broken. A cannot be brought back in sync with B without a full resync.

Inverting Master and Slave

If you have a master (A) and a slave (B) and you would like to reverse their roles, this is the recommended sequence of steps. Note the following assumes A is healthy, up-to-date and up.

Halt writes on A (using the fsync command)

Make sure B is caught up

Shut down B

Wipe local.* on B to remove old local.sources

Start up B with the --master option

Do a write on B (primes the oplog to provide a new sync start point).

Shut down B. B will now have a new set of local.* files.

Shut down A and replace A's local.* files with a copy of B's new local.* files. Remember to compress the files before/while copying them – they can be quite large.

Start B with the --master option

Start A with all the usual slave options plus --fastsync

If A is not healthy but the hardware is okay (power outage, server crash, etc.):

Skip the first two steps

Replace all of A's files with B's files in step 8.

If the hardware is not okay, replace A with a new machine and then follow the instructions in the previous paragraph.

Creating a slave from an existing master's disk image

--fastsync is a way to start a slave starting with an existing master disk image/backup. This option declares that the adminstrator guarantees the image is correct and completely up to date with that of the master. If you have a full and complete copy of data
from a master you can use this option to avoid a full synchronization upon starting the slave.

Creating a slave from an existing slave's disk image

You can just copy the other slave's data file snapshot without any special options. Note data snapshots should only be taken when a mongod process is down or in fsync-and-lock state.

Resyncing a slave that is too stale to recover

Slaves asynchronously apply write operations from the master. These operations are stored in the master's oplog. The oplog is finite in length. If a slave is too far behind, a full resync will be necessary. See the Halted Replication page.

Slave chaining

Slaves cannot be "chained", they must all connect to the master directly. If a slave is chained to another slave you may see the following in the logs: assertion 13051 tailable cursor requested on non capped collection ns:local.oplog.$main

Correcting a slave's source

If you accidentally type the wrong host for the slave's source or wish to change it, you can do so by manually modifying the slave's local.sources collection. For example, say you start the slave with:

$ mongod --slave --source prod.missisippi

Restart the slave without the --slave and --source arguments.

$ mongod

Now start the shell and update the local.sources collection.

> use local

switched to db local

> db.sources.update({host : "prod.missisippi"}, {$set : {host : "prod.mississippi"}})

Restart the slave with the correct command line arguments or no --source argument (once local.sources is set, no --source is necessary).

$ ./mongod --slave --source prod.mississippi

$ # or

$ ./mongod --slave

Now your slave will be pointing at the correct master.