自我学习，仅供参考：

数据库总是会遇到各种失败的场景，如网络连接断开、断电等，尽管journaling日志功能也提供了数据恢复的功能，但journaling通常是针对单个节点来说的，只能保证单节点数据的一致性，而复制集通常是由多个节点组成，每个节点除了journaling日志恢复功能外，整个复制集还具有故障自动转移的功能，这样能保证数据库的高可用性。在生产环境中一个复制集最少应该包含三个节点，其中有一个必须是主节点，典型的部署结构如下图：

其中每个节点都是一个mongod进程对应的实例，节点之间互相周期性的通过心跳检查对方的状态，默认情况下primary节点负责数据的读、写，second节点备份primary节点上的数据（如何备份？下面会分析），但是arbiter节点不会从primary节点同步数据，从它的名字arbiter可以看出，它起到的作用只是当primary节点故障时，能够参与到复制集剩下的节点中，选择出一个新的primary节点，它自己永远不会变为primary节点，也不会参与数据的读写。也就是说，数据库的数据会存在primary和second节点中，second节点相当于一个备份，当然second节点可以有多个，当primary节点故障时，second节点有可能变为primary节点。上图是一个生产环境所需的最少节点数，下面就配置一个这样的复制集。

（1）创建复制集中每个节点存放数据的目录

E:\mongodb-win32-i386-2.4.3\db_rs0\data\rs0_0

E:\mongodb-win32-i386-2.4.3\db_rs0\data\rs0_1

E:\mongodb-win32-i386-2.4.3\db_rs0\data\rs0_2

（2）创建复制集中每个节点的日志文件

E:\mongodb-win32-i386-2.4.3\db_rs0\logs\rs0_0.log

E:\mongodb-win32-i386-2.4.3\db_rs0\logs\rs0_1.log

E:\mongodb-win32-i386-2.4.3\db_rs0\logs\rs0_2.log

（3）为复制集中的每个节点创建启动时所需的配置文件

第一个节点配置文件为：E:\mongodb-win32-i386-2.4.3\configs_rs0\rs0_0.conf 内容如下：

dbpath = E:\mongodb-win32-i386-2.4.3\db_rs0\data\rs0_0

logpath = E:\mongodb-win32-i386-2.4.3\db_rs0\logs\rs0_0.log

journal = true

port = 40000

replSet = rs0

其中dbpath指向数据库数据文件存放的路径（在第一步中已创建好），logpath指向数据库的日志文件路径（第二步中已创建好），journal表示对于此mongod实例是否启动日志功能，port为实例监听的端口号，rs0为实例所在的复制集名称，更多参数的意思可以参考mongoDB手册。

第二个节点配置文件为：E:\mongodb-win32-i386-2.4.3\configs_rs0\rs0_1.conf 内容如下：

dbpath = E:\mongodb-win32-i386-2.4.3\db_rs0\data\rs0_1

logpath = E:\mongodb-win32-i386-2.4.3\db_rs0\logs\rs0_1.log

journal = true

port = 40001

replSet = rs0

第三个节点配置文件为：E:\mongodb-win32-i386-2.4.3\configs_rs0\rs0_2.conf 内容如下：

dbpath = E:\mongodb-win32-i386-2.4.3\db_rs0\data\rs0_2

logpath = E:\mongodb-win32-i386-2.4.3\db_rs0\logs\rs0_2.log

journal = true

port = 40002

replSet = rs0

（4）启动上面三个节点对应的mongoDB实例

mongod –config  E:\mongodb-win32-i386-2.4.3\configs_rs0\rs0_0.conf

mongod –config  E:\mongodb-win32-i386-2.4.3\configs_rs0\rs0_1.conf

mongod –config  E:\mongodb-win32-i386-2.4.3\configs_rs0\rs0_2.conf

观察一下每个实例的启动日志，日志中都有如下内容：

[rsStart] replSet can't get local.system.replset config from self or any seed (EMPTYCONFIG)

[rsStart] replSet info you may need to run replSetInitiate -- rs.initiate() in the shell -- if that is not already done

上面日志说明虽然已经成功启动了三个实例，但是复制集还没配置好，复制集的信息会保存在每个mongod实例上的local数据库中即local.system.replset上。按照上图所描述那样，你应该通过配置确定哪个节点为primary、哪个为second、哪个为arbiter。下面开始配置复制集。

（5）启动一个mongo客户端，连接到上面的一个mongod实例

>mongo --port 40000

运行以下命令初始化复制集

> rs.initiate()

{

"info2" : "no configuration explicitly specified -- making one",

"me" : "Guo:40000",

"info" : "Config now saved locally.  Should come online in about a min e.",

"ok" : 1

}

