NoSQL搭建高可用mongodb集群(二)—— 副本集

当达成平等首文章《搭建高可用MongoDB集群(一)——配置MongoDB》
提到了几乎只问题尚没有缓解。

  • 主节点悬挂了可不可以自行切换连接?目前待手工切换。
  • 主节点之读写压力过好争化解?
  • 从今节点每个点的数量还是针对数据库全量拷贝,从节点压力会无会见了死?
  • 数量压力很到机械支撑不了的时节是否成功自动扩展?

当时篇稿子看了这些问题虽足以打定了。NoSQL的发生就是为解决好数据量、高扩展性、高性能、灵活数据模型、高可用性。但是一味通过着力模式的架远远达不至地方几乎沾,由此MongoDB设计了入本集和分片的效用。这首稿子主要介绍副本集

mongoDB官方已经不建议利用基本模式了,替代方案是行使副本集的模式,点击查看
,如图:
NoSQL 1
这就是说什么是吻合本集呢?打魔兽世界总说打副本,其实就片单概念差不多一个意。游戏里之副本是依靠玩家集中在山上日错开一个景打怪,会油然而生玩家暴多怪物少的情形,游戏开发商为保险玩家的体验度,就吧各一样批玩家单独开放一个等同的上空同样的数码之精灵,这一个复制的状况就是是一个副本,不管生稍许个玩家分别在个别的副本里嬉戏无会见彼此影响。
mongoDB的副本为是是,主从模式其实就是一个单副本的动,没有很好的扩展性和容错性。而称本集具有多个副本保证了容错性,就算是一个副本挂掉了还有许多副本是,并且解决了点第一独问题“主节点挂掉了,整个集群内见面自动切换”。难怪mongoDB官方推荐用这种模式。我们来探视mongoDB副本集的架构图:

NoSQL 2

鉴于图可以望客户端连接到全合本集,不关注具体哪一样贵机械是否挂掉。主服务器负责整个合本集的读写,副本集定期联合数据备份,一而主节点挂掉,副本节点就会见选出一个初的主服务器,这所有对应用服务器不需要关怀。我们看一下预告服务器挂掉后底架构:

NoSQL 3

副本集中的副本节点在主节点悬挂掉后经心跳机制检测到后,就会见以集群内发起主节点之公推机制,自动选举一位新的主服务器。看起颇牛X的金科玉律,我们快操作部署一下!
合法推荐的合本集机器数量也至少3只,那咱们吧照此数目配置测试。

1、准备一定量宝机械 192.168.1.136、192.168.1.137、192.168.1.138。
192.168.1.136
当作可本集主节点,192.168.1.137、192.168.1.138当副本集副本节点

2、分别于各令机械上建立mongodb副本集测试文件夹

1

2

3

4

5

6

7

8

#存放整个mongodb文件

mkdir -p ``/data/mongodbtest/replset

#存放mongodb数据文件

mkdir -p ``/data/mongodbtest/replset/data

#进入mongodb文件夹

cd /data/mongodbtest

3、下载mongodb的安装程序包

1

wget http:``//fastdl``.mongodb.org``/linux/mongodb-linux-x86_64-2``.4.8.tgz

在意linux生产条件不可知装32各类的mongodb,因为32各类让压操作系统最酷2G的文书限制。

NoSQL 4

1

2

#解压下载的压缩包

tar xvzf mongodb-linux-x86_64-2.4.8.tgz

4、分别以每令机械及启动mongodb

1

/data/mongodbtest/mongodb-linux-x86_64-2``.4.8``/bin/mongod
--dbpath ``/data/mongodbtest/replset/data --replSet repset

得看到控制台上显示副本集还并未配置初始化信息。

1

2

Sun Dec 29 20:12:02.953 [rsStart] replSet can't get local.system.replset config from self or any seed (EMPTYCONFIG)

Sun Dec 29 20:12:02.953 [rsStart] replSet info you may need to run  replSetInitiate -- rs.initiate() in the shell -- if that is not already done

5、初始化副本集

每当三玉机械及自由一台机器登陆mongodb

1

2

3

4

/data/mongodbtest/mongodb-linux-x86_64-2``.4.8``/bin/mongo

#使用admin数据库

use admin

#概念副本集配置变量,这里的 _id:”repset” 和方命令参数“ –replSet
repset” 要保障同。

1

2

3

4

5

config = { _id:``"repset"``, members:[

... {_id:0,host:``"192.168.1.136:27017"``},

... {_id:1,host:``"192.168.1.137:27017"``},

... {_id:2,host:``"192.168.1.138:27017"``}]

... }

