mongodb(下)
mongodb 副本集
早期版本使用master-slave,一主一从和MySQL类似,但slave在此架构中为只读,当主库宕机后,从库不能自动切换为主 目前已经淘汰master-slave模式,改为副本集,这种模式下有一个主(primary),和多个从(secondary),只读。支持给它们设置权重,当主宕掉后,权重最高的从切换为主 在此架构中还可以建立一个仲裁(arbiter)的角色,它只负责裁决,而不存储数据 再此架构中读写数据都是在主上,要想实现负载均衡的目的需要手动指定读库的目标server
mongo 副本集原理图:



配置副本集
准备三台机器: 192.168.127.128(primary) 192.168.127.129(secondary) 192.168.127.130(secondary)
编辑三台机器的配置文件,更改或增加:
重启服务
连接主,在主上运行命令
还可选择动态添加,在主上:
副本集测试
主上面:
从上面:
修改权重
重启问题
mongodb 分片搭建
分片就是将数据库进行拆分,将大型集合分隔到不同服务器上。比如,本来100G的数据,可以分割成10份存储到10台服务器上,这样每台机器只有10G的数据。 通过一个mongos的进程(路由)实现分片后的数据存储与访问,也就是说mongos是整个分片架构的核心,对客户端而言是不知道是否有分片的,客户端只需要把读写操作转达给mongos即可。 虽然分片会把数据分隔到很多台服务器上,但是每一个节点都是需要有一个备用角色的,这样能保证数据的高可用。 当系统需要更多空间或者资源的时候,分片可以让我们按需方便扩展,只需要把mongodb服务的机器加入到分片集群中即可
分片架构图

分片的相关概念
mongos: 数据库集群请求的入口,所有的请求都通过mongos进行协调,不需要在应用程序添加一个路由选择器,mongos自己就是一个请求分发中心,它负责把对应的数据请求请求转发到对应的shard服务器上。在生产环境通常有多mongos作为请求的入口,防止其中一个挂掉所有的mongodb请求都没有办法操作。
config server: 配置服务器,存储所有数据库元信息(路由、分片)的配置。mongos本身没有物理存储分片服务器和数据路由信息,只是缓存在内存里,配置服务器则实际存储这些数据。mongos第一次启动或者关掉重启就会从 config server 加载配置信息,以后如果配置服务器信息变化会通知到所有的 mongos 更新自己的状态,这样 mongos 就能继续准确路由。在生产环境通常有多个 config server 配置服务器,因为它存储了分片路由的元数据,防止数据丢失!
shard: 存储了一个集合部分数据的MongoDB实例,每个分片是单独的mongodb服务或者副本集,在生产环境中,所有的分片都应该是副本集。
分片搭建
准备三台机器 A B C
A(192.168.127.128)搭建:mongos、config server、副本集1主节点、副本集2仲裁、副本集3从节点
B(192.168.127.129)搭建:mongos、config server、副本集1从节点、副本集2主节点、副本集3仲裁
C(192.168.127.130)搭建:mongos、config server、副本集1仲裁、副本集2从节点、副本集3主节点 端口分配:mongos 20000、config 21000、副本集1 27001、副本集2 27002、副本集3 27003
三台机器全部关闭firewalld服务和selinux,或者增加对应端口的规则
分别在三台机器上创建各个角色所需要的目录
config server配置
mongodb3.4版本以后需要对config server创建副本集
添加配置文件(三台机器都操作)
启动三台机器的config server
分片配置
添加配置文件(三台机器都操作)
启动shard1
启动shard2
启动shard3
配置路由服务器
添加配置文件(三台机器都操作)
启动mongos服务,注意命令,前面都是mongod,这里是mongos
启用分片
登录任何一台20000端口
测试
登录任何一台20000端口
mongodb 备份和恢复
最后更新于
这有帮助吗?