设为首页 收藏本站
查看: 1688|回复: 0

[经验分享] Mongodb-复制

[复制链接]
累计签到:1 天
连续签到:1 天
发表于 2016-12-5 09:09:01 | 显示全部楼层 |阅读模式
复制:两种架构
1、一个master(读写),多个slave(读),但是mongodb这种架构无法实现故障自动转移

2、副本集:

复制集、副本集:Replica set,至少三个节点,通过选举选出1个主节点和2个备节点。主节点负责读写,备节点监控主节点并从主节点上获得其心跳信息。万一主节点挂了,则剩下的节点通过选举选出新的主节点,备节点则自动将其主节点指向新的主节点。能实现自动故障转移。在实现复制时,必须指明处于哪个副本集,所有节点都要明确工作于某个副本之上,只在此副本实现主从架构。如果还有其他节点,但其他节点所处的集群名称不一样的话,就处于不同的复制架构中。集群名称通过副本集名称定义的。主节点将所有的写操作写在一个日志文件(oplog)中,从节点复制写操作并在本地执行一遍。这个复制是异步的。
还有一种情况:
    三个节点中有一个节点不存任何数据,只有选举权,而没有被选举权。这样会导致假如一个节点挂了后,剩下的一个节点没有从节点,这样那个活动节点要降级为只读模式,因为它无法保证数据有副本存放的。
副本集参数:
replset:副本集名称
oplogsize:日志大小
fastsync:快速同步
replindexprefetch:在实现复制时,根据索引实现数据预取。这种特性可以实现快速装载主节点上的数据,尤其在修改量比较大的集群上,非常有意义,在2.2.2版本实现

实验:

条件:

所有节点时间同步
配置文件中的集群名称一致
三个节点都安装mongodb
三个节点的/etc/hosts文件设置如下:
1480430189712547.jpg
三个节点都创建数据目录、更改属主属组、修改配置文件请看上文
配置文件最后加上:
1480427766132637.jpg
rest = true 显示按钮的相关信息

复制配置文件到另外两个节点:
1480428015416810.jpg
启动服务:(三个节点都启动)

连接到任意节点执行副本集初始化命令即可。(rs命令)
1480428283551112.jpg
rs.status:显示rs状态
rs.initiate:初始化,第一次实现创建副本集要用这个命令初始化
rs.initiate(cfg):通过配置文件来初始化,配置文件由下面的命令获得
rs.conf:获取配置文件
rs.reconfig(cfg):重新初始化
rs.add(hostportstr):添加从节点的端口号

rs.add(membercfgobj):添加从节点

初始化:
1480429049934270.jpg
查看状态:
1480429095355996.jpg
查看是否为主节点:
1480429423473247.jpg
添加从节点并查看信息:
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
testrs0:PRIMARY> rs.add("192.168.0.22:27017")
{ "ok" : 1 }
testrs0:PRIMARY> rs.status()
{
    "set" : "testrs0",
    "date" : ISODate("2016-11-29T14:25:50Z"),
    "myState" : 1,
    "members" : [
        {
            "_id" : 0,
            "name" : "node1:27017",
            "health" : 1,
            "state" : 1,
            "stateStr" : "PRIMARY",
            "uptime" : 557,
            "optime" : Timestamp(1480429519, 1),
            "optimeDate" : ISODate("2016-11-29T14:25:19Z"),
            "self" : true
        },
        {
            "_id" : 1,
            "name" : "192.168.0.22:27017",
            "health" : 1,
            "state" : 2,
            "stateStr" : "SECONDARY",
            "uptime" : 31,
            "optime" : Timestamp(1480429519, 1),
            "optimeDate" : ISODate("2016-11-29T14:25:19Z"),
            "lastHeartbeat" : ISODate("2016-11-29T14:25:49Z"),
            "lastHeartbeatRecv" : ISODate("2016-11-29T14:25:50Z"),
            "pingMs" : 0,
            "syncingTo" : "node1:27017"
        }
    ],
    "ok" : 1
}



添加第二个节点并查看状态:(不知为何会不一样)

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
testrs0:PRIMARY> rs.add("192.168.0.23:27017")
{ "down" : [ "192.168.0.23:27017" ], "ok" : 1 }
testrs0:PRIMARY> rs.status()
{
    "set" : "testrs0",
    "date" : ISODate("2016-11-29T14:28:05Z"),
    "myState" : 1,
    "members" : [
        {
            "_id" : 0,
            "name" : "node1:27017",
            "health" : 1,
            "state" : 1,
            "stateStr" : "PRIMARY",
            "uptime" : 692,
            "optime" : Timestamp(1480429663, 1),
            "optimeDate" : ISODate("2016-11-29T14:27:43Z"),
            "self" : true
        },
        {
            "_id" : 1,
            "name" : "192.168.0.22:27017",
            "health" : 1,
            "state" : 2,
            "stateStr" : "SECONDARY",
            "uptime" : 166,
            "optime" : Timestamp(1480429663, 1),
            "optimeDate" : ISODate("2016-11-29T14:27:43Z"),
            "lastHeartbeat" : ISODate("2016-11-29T14:28:04Z"),
            "lastHeartbeatRecv" : ISODate("2016-11-29T14:28:04Z"),
            "pingMs" : 0,
            "syncingTo" : "node1:27017"
        },
        {
            "_id" : 2,
            "name" : "192.168.0.23:27017",
            "health" : 1,
            "state" : 2,
            "stateStr" : "SECONDARY",
            "uptime" : 22,
            "optime" : Timestamp(1480429663, 1),
            "optimeDate" : ISODate("2016-11-29T14:27:43Z"),
            "lastHeartbeat" : ISODate("2016-11-29T14:28:03Z"),
            "lastHeartbeatRecv" : ISODate("2016-11-29T14:28:04Z"),
            "pingMs" : 2,
            "syncingTo" : "node1:27017"
        }
    ],
    "ok" : 1
}



