MongoDB实战指南(六)：MongoDB复制集之复制集概述
1. 复制集概述
数据库总是会遇到各种失败的场景，如网络连接断开、断电等，尽管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节点间的数据同步。
