MongoDB 3.2复制集单节点部署（四）

MongoDB在单节点中也可以做复制集，但是仅限于测试实验，最大的好处就是部署方便快速，可以随便添加新节点，节省资源。在这里我使用的是MongoDB 3.2版本进行复制集实验（但MongoDB配置文件使用的是老版本格式），一共使用三个节点，一个是主节点（PRIMARY），一个是从节点（SECONDARY），一个是投票节点（ARBITER）。如下图：

一、实验环境

1）节点信息:192.168.60.10

3）节点确保iptables和selinux已关闭

1

2

[root@node1 ~]# iptables -F

[root@node1 ~]# setenforce 0

二、安装MongoDB 3.2

1

2

3

4

5

mongodb-org-3.2.0-1.el6.x86_64.rpm

mongodb-org-mongos-3.2.0-1.el6.x86_64.rpm

mongodb-org-server-3.2.0-1.el6.x86_64.rpm

mongodb-org-shell-3.2.0-1.el6.x86_64.rpm

mongodb-org-tools-3.2.0-1.el6.x86_64.rpm

PS：需要的软件包可以去https://repo.mongodb.org/yum/redhat/下载，MongoDB的安装很简单，怎么安装都成。

三、配置单点复制集（启动三个套接字）

1）创建所需要的目录

1

2

3

4

5

6

$ mkdir -p /data/mongodb/{conf,log,pid,data}

$ mkdir -p /data/mongodb/conf/{conf27017,conf27018,conf27019}

$ mkdir -p /data/mongodb/log/{log27017,log27018,log27019}

$ mkdir -p /data/mongodb/pid/{pid27017,pid27018,pid27019}

$ mkdir -p /data/mongodb/data/{data27017,data27018,data27019}

$ chown -R mongod.mongod /data/mongodb/data/{data27017,data27018,data27019}

2）创建三个配置文件

192.168.60.10:27017

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

$ cat /data/mongodb/conf/conf27017/mongod.conf

# 开启日志文件;

logpath = /data/mongodb/log/log27017/mongod.log

# 开启日志追加;

logappend = true

# 指定数据目录;

dbpath = /data/mongodb/data/data27017

# 实例端口;

port = 27017

# 绑定地址;

bind_ip = 0.0.0.0

# 守护进程模式开启;

fork = true

# 进程号文件;

pidfilepath = /data/mongodb/pid/pid27017/mongod.pid

# 日志回转;

logRotate = rename

# 日志时间格式;

timeStampFormat = ctime

# 日志刷盘间隔（默认100毫秒）;

journalCommitInterval = 100

# 数据刷盘间隔（默认60秒）;

syncdelay = 60

# 最大连接数（默认65536）;

maxConns = 65536

###Replica Set

# Oplog大小（单位MB）;

oplogSize = 1024

# 复制集名称;

replSet = ywnds

192.168.60.10:27018

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

$ cat /data/mongodb/conf/conf27018/mongod.conf

logpath = /data/mongodb/log/log27018/mongod.log

logappend = true

dbpath = /data/mongodb/data/data27018

port = 27018

bind_ip = 0.0.0.0

fork = true

pidfilepath = /data/mongodb/pid/pid27018/mongod.pid

logRotate = rename

timeStampFormat = ctime

journalCommitInterval = 100

syncdelay = 60

maxConns = 65536

###Replica Set

oplogSize = 1024

replSet = ywnds

192.168.60.10:27019

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

$ cat /data/mongodb/conf/conf27019/mongod.conf

logpath = /data/mongodb/log/log27019/mongod.log

logappend = true

dbpath = /data/mongodb/data/data27019

port = 27019

bind_ip = 0.0.0.0

fork = true

pidfilepath = /data/mongodb/pid/pid27019/mongod.pid

logRotate = rename

timeStampFormat = ctime

journalCommitInterval = 100

syncdelay = 60

maxConns = 65536

###Replica Set

oplogSize = 1024

replSet = ywnds

PS:更多具体参数详细含义请看《MongoDB命令行选项介绍》

3）启动集群（所有节点）

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