查看master:
1480429886510652.jpg
在主节点创建数据,看从能否获取到
主节点:
1
2
3
4
5
testrs0:PRIMARY> use testdb
switched to db testdb
testrs0:PRIMARY> db.testcoll.insert({Name:'test',Age:50,Gender:'F'})
testrs0:PRIMARY> db.testcoll.find({Name:'test'})
{ "_id" : ObjectId("583d92d63b539fcc9aef4fd4"), "Name" : "test", "Age" : 50, "Gender" : "F"



从节点:
从节点不能直接查询的,必须使用rs.slaveOk()把自己提升为可以接受查询的从节点
1
2
3
4
5
testrs0:SECONDARY> rs.slaveOk()
testrs0:SECONDARY> use testdb
switched to db testdb
testrs0:SECONDARY> db.testcoll.find({Name:'test'})
{ "_id" : ObjectId("583d92d63b539fcc9aef4fd4"), "Name" : "test", "Age" : 50, "Gender" : "F" }



让主节点挂点,看是否有一个会提升为主的:
停止主节点的服务即可:
1
2
[iyunv@node1 ~]# service mongod stop
Stopping mongod:                                           [  OK   ]



在刚才的备节点查看状态:
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
testrs0:SECONDARY> rs.status()
{
    "set" : "testrs0",
    "date" : ISODate("2016-11-29T14:45:20Z"),
    "myState" : 1,
    "members" : [
        {
            "_id" : 0,
            "name" : "node1:27017",
            "health" : 0,
            "state" : 8,
            "stateStr" : "(not reachable/healthy)",
            "uptime" : 0,
            "optime" : Timestamp(1480430294, 1),
            "optimeDate" : ISODate("2016-11-29T14:38:14Z"),
            "lastHeartbeat" : ISODate("2016-11-29T14:45:19Z"),
            "lastHeartbeatRecv" : ISODate("2016-11-29T14:44:00Z"),
            "pingMs" : 0
        },
        {
            "_id" : 1,
            "name" : "192.168.0.22:27017",
            "health" : 1,
            "state" : 1,
            "stateStr" : "PRIMARY",
            "uptime" : 1210,
            "optime" : Timestamp(1480430294, 1),
            "optimeDate" : ISODate("2016-11-29T14:38:14Z"),
            "self" : true
        },
        {
            "_id" : 2,
            "name" : "192.168.0.23:27017",
            "health" : 1,
            "state" : 2,
            "stateStr" : "SECONDARY",
            "uptime" : 1056,
            "optime" : Timestamp(1480430294, 1),
            "optimeDate" : ISODate("2016-11-29T14:38:14Z"),
            "lastHeartbeat" : ISODate("2016-11-29T14:45:19Z"),
            "lastHeartbeatRecv" : ISODate("2016-11-29T14:45:19Z"),
            "pingMs" : 1,
            "lastHeartbeatMessage" : "syncing to: 192.168.0.22:27017",
            "syncingTo" : "192.168.0.22:27017"
        }
    ],
    "ok" : 1
}
testrs0:PRIMARY>   #这里已经改为主的了



1480430813900061.jpg
在新的主节点添加数据:
1480430909729213.jpg
然后在从节点查看:
1480430941135587.jpg
让之前的主节点从新上线:
1480431004439023.jpg

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
testrs0:PRIMARY> rs.status()
{
    "set" : "testrs0",
    "date" : ISODate("2016-11-29T14:50:31Z"),
    "myState" : 1,
    "members" : [
        {
            "_id" : 0,
            "name" : "node1:27017",
            "health" : 1,
            "state" : 2,
            "stateStr" : "SECONDARY",   #其状态不再是主的了
            "uptime" : 45,
            "optime" : Timestamp(1480430874, 1),
            "optimeDate" : ISODate("2016-11-29T14:47:54Z"),
            "lastHeartbeat" : ISODate("2016-11-29T14:50:30Z"),
            "lastHeartbeatRecv" : ISODate("2016-11-29T14:50:29Z"),
            "pingMs" : 1,
            "lastHeartbeatMessage" : "syncing to: 192.168.0.22:27017",
            "syncingTo" : "192.168.0.22:27017"
        },
        {
            "_id" : 1,
            "name" : "192.168.0.22:27017",
            "health" : 1,
            "state" : 1,
            "stateStr" : "PRIMARY",
            "uptime" : 1521,
            "optime" : Timestamp(1480430874, 1),
            "optimeDate" : ISODate("2016-11-29T14:47:54Z"),
            "self" : true
        },
        {
            "_id" : 2,
            "name" : "192.168.0.23:27017",
            "health" : 1,
            "state" : 2,
            "stateStr" : "SECONDARY",
            "uptime" : 1367,
            "optime" : Timestamp(1480430874, 1),
            "optimeDate" : ISODate("2016-11-29T14:47:54Z"),
            "lastHeartbeat" : ISODate("2016-11-29T14:50:29Z"),
            "lastHeartbeatRecv" : ISODate("2016-11-29T14:50:29Z"),
            "pingMs" : 1,
            "syncingTo" : "192.168.0.22:27017"
        }
    ],
    "ok" : 1
}



打印复制信息:
1480431228166076.jpg



1480431364447582.jpg

1480431395161170.jpg

配置优先级:
rs.conf()显示现有的配置
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
testrs0:SECONDARY> rs.conf()
{
    "_id" : "testrs0",
    "version" : 3,
    "members" : [
        {
            "_id" : 0,
            "host" : "node1:27017"
        },
        {
            "_id" : 1,
            "host" : "192.168.0.22:27017"
        },
        {
            "_id" : 2,
            "host" : "192.168.0.23:27017"
        }
    ]
}



编辑配置文件:
方式1:rs.conf({id:xxx}),这种方式比较麻烦

方式2:把内容保存到文件中,重新应用就可以了
cfg=rs.conf()保存文件

cfg.members[0].priority=2设置优先级

rs.reconfig(cfg)重新应用
只能在主节点进行配置:

1480815707404367.jpg
40-45从看

三个节点理由有一个可以不被选举,只参与选举,无法触发选举,但可以参与选举。这种节点的优先级为0
触发重新选举:
    一个几点只能以从节点的身份去上线,然后主节点主持重新选举。
    优先级为0的节点:无权触发,仅参与选举
添加优先级为0的节点:rs.addArb(hostportstr)
移除节点:rs.remove(hostportstr)


Sharding:把一个很大的表的数据切割后放到不同的节点,各节点只存放一部分。每个服务器成为一个sharding节点。把每个collection分割为多片,平均分配到各节点。均匀分配。
用途:
    复制集很大、吞吐量大
    高并发查询可能耗尽cpu的处理能力
    海量数据集超出某一个节点的存储能力
    降低单台服务器的io压力
sharding架构:

1480818045678359.jpg
config servers:存储元数据
shard:存储数据
读操作:请求过来了,app server先去查找元数据,再查找shard。性能不好,因为各索引在shard节点中

写操作:shard特长
shard必须和业务数据相关联。
生产环境中应该至少有三个config server节点,这些服务器压力很小,所以可以放到运行其他应用的节点
mongos:端口28017,用来接收用户请求,合并数据,扮演前段的代理服务器。router之间不会通信。mongos1个也可以,mongos也可以直接安装到应用服务器中

shard:至少有2个

实验:1个mongos,1个config server,2个shard
1、配置config server
2、配置mongos
3、配置shard

配置config server:192.168.0.22
1480821315372224.jpg
1480821387828201.jpg
保存退出,重启服务

1480821449602272.jpg

端口:
1480821560177059.jpg

配置mongos:
1480821723139994.jpg
1480821769344678.jpg
1480821881689651.jpg
1480821902714214.jpg
启动shard:
只需改下数据目录,重启服务即可

下图中的A为主shard:

1480822182113325.jpg
连接mongos:

1480822573593588.jpg

查看shard状态:
1480822652838791.jpg
添加shard:在192.168.0.22上添加
1480822708586163.jpg
使用分区功能:sh.enableSharding(dbname)

1480822802924126.jpg
collection支持分区功能:sh.shardCollection(fullName,key,unique)
1480823000564115.jpg
1480823044493206.jpg

添加数据:
1480823516634771.jpg
在mongos上查看分片:192.168.0.21
1480823563214849.jpg

1480823580163074.jpg
完成重新均衡:
sh.addShard(host)添加新的shade

sh.setBalancerState均衡
查看是否均衡:
1480823895473954.jpg

补充:
php访问mongodb,需要编译相应的驱动。
aubiter:仅参与选举,不持有任何数据
0优先级的节点:持有数据,参与选举,但不能成为主节点
shard:
    读:不离散
    写:离散

选择sharding key的标准:
    应该在哪里存储数据
    应该从哪里得到希望的数据

基本法则:
    sharding key应该是主键
    sharding key应该能尽量保证避免跨分片查询

自学:
    1、新增shard
    2、移除shard

命令:
    mongodump:备份
    mongorestore:恢复
    mongoexport:导出
    mongoimport:导入
    mongostat:监控
    mongotop:
    mongooplog:
    mongoperf:性能评估
    mongofiles:查看和修改GridFS文件系统







运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-309815-1-1.html 上篇帖子: mongodb 备份与恢复 下篇帖子: mongodb sharding maintenance (分片维护1)
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表