#输出

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

{

``"_id" : "repset",

``"members" : [

``{

``"_id" : 0,

``"host" : "192.168.1.136:27017"

``},

``{

``"_id" : 1,

``"host" : "192.168.1.137:27017"

``},

``{

``"_id" : 2,

``"host" : "192.168.1.138:27017"

``}

``]

}

1

2

#初始化副本集配置

rs.initiate(config);

#出口成功

1

2

3

4

{

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

``"ok" : 1

}

#查看日志,副本集启动成功后,138也主节点PRIMARY,136、137也副本节点SECONDARY

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

Sun Dec 29 20:26:13.842 [conn3] replSet replSetInitiate admin command received from client

Sun Dec 29 20:26:13.842 [conn3] replSet replSetInitiate config object parses ok, 3 members specified

Sun Dec 29 20:26:13.847 [conn3] replSet replSetInitiate all members seem up

Sun Dec 29 20:26:13.848 [conn3] ******

Sun Dec 29 20:26:13.848 [conn3] creating replication oplog of size: 990MB...

Sun Dec 29 20:26:13.849 [FileAllocator] allocating new datafile /data/mongodbtest/replset/data/local.1, filling with zeroes...

Sun Dec 29 20:26:13.862 [FileAllocator] done allocating datafile /data/mongodbtest/replset/data/local.1, size: 1024MB,  took 0.012 secs

Sun Dec 29 20:26:13.863 [conn3] ******

Sun Dec 29 20:26:13.863 [conn3] replSet info saving a newer config version to local.system.replset

Sun Dec 29 20:26:13.864 [conn3] replSet saveConfigLocally done

Sun Dec 29 20:26:13.864 [conn3] replSet replSetInitiate config now saved locally.  Should come online in about a minute.

Sun Dec 29 20:26:23.047 [rsStart] replSet I am 192.168.1.138:27017

Sun Dec 29 20:26:23.048 [rsStart] replSet STARTUP2

Sun Dec 29 20:26:23.049 [rsHealthPoll] replSet member 192.168.1.137:27017 is up

Sun Dec 29 20:26:23.049 [rsHealthPoll] replSet member 192.168.1.136:27017 is up

Sun Dec 29 20:26:24.051 [rsSync] replSet SECONDARY

Sun Dec 29 20:26:25.053 [rsHealthPoll] replset info 192.168.1.136:27017 thinks that we are down

Sun Dec 29 20:26:25.053 [rsHealthPoll] replSet member 192.168.1.136:27017 is now in state STARTUP2

Sun Dec 29 20:26:25.056 [rsMgr] not electing self, 192.168.1.136:27017 would veto with 'I don't think 192.168.1.138:27017 is electable'

Sun Dec 29 20:26:31.059 [rsHealthPoll] replset info 192.168.1.137:27017 thinks that we are down

Sun Dec 29 20:26:31.059 [rsHealthPoll] replSet member 192.168.1.137:27017 is now in state STARTUP2

Sun Dec 29 20:26:31.062 [rsMgr] not electing self, 192.168.1.137:27017 would veto with 'I don't think 192.168.1.138:27017 is electable'

Sun Dec 29 20:26:37.074 [rsMgr] replSet info electSelf 2

Sun Dec 29 20:26:38.062 [rsMgr] replSet PRIMARY

Sun Dec 29 20:26:39.071 [rsHealthPoll] replSet member 192.168.1.137:27017 is now in state RECOVERING

Sun Dec 29 20:26:39.075 [rsHealthPoll] replSet member 192.168.1.136:27017 is now in state RECOVERING

Sun Dec 29 20:26:42.201 [slaveTracking] build index local.slaves { _id: 1 }

Sun Dec 29 20:26:42.207 [slaveTracking] build index done.  scanned 0 total records. 0.005 secs

Sun Dec 29 20:26:43.079 [rsHealthPoll] replSet member 192.168.1.136:27017 is now in state SECONDARY

Sun Dec 29 20:26:49.080 [rsHealthPoll] replSet member 192.168.1.137:27017 is now in state SECONDARY

1

2

#查看集群节点的状态

``rs.status();

#输出

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