$ killall mongod

$ mongod -f /data/mongodb/conf/conf27019/mongod.conf

about to fork child process, waiting until server is ready for connections.

forked process: 35554

child process started successfully, parent exiting

$ mongod -f /data/mongodb/conf/conf27018/mongod.conf

about to fork child process, waiting until server is ready for connections.

forked process: 35601

child process started successfully, parent exiting

$ mongod -f /data/mongodb/conf/conf27017/mongod.conf

about to fork child process, waiting until server is ready for connections.

forked process: 35648

child process started successfully, parent exiting

查看进程三个节点都启动

1

2

3

4

$ netstat -anplt | grep mongod

tcp        0      0 0.0.0.0:27019         0.0.0.0:*                   LISTEN      35554/mongod

tcp        0      0 0.0.0.0:27017         0.0.0.0:*                   LISTEN      35648/mongod

tcp        0      0 0.0.0.0:27018         0.0.0.0:*                   LISTEN      35601/mongod

4）选择一个节点做主节点（可以随意选择一个，这里我使用21017）

1

2

3

4

$ mongo 192.168.60.10:27017/admin

MongoDB shell version: 3.2.0

connecting to: 192.168.60.10:27017/admin

>

5）初始化27017节点

5.1.为复制集初始化建立配置文档

1

2

3

4

5

6

7

> config = {

_id:"ywnds",

members:[

{_id:0,host:"192.168.60.10:27017"},

{_id:1,host:"192.168.60.10:27018"},

{_id:2,host:"192.168.60.10:27019"}

]}

5.2.更新配置文档参数，设置27019为arbiterOnly（投票节点）

1

> config.members[2] = {"_id":2,"host":"192.168.60.10:27019","arbiterOnly":true}

PS：上面是把复制集初始化配置文档赋值给config变量，这里是通过membes数组的索引来修改节点属性，数组索引从0开始。

具体的配置文档说明请看《MongoDB复制集配置文档介绍》

5.3.使用rs.initiate(cfg)初始化集群

1

2

3

4

5

> rs.initiate(config)

{

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

"ok" : 1

}

这里使用rs.initiate(config)初始化集群，config文件为我们上面定义的。这里的ok返回值为1表示命令执行成功，如果为0则表示没有执行成功。跟Linux中的状态值刚好相反。现在可以使用rs.conf()方法返回配置文件内容。

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

ywnds:PRIMARY> rs.conf()

{

"_id" : "ywnds",

"version" : 2,

"protocolVersion" : NumberLong(1),

"members" : [

{

"_id" : 0,

"host" : "192.168.60.10:27017",

"arbiterOnly" : false,

"buildIndexes" : true,

"hidden" : false,

"priority" : 1,

"tags" : {

},

"slaveDelay" : NumberLong(0),

"votes" : 1

},

{

"_id" : 1,

"host" : "192.168.60.10:27018",

"arbiterOnly" : false,

"buildIndexes" : true,

"hidden" : false,

"priority" : 1,

"tags" : {

},

"slaveDelay" : NumberLong(0),

"votes" : 1

},

{

"_id" : 2,

"host" : "192.168.60.10:27019",

"arbiterOnly" : true,

"buildIndexes" : true,

"hidden" : false,

"priority" : 1,

"tags" : {

},

"slaveDelay" : NumberLong(0),

"votes" : 1

}

],

"settings" : {

"chainingAllowed" : true,

"heartbeatIntervalMillis" : 2000,

"heartbeatTimeoutSecs" : 10,

"electionTimeoutMillis" : 10000,

"getLastErrorModes" : {

},

"getLastErrorDefaults" : {

"w" : 1,

"wtimeout" : 0

}

}

}

在Mongodb3.2版本中，相比之前的版本rs.conf返回配置文件的信息更加详细了。把”arbiterOnly”、”buildIndexes”、”hidden”、”priority”、”tags”、”slaveDelay”、”votes”的默认值都给真是出来了，具体的含义看《MongoDB复制集配置文档介绍》。

5.4.查看集群状态

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

ywnds:PRIMARY> rs.status()

