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节点间的数据同步。

上一篇:Java:xxx is not an enclosing class


下一篇:(转) 解决ssh的"Write failed: Broken pipe"问题