{

``"set" : "repset",

``"date" : ISODate("2013-12-29T12:54:25Z"),

``"myState" : 1,

``"members" : [

``{

``"_id" : 0,

``"name" : "192.168.1.136:27017",

``"health" : 1,

``"state" : 2,

``"stateStr" : "SECONDARY",

``"uptime" : 1682,

``"optime" : Timestamp(1388319973, 1),

``"optimeDate" : ISODate("2013-12-29T12:26:13Z"),

``"lastHeartbeat" : ISODate("2013-12-29T12:54:25Z"),

``"lastHeartbeatRecv" : ISODate("2013-12-29T12:54:24Z"),

``"pingMs" : 1,

``"syncingTo" : "192.168.1.138:27017"

``},

``{

``"_id" : 1,

``"name" : "192.168.1.137:27017",

``"health" : 1,

``"state" : 2,

``"stateStr" : "SECONDARY",

``"uptime" : 1682,

``"optime" : Timestamp(1388319973, 1),

``"optimeDate" : ISODate("2013-12-29T12:26:13Z"),

``"lastHeartbeat" : ISODate("2013-12-29T12:54:25Z"),

``"lastHeartbeatRecv" : ISODate("2013-12-29T12:54:24Z"),

``"pingMs" : 1,

``"syncingTo" : "192.168.1.138:27017"

``},

``{

``"_id" : 2,

``"name" : "192.168.1.138:27017",

``"health" : 1,

``"state" : 1,

``"stateStr" : "PRIMARY",

``"uptime" : 2543,

``"optime" : Timestamp(1388319973, 1),

``"optimeDate" : ISODate("2013-12-29T12:26:13Z"),

``"self" : true

``}

``],

``"ok" : 1

}

成套合本集已经搭建成功了。

6、测试可本集数据复制功能

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

#在主节点192.168.1.138 上连接到终端:

mongo 127.0.0.1

#建立test 数据库。

use ``test``;

往testdb表插入数据。

> db.testdb.insert({``"test1"``:``"testval1"``})

#在副本节点 192.168.1.136、192.168.1.137 上连接到mongodb查看数据是否复制过来。

/data/mongodbtest/mongodb-linux-x86_64-2``.4.8``/bin/mongo
192.168.1.136:27017

#使用test 数据库。

repset:SECONDARY> use ``test``;

repset:SECONDARY> show tables;

#输出

1

Sun Dec 29 21:50:48.590 error: { "$err" : "not master and slaveOk=false", "code" : 13435 } at src/mongo/shell/query.js:128

1

2

3

4

5

#mongodb默认是从主节点读写数据的,副本节点上不允许读,需要设置副本节点可以读。

repset:SECONDARY> db.getMongo().setSlaveOk();

#可以看到数据已经复制到了副本集。

repset:SECONDARY> db.testdb.``find``();

1

2

#输出

{ "_id" : ObjectId("52c028460c7505626a93944f"), "test1" : "testval1" }

7、测试可本集故障转移职能

先行歇少主节点mongodb
138,查看136、137之日志可以看出经过同多重之投票选操作,137
当选主节点,136从137一头数据恢复。

1

2

3

4

5

6

7

8

9

10

11

12

13

14

Sun Dec 29 22:03:05.351 [rsBackgroundSync] replSet sync source problem: 10278 dbclient error communicating with server: 192.168.1.138:27017

Sun Dec 29 22:03:05.354 [rsBackgroundSync] replSet syncing to: 192.168.1.138:27017

Sun Dec 29 22:03:05.356 [rsBackgroundSync] repl: couldn't connect to server 192.168.1.138:27017

Sun Dec 29 22:03:05.356 [rsBackgroundSync] replSet not trying to sync from 192.168.1.138:27017, it is vetoed for 10 more seconds

Sun Dec 29 22:03:05.499 [rsHealthPoll] DBClientCursor::init call() failed

Sun Dec 29 22:03:05.499 [rsHealthPoll] replset info 192.168.1.138:27017 heartbeat failed, retrying

Sun Dec 29 22:03:05.501 [rsHealthPoll] replSet info 192.168.1.138:27017 is down (or slow to respond):

Sun Dec 29 22:03:05.501 [rsHealthPoll] replSet member 192.168.1.138:27017 is now in state DOWN

Sun Dec 29 22:03:05.511 [rsMgr] not electing self, 192.168.1.137:27017 would veto with '192.168.1.136:27017 is trying to elect itself but 192.168.1.138:27017 is already primary and more up-to-date'

Sun Dec 29 22:03:07.330 [conn393] replSet info voting yea for 192.168.1.137:27017 (1)

Sun Dec 29 22:03:07.503 [rsHealthPoll] replset info 192.168.1.138:27017 heartbeat failed, retrying

Sun Dec 29 22:03:08.462 [rsHealthPoll] replSet member 192.168.1.137:27017 is now in state PRIMARY

