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

转自:http://www.lanceyan.com/tech/mongodb/mongodb\_repset1.html

在齐同样首文章《搭建高可用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的故障转移会不会见无故自动出?什么条件会接触?频繁接触可能会见带动系统负荷加重
网站地图xml地图