mongoDB研究笔记：复制集概述

花花世界蕾

　　自我学习，仅供参考：
　　数据库总是会遇到各种失败的场景，如网络连接断开、断电等，尽管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节点间的数据同步。