Sun Dec 29 22:03:09.359 [rsBackgroundSync] replSet syncing to: 192.168.1.137:27017

Sun Dec 29 22:03:09.507 [rsHealthPoll] replset info 192.168.1.138:27017 heartbeat failed, retrying

查所有集群的状态,可以见见138啊状态不可达。

1

2

3

/data/mongodbtest/mongodb-linux-x86_64-2``.4.8``/bin/mongo
192.168.1.136:27017

repset:SECONDARY> rs.status();

#输出

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

{

``"set" : "repset",

``"date" : ISODate("2013-12-29T14:28:35Z"),

``"myState" : 2,

``"syncingTo" : "192.168.1.137:27017",

``"members" : [

``{

``"_id" : 0,

``"name" : "192.168.1.136:27017",

``"health" : 1,

``"state" : 2,

``"stateStr" : "SECONDARY",

``"uptime" : 9072,

``"optime" : Timestamp(1388324934, 1),

``"optimeDate" : ISODate("2013-12-29T13:48:54Z"),

``"self" : true

``},

``{

``"_id" : 1,

``"name" : "192.168.1.137:27017",

``"health" : 1,

``"state" : 1,

``"stateStr" : "PRIMARY",

``"uptime" : 7329,

``"optime" : Timestamp(1388324934, 1),

``"optimeDate" : ISODate("2013-12-29T13:48:54Z"),

``"lastHeartbeat" : ISODate("2013-12-29T14:28:34Z"),

``"lastHeartbeatRecv" : ISODate("2013-12-29T14:28:34Z"),

``"pingMs" : 1,

``"syncingTo" : "192.168.1.138:27017"

``},

``{

``"_id" : 2,

``"name" : "192.168.1.138:27017",

``"health" : 0,

``"state" : 8,

``"stateStr" : "(not reachable/healthy)",

``"uptime" : 0,

``"optime" : Timestamp(1388324934, 1),

``"optimeDate" : ISODate("2013-12-29T13:48:54Z"),

``"lastHeartbeat" : ISODate("2013-12-29T14:28:35Z"),

``"lastHeartbeatRecv" : ISODate("2013-12-29T14:28:23Z"),

``"pingMs" : 0,

``"syncingTo" : "192.168.1.137:27017"

``}

``],

``"ok" : 1

}

还开行原来的主节点 138,发现138 变为 SECONDARY,还是137 为主节点
PRIMARY。

1

2

3

4

5

6

7

8

Sun Dec 29 22:21:06.619 [rsStart] replSet I am 192.168.1.138:27017

Sun Dec 29 22:21:06.619 [rsStart] replSet STARTUP2

Sun Dec 29 22:21:06.627 [rsHealthPoll] replset info 192.168.1.136:27017 thinks that we are down

Sun Dec 29 22:21:06.627 [rsHealthPoll] replSet member 192.168.1.136:27017 is up

Sun Dec 29 22:21:06.627 [rsHealthPoll] replSet member 192.168.1.136:27017 is now in state SECONDARY

Sun Dec 29 22:21:07.628 [rsSync] replSet SECONDARY

Sun Dec 29 22:21:08.623 [rsHealthPoll] replSet member 192.168.1.137:27017 is up

Sun Dec 29 22:21:08.624 [rsHealthPoll] replSet member 192.168.1.137:27017 is now in state PRIMARY

8、java程序连接副本集测试。老三只节点有一个节点挂掉也非见面影响应用程序客户端对总体可本集的读写!

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

public class TestMongoDBReplSet {

``public static void main(String[] args) {

``try {

`List<ServerAddress> addresses =new`ArrayList<ServerAddress>();

`ServerAddress address1 =new`ServerAddress(``"192.168.1.136"
, ``27017``);

`ServerAddress address2 =new`ServerAddress(``"192.168.1.137"
, ``27017``);

`ServerAddress address3 =new`ServerAddress(``"192.168.1.138"
, ``27017``);

``addresses.add(address1);

``addresses.add(address2);

``addresses.add(address3);

`MongoClient client =new`MongoClient(addresses);

`DB db = client.getDB(“test”`);

`DBCollection coll = db.getCollection(“testdb”`);

``// 插入

`BasicDBObject object =new`BasicDBObject();

`object.append(“test2”,“testval2”`);

``coll.insert(object);

``DBCursor dbCursor = coll.find();

``while (dbCursor.hasNext()) {

``DBObject dbObject = dbCursor.next();

``System. out.println(dbObject.toString());

``}

`}catch`(Exception e) {

``e.printStackTrace();

``}

``}

}