{

"set" : "ywnds",

"date" : ISODate("2016-02-03T01:56:49Z"),

"myState" : 1,

"members" : [

{

"_id" : 0,

"name" : "192.168.60.10:27017",

"health" : 1,

"state" : 1,

"stateStr" : "PRIMARY",

"uptime" : 1043,

"optime" : Timestamp(1454464583, 1),

"optimeDate" : ISODate("2016-02-03T01:56:23Z"),

"electionTime" : Timestamp(1454464592, 1),

"electionDate" : ISODate("2016-02-03T01:56:32Z"),

"self" : true

},

{

"_id" : 1,

"name" : "192.168.60.10:27018",

"health" : 1,

"state" : 2,

"stateStr" : "SECONDARY",

"uptime" : 25,

"optime" : Timestamp(1454464583, 1),

"optimeDate" : ISODate("2016-02-03T01:56:23Z"),

"lastHeartbeat" : ISODate("2016-02-03T01:56:48Z"),

"lastHeartbeatRecv" : ISODate("2016-02-03T01:56:47Z"),

"pingMs" : 2,

"syncingTo" : "192.168.60.10:27017"

},

{

"_id" : 2,

"name" : "192.168.60.10:27019",

"health" : 1,

"state" : 7,

"stateStr" : "ARBITER",

"uptime" : 25,

"lastHeartbeat" : ISODate("2016-02-03T01:56:48Z"),

"lastHeartbeatRecv" : ISODate("2016-02-03T01:56:47Z"),

"pingMs" : 0

}

],

"ok" : 1

}

我们的集群中有三个节点，由状态返回值可以看出27017为PRIMARY节点，而27018为SECONDARY节点，而27019为我们设置的ARBITER节点。这里我们发现mongodb的角标已经变了，变成了复制集名称加上当前节点的状态。同样如果登陆27018和27019会发现都发生了变化。

5.5.查看主节点local库

1

2

3

4

5

6

7

8

9

10

ywnds:PRIMARY> use local

switched to db local

ywnds:PRIMARY> show tables

me

oplog.rs

replset.minvalid

slaves

startup_log

system.indexes

system.replset

这里我们看一下本地的local库，每一个mongod实例都有自己的local数据库，其中存储了复制进程所用的数据和其他实例单独的信息，local数据库对于复制时不可见的，local数据库将不会被复制。

进入到local库可以看到一些集合和索引文件，其中startup_log 是一个固定集合，该集合主要是用来诊断的（每个mongod 实例向 startup_log 插入一条有关mongod实例自身和host信息的诊断信息）；system.replset保存了复制集的配置文档信息（就是我们上面定义的config），跟rs.conf()返回的信息一样；oplog.rs是一个存储了oplog的固定集合，大小为我们在配置文件中设置的大小；replset.minvalid包含了复制集内部定位复制集状态信息；slaves包含了复制集每个节点和与其通讯的最后时间戳。如果该集合过时了，我们可以通过删除该节点来让复制集自动刷新生成。

6）验证复制集

192.168.60.10:27017插入数据

1

2

3

4

5

6

7

$ mongo 192.168.60.10:27017

MongoDB shell version: 3.2.0

connecting to: 192.168.60.10:27017/test

ywnds:PRIMARY> use ywnds

switched to db ywnds

ywnds:PRIMARY> db.ywnds.insert({name:"ywnds",age:"20",gender:"B"})

WriteResult({ "nInserted" : 1 })

然后我们来看一下主节点的数据目录（WiredTiger存储引擎为例）

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

$ ll -h /data/mongodb/data/data27017/

总用量 400K

-rw-r--r--. 1 root root  16K 1月  18 03:29 collection-0--3354265032980496329.wt

-rw-r--r--. 1 root root  16K 1月  18 03:29 collection-2--3354265032980496329.wt

-rw-r--r--. 1 root root  36K 1月  18 04:26 collection-4--3354265032980496329.wt

-rw-r--r--. 1 root root  32K 1月  18 03:39 collection-5--3354265032980496329.wt