这个时候的复制集还只有刚才这个初始化的成员，通过如下命令查看到。

> rs.conf()

{

"_id" : "rs0",

"version" : 1,

"members" : [

{

"_id" : 0,

"host" : "Guo:40000"

}

]

}

按照mongoDB的默认设置，刚才执行初始化命令的这个mongod实例将成为复制集中的primary节点。

（6）接下来在复制集中添加上图中的second节点和arbiter节点，继续在上面那个mongod实例上执行如下命令：

rs0:PRIMARY> rs.add("Guo:40001")

{ "ok" : 1 }

rs0:PRIMARY> rs.addArb("Guo:40002")

{ "ok" : 1 }

注意此时命令的前缀变为了：rs0:PRIMARY，说明当前执行命令的机器是复制集中primary机器，上面的命令通过rs.add()添加一个默认的second节点，rs.addArb()添加一个默认的arbiter节点。命令成功执行后，就会生成上图所示那样的一个复制集。

（7）观察整个复制集的状态信息，几个重要参数会在后面说明。

rs0:PRIMARY> rs.status()

{

"set" : "rs0",//复制集的名称

"date" : ISODate("2013-08-18T09:03:49Z"),

"myState" : 1, //当前节点成员在复制集中的位置，如1表示primary，2表示secondry

"members" : [//复制集的所有成员信息

{

"_id" : 0, //成员编号

"name" : "Guo:40000",//成员所在的服务器名称

"health" : 1,//成员在复制集中是否运行，1表示运行，0失败

"state" : 1,//成员在复制集中的状态，1是primary

"stateStr" : "PRIMARY",//成员在复制集中的状态名称

"uptime" : 2186,//成员的在线时间，单位是秒

"optime" : {//这个是用来进行同步用的，后面重点分析

"t" : 1376816431,

"i" : 1

},

"optimeDate" : ISODate("2013-08-18T09:00:31Z"),

"self" : true //成员为当前命令所在的服务器

},

{

"_id" : 1,

"name" : "Guo:40001",

"health" : 1, ,//成员在复制集中是否运行，1表示运行

"state" : 2 ,//成员在复制集中的状态，2是secondary

"stateStr" : "SECONDARY",

"uptime" : 306,

"optime" : {

"t" : 1376816431,

"i" : 1

},

"optimeDate" : ISODate("2013-08-18T09:00:31Z"),

"lastHeartbeat" : ISODate("2013-08-18T09:03:47Z"),

"lastHeartbeatRecv" : ISODate("2013-08-18T09:03:47Z"),

"pingMs" : 0,//此远端成员到本实例间一个路由包的来回时间

"syncingTo" : "Guo:40000"//此成员需要从哪个实例同步数据

},

{

"_id" : 2,

"name" : "Guo:40002",

"health" : 1,

"state" : 7, //成员在复制集中的状态位置，7是arbiter

"stateStr" : "ARBITER",

"uptime" : 198,

"lastHeartbeat" : ISODate("2013-08-18T09:03:49Z"),

"lastHeartbeatRecv" : ISODate("1970-01-01T00:00:00Z"),

"pingMs" : 0,//此远端成员到本实例间一个路由包的来回时间

}

],

"ok" : 1

}

上面复制集状态信息的输出是基于primary实例的，也可以再secondary实例上输出复制集的状态信息，包含的字段与上面大致相同。上面的输出有些地方还需进一步解释，如在arbiter成员节点上，没有字段syncingTo，说明他不需要从primary节点上同步数据，因为它只是一个当主节点发生故障时，在复制集中剩下的secondary节点中选择一个新的priamry节点的仲裁者，因此运行此实例的机器不需要太多的存储空间。

上面输出的字段中还有几个时间相关的字段如："date"表示当前实例所在服务器的时间，"lastHeartbeat"表示当前实例到此远端成员最近一次成功发送与接收心跳包的时间，通过比较这个两个时间可以判断当前实例与此成员相差的时间间隔，比如某个成员宕机了，本实例发像此宕机成员的心跳包就不会被成功接收，随着时间推移，本实例的data字段值与此成员上的lastHeartbeat差值就会逐渐增加。

上面还有一个optime字段，这个字段的值说明了本实例最近一次更改数据库的时间"t" : 1376816431以及每秒执行的操作数据库的次数"i" : 1，此字段的值实际上是从本实例上的local数据库中的oplog.rs集合上读取的，这个集合还详细记录了具体是什么操作，如插入语句、修改语句等。复制集中的每一个实例都会有一个这样的数据库和集合，如果复制集运行正常，理论上来说，每一个mongod实例上此集合中的记录应该相同。实际上mongoDB也是根据此集合来实现复制集中primary节点与secondary节点间的数据同步。