当前关押起支持完善的故障转移了,这个架构是未是比全面了?其实还有很多地方得优化,比如开的亚独问题:主节点之宣读写压力过好焉缓解?常见的缓解方案是朗诵写分离,mongodb副本集的读写分离如何做为?

看图说话:

NoSQL 5

正常写操作来说并没读操作多,所以一律尊主节点负责写,两雅副本节点负责读。

1、设置读写分离需要先在副本节点SECONDARY 设置 setSlaveOk。
2、在程序中设置副本节点负责读操作,如下代码:

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

public class TestMongoDBReplSetReadSplit {

``public static void main(String[] args) {

``try {

`List<ServerAddress> addresses =new`ArrayList<ServerAddress>();

`ServerAddress address1 =new`ServerAddress(``"192.168.1.136"
, ``27017``);

`ServerAddress address2 =new`ServerAddress(``"192.168.1.137"
, ``27017``);

`ServerAddress address3 =new`ServerAddress(``"192.168.1.138"
, ``27017``);

``addresses.add(address1);

``addresses.add(address2);

``addresses.add(address3);

`MongoClient client =new`MongoClient(addresses);

`DB db = client.getDB(“test”`);

`DBCollection coll = db.getCollection(“testdb”`);

`BasicDBObject object =new`BasicDBObject();

`object.append(“test2”`, ``"testval2" );

``//读操作从副本节点读取

``ReadPreference preference = ReadPreference. secondary();

`DBObject dbObject = coll.findOne(object,null`, preference);

``System. out .println(dbObject);

`}catch`(Exception e) {

``e.printStackTrace();

``}

``}

}

念参数除了secondary一共还时有发生五只参数:primary、primaryPreferred、secondary、secondaryPreferred、nearest。

NoSQL 6

primary:默认参数,只于主节点上进展读取操作;
primaryPreferred:绝大多数自主节点上读取数据,只有主节点不可用时由secondary节点读取数据。
secondary:光从secondary节点上进展读取操作,存在的问题是secondary节点的多少会较primary节点数据“旧”。
secondaryPreferred:先由secondary节点进行读取操作,secondary节点不可用时由主节点读取数据;
nearest:甭管是主节点、secondary节点,从网延迟最低的节点上读取数据。

吓,读写分离做好我们得以数分流,减轻压力缓解了“主节点的念写压力过死哪缓解?”这个问题。不过当我们的副本节点增多时,主节点之复制压力会加大发什么办法缓解吧?mongodb早就出矣对应的解决方案。

看图:
NoSQL 7

里的决策节点不存储数据,只是负责故障转移的群体投票,这样就是掉了数额复制的下压力。是无是想念得生到啊,一看mongodb的开销兄弟熟知大数额架构体系,其实不一味是主节点、副本节点、仲裁节点,还有Secondary-Only、Hidden、Delayed、Non-Voting。

Secondary-Only:莫克成primary节点,只能作为secondary副本节点,防止有属性不高之节点成为主节点。
Hidden:即看似节点是休可知被客户端制定IP引用,也未能够给装为主节点,但是得投票,一般用于备份数据。
Delayed:足指定一个年华推从primary节点同步数据。主要用以备份数据,如果实时同步,误删除数据及时同步到起节点,恢复又死灰复燃不了。
Non-Voting:从没选举权的secondary节点,纯粹的备份数据节点。

至此整个mongodb副本集搞定了个别个问题:

  • 主节点悬挂了可不可以自行切换连接?目前内需手工切换。
  • 主节点的朗读写压力过大焉化解?

还有这简单单问题持续解决:

  • 起节点每个点的数码都是指向数据库全量拷贝,从节点压力会不会见了那个?
  • 数据压力好及机械支撑不了的时光是否完成自动扩展?

举行了副本集发现并且有问题:

  • 切本集故障转移,主节点是如何选的?能否手动干涉下架某同玉主节点。
  • 法定说称本集数量最为是奇数,为什么?
  • mongodb副本集是什么样共同的?如果并不立即会现出啊情况?会无会见冒出不一致性?
  • mongodb的故障转移会不见面无故自动发出?什么条件会硌?频繁触发可能会见带动系统负荷加重

参考:

http://cn.docs.mongodb.org/manual/administration/replica-set-member-configuration/

http://docs.mongodb.org/manual/reference/connection-string/

http://www.cnblogs.com/magialmoon/p/3268963.html

原创文章,转载请注明:
转载自LANCEYAN.COM

本文链接地址: 搭建高可用mongodb集群(二)——
副本集

网站地图xml地图