-rw-r--r--. 1 root root  16K 1月  18 03:32 collection-7--3354265032980496329.wt

-rw-r--r--. 1 root root  16K 1月  18 04:26 collection-9--3354265032980496329.wt

drwxr-xr-x. 2 root root 4.0K 1月  18 04:33 diagnostic.data

-rw-r--r--. 1 root root  16K 1月  18 04:26 index-10--3354265032980496329.wt

-rw-r--r--. 1 root root  16K 1月  18 03:29 index-1--3354265032980496329.wt

-rw-r--r--. 1 root root  16K 1月  18 03:29 index-3--3354265032980496329.wt

-rw-r--r--. 1 root root  16K 1月  18 03:32 index-6--3354265032980496329.wt

-rw-r--r--. 1 root root  16K 1月  18 03:32 index-8--3354265032980496329.wt

drwxr-xr-x. 2 root root 4.0K 1月  18 03:28 journal

-rw-r--r--. 1 root root  36K 1月  18 04:26 _mdb_catalog.wt

-rw-r--r--. 1 root root    6 1月  18 03:28 mongod.lock

-rw-r--r--. 1 root root  36K 1月  18 04:26 sizeStorer.wt

-rw-r--r--. 1 root root   95 1月  18 03:28 storage.bson

-rw-r--r--. 1 root root   49 1月  18 03:28 WiredTiger

-rw-r--r--. 1 root root 4.0K 1月  18 03:28 WiredTigerLAS.wt

-rw-r--r--. 1 root root   21 1月  18 03:28 WiredTiger.lock

-rw-r--r--. 1 root root  920 1月  18 04:26 WiredTiger.turtle

-rw-r--r--. 1 root root  64K 1月  18 04:26 WiredTiger.wt

这里我们可以看到，由于使用了WiredTiger存储引擎，数据存储格式都跟MongoDB 2.6（使用MMAPV1存储引擎）不同了。

192.168.60.10:27018同步数据

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

$ mongo 192.168.60.10:27018

MongoDB shell version: 3.2.0

connecting to: 192.168.60.10:27018/test

ywnds:SECONDARY> rs.slaveOk()

ywnds:SECONDARY> show dbs

local  0.000GB

ywnds  0.000GB

ywnds:SECONDARY> use ywnds

switched to db ywnds

ywnds:SECONDARY> show tables

2016-02-03T11:34:24.505+0800 error: { "$err" : "not master and slaveOk=false", "code" : 13435 }

ywnds:SECONDARY> db.ywnds.insert({name:"eric",age:20})

WriteResult({ "writeError" : { "code" : undefined, "errmsg" : "not master" } })

ywnds:SECONDARY> rs.slaveOk(true)

ywnds:SECONDARY> show tables

ywnds

ywnds:SECONDARY> db.ywnds.find()

{ "_id" : ObjectId("569bf8b9a0c81df2ebc0d75d"), "name" : "ywnds", "age" : 20, "gender" : "B" }

我们看到数据已经同步过来了，但是如果我们不是通过驱动连接从节点的话，我们查看数据时会报错，说我们不是master节点，且slaveOK=false，所以查看不了。MongoDB在数据一致性上确实下了很大的功夫啊。那么也就是说如果从节点想查看数据就需要开启slaveOK，并且在从节点上是无法进行写入操作的。然后我们开启rs.slaveOk(1)立马就可以查看同步的数据了。

192.168.60.10:27019投票节点

1

2

3

4

5

6

7

8

9

10

11

12

13

$ mongo 192.168.60.10:27019

MongoDB shell version: 3.2.0

connecting to: 192.168.60.10:27019/test

ywnds:ARBITER> show dbs

admin  (empty)

local  0.078GB

ywnds:ARBITER> use local

switched to db local

ywnds:ARBITER> show tables

me

startup_log

system.indexes

system.replset

连接到投票节点，我们可以看到PRIMARY上的数据没有同步到投票节点上来，没有ywnds这个库。但是这里需要说明的是，我们可以看到arbiter虽然不同步数据但是local库却有system.indexes和system.replset这两个文件。另外我们可以发现local数据的大小为0.078GB（80M），库物理文件的第一个文件默认大小为64M，而命名空间文件为16M。

四、按照功能来区分复制集成员

从上面的分析可以看出三个节点的不同之处，也可以这么说，上面我们是按照数据来区分不同的复制集节点，那么下面我们按照功能上来区分各个节点。先来简单说一下各个节点状态的不同所能提供的功能有哪些？

主节点（PRIMARY）：默认提供读写服务的节点。

从节点（SECONDARY）：提供读服务的节点，但可以提供多样性服务，如可以转为“隐藏节点”对程序不可见、转为“延时节点”延时复制节点、转为“投票节点”具有投票权但不是arbiter。

投票节点（ARBITER）：ARBITER节点，无数据，仅作选举和充当复制集节点、也称它为选举节点。

五、复制集自动容灾

Mongodb复制集最大的特点就是可以自动容灾，这个特性是从主从复制的架构上改变而来，简单来说就是当复制集（3节点）中如果PRIMARY发生故障，其他节点无法探测到它的心跳信息时，复制集就会产生从新投票选出一个新的PRIAMRY提供服务。下面我们来模拟一下MongoDB的自动故障转移功能。

我们连接到27017主机上，此时的27017是PRIMARY

1

2

3

4

$ mongo 192.168.60.10:27017

MongoDB shell version: 3.2.0

connecting to: 192.168.60.10:27017/test

ywnds:PRIMARY>

我们连接到27018主机上，此时的27018是SECONDARY

1

2

3

4

$ mongo 192.168.60.10:27018

MongoDB shell version: 3.2.0

connecting to: 192.168.60.10:27018/test

ywnds:SECONDARY>

我们连接到27019主机上，此时的27019是ARBITER

1

2

3

4

$ mongo 192.168.60.10:27019

MongoDB shell version: 3.2.0

connecting to: 192.168.60.10:27019/test

ywnds:ARBITER>

模拟主节点宕机，kill掉27017的进程。

1

2

3

4

5

6

$ cat /mongodb/pid/pid27017/mongod.pid

125484

$ kill -2 125484

$ ps aux | grep mongod

root     125581  0.5  7.9 5266620 48252 ?       Sl   04:07   0:00 mongod -f /data/mongodb/conf/conf27018/mongod.conf

root     125670  0.5  5.1 849056 31440 ?        Sl   04:07   0:00 mongod -f /data/mongodb/conf/conf27019/mongod.conf

然后登录27018主机上，看看此时的SECONDARY已经转为PRIMARY了，但是这个过程会有短暂的断开。

1

2

3

4

$ mongo 192.168.60.10:27018

MongoDB shell version: 3.2.0

connecting to: 192.168.60.10:27018/test

ywnds:PRIMARY>

而27019主机上ARBITER还是ARBITER节点。

1

2

3

4

$ mongo 192.168.60.10:27019

MongoDB shell version: 3.2.0

connecting to: 192.168.60.10:27019/test

ywnds:ARBITER>

有兴趣可以通过show log rs命令查看复制集的日志信息，看看这个过程是怎么进行的。这就是MongoDB三节点（一主一从一投票或一主二从）复制集的故障转移功能，是不是很强大。当然除了复制集内部自动选举之外，我们也可以进行人工干预，使用rs.stepdown()方法可以手动切换。

原文地址：https://www.cnblogs.com/ExMan/p/9665098.html

时间： 2024-08-28 13:04:18

MongoDB 3.2复制集单节点部署（四）的相关文章

MongoDB 2.6复制集单节点部署（三）

MongoDB在单节点中也可以做复制集,但是仅限于测试实验,最大的好处就是部署方便快速,可以随便添加新节点,节省资源.在这里我使用的是MongoDB 2.6版本进行复制集实验(但MongoDB配置文件使用的是老版本格式),一共使用三个节点,一个是主节点(PRIMARY),一个是从节点(SECONDARY),一个是投票节点(ARBITER).如下图: 一.实验环境 1)节点信息:192.168.60.60 3)节点确保iptables和selinux已关闭 1 2 [root@node1 ~]#

rancher server 单节点部署/K8S高可用部署

环境说明: # 操作系统:centos7 # docker版本:19.03.5 # rancher版本: latest # rancher server 节点IP :192.168.2.175 # rancher agent节点IP: 192.168.2.175,192.168.2.176,192.168.2.177,192.168.2.185,192.168.2.187 # K8S master 节点IP:192.168.2.176,192.168.2.177,192.168.2.185 #

RDO单节点部署openstack (Havana)

OpenStack是一个开源的云计算管理平台项目,由几个主要的组件组合起来完成具体工作.OpenStack支持几乎所有类型的云环境,项目目标是提供实施简单.可大规模扩展.丰富.标准统一的云计算管理平台.OpenStack通过各种互补的服务提供了基础设施即服务(IaaS)的解决方案,每个服务提供API以进行集成. OpenStack 是一个旨在为公共及私有云的建设与管理提供软件的开源项目.它的社区拥有超过130家企业及1350位开发者,这些机构与个人都将OpenStack作为基础设施即服务(简称I

mongodb之replSet复制集

### mongodb的复制集 ### 注意点 - 服务器节点之前时间要同步 - 开启防火墙的一定要允许通过 - 开启selinux的也要进行设置 - 建立双击互信模式最好不过 ### 主服务器配置文件 - 添加一行 replSet = zhuima 定义一个副本集 [[email protected] ~]# sed -e '/^#/d;/^$/d' /etc/mongodb.conf bind_ip = 192.168.58.10 port = 27017 fork = true pidfi

mongodb replica sets复制集详解

一.replica sets介绍 一个复制集是一组包含相同数据集的mongod实例.一个复制集只能有一个是primary节点,其它的节点为secondary节点. 和主从复制的原理一样,复制集也是通过读取oplog来进行数据传输.oplog是一个capped collection即固定表,创建表的时候可以指定其大小,当oplog满的时候会删除旧的数据.所以设置oplog的大小非常重要,如果oplog在primary节点被覆盖而尚未被secondary节点读取的话就要重新resync. 一般的使用

Ubuntu下用devstack单节点部署Openstack

一.实验环境 本实验是在Vmware Workstation下创建的单台Ubuntu服务器版系统中,利用devstack部署的Openstack Pike版. 宿主机:win10 1803  8G内存  256G SSD 虚拟软件:Vmware Workstation 12.5.9 虚拟机系统:Ubuntu Server 16.04.5 LTS  参考博客: https://blog.csdn.net/pfztab/article/details/78632393 https://www.cnb

HyperLedger Fabric 1.2 单机单节点部署（10.2）

单机单节点指在一台电脑上部署一个排序(Orderer)服务.一个组织(Org1),一个节点(Peer,属于Org1),然后运行官方案例中的example02智能合约例子,实现转财交易和查询功能.单机单节点部署结构图如下: 图:单机单节点部署结构图 单机单节点部署步骤如下:1. 创建singlepeer目录 # cd $GOPATH/src/github.com/hyperledger/fabric # mkdir singlepeer # cd singlepeer 2. 获取生成工具 把下载的

mongodb 复制集各节点概述

默认情况:primary节点负责数据读写,secondary节点备份primary节点上的数据,但是arbiter节点 不会从primary节点同步数据 arbiter作用: 当primary节点故障,能够从second节点中,选出一个primary节点,不会参与数据读写. mongodb通过oplog.rs来实现复制集之间数据集之间同步的

小试牛刀之Kolla单节点部署

写在前面的话,笔者目的是为了尝试用Kolla来方便快捷的部署OpenStack,为以后多节点部署打下基础. Kola简介: kolla项目起源于TripleO项目,聚焦于使用Docker容器部署OpenStack服务.该项目由Cisco于2014年9月提出,是OpenStack 社区Big Tent开发模式下的孵化项目. Kolla项目是一个支持Openstack服务以容器的方式部署,借助ansible部署工具可以简单的扩展到多个节点.同时,又借助于使用 heat 来编排 Kolla 集群. 环