MongoDB之分片集群与复制集

分片集群

1.1、概念

分片集群是将数据存储在多台机器上的操作,主要由查询路由mongos、分片、配置服务器组成。

●查询路由根据配置服务器上的元数据将请求分发到相应的分片上,本身不存储集群的元数据,只是缓存在内存中。

●分片用来存储数据块。数据集根据分片键将集合分割为数据块,存储在不同的分片上。在生产环境下,通常一个分片由一个复制集组成。

●配置服务器存储集群的元数据,包括数据与分片的映射关系,配置服务器一旦挂掉,集群将无法工作。

注意:

●当mongos重启时,会从配置服务器读取元数据更新自己缓存的元数据

●当分割数据时或者在分片间移动数据时会写配置服务器。

●在分片集群中,配置服务器可以采用复制集的架构,但复制集中不允许有仲裁节点和延时节点,且buildindexes必须设为true。

●集合的数据分布在多个分片上,如果某个分片失效,查询会返回错误,可以通过为查询指定partial选项,允许接受不完整的数据

作用

单台机器无法满足存储需求,内存、磁盘空间不够,读写吞吐量不够。

1.2、如何维护数据均衡分布

集群使用分割器和平衡器两个后台进程维护数据均匀分布。

分割器

●分割器的作用是防止数据块变大,数据块大小默认是64MB,当超过64MB时,分割器会将其一分为二。

●分割的对象不是实际的数据,而是元数据,只是在逻辑上进行逻辑块的划分,不会影响到实际数据的分布

●数据块太小会产生大量块,容易使集群不平衡,导致数据块频繁移动,降低集群性能,元数据增加,降低查询效率

●数据块太大,会减小移动频率,元数据少,有利于数据查询,但一旦移动,会花费很长时间

●并不是所有的集合都会分片,没有被分片的集合都存储在同一个主分片上

●只有对数据库和集合开启分片后,数据才会在不同分片上分布,否则只存储在主分片上

●插入和更新操作都有可能引发分割

平衡器

●平衡器的作用是管理数据块的移动。

●当集群中数据块的分布达到移动阈值时,平衡器会移动数据块。

●增加或减少分片或增删数据也会使平衡器移动数据块

1.3数据块如何存储在相应分片上

每个需要被分片的集合都需要指定索引字段作为分片键,mongodb使用区间分区或哈希分区算法根据分片键将数据分割为数据块。

●区间分区

数据块覆盖一段子区间,任何分片键都会被某一段覆盖

优缺点

区间分区支持更好的range查询,通过分片键查询,查询路由可以很容易的判断出哪些数据块含有查询需要数据,并将请求分配到的分片上。

区间分区使数据分布不均匀

●哈希分区

根据分片键的哈希值进行数据的分配。

优缺点

数据随机分配到不同的数据块

在进行range查询时,由于相邻数据分布在不同分片上,导致访问很多分片

注意

●分片键不能是多键索引,即索引字段的值不能是数组

●分片键一旦被指定,不能被修改为其他字段,同时分片键的字段值也不能被修改

●如果集群的写操作比较多,可以使用哈希分区,将数据均匀分配到节点上,将写操作均匀应用与集群,

如果集群读操作比较多,可以使用区间分区,将相邻数据分到同一节点上,便于查询

●如果查询时没有指定索引字段,查询路由会将请求分发到所有节点上,等待返回结果,查询效率低

如果查询时指定了索引字段,查询路由会将请求分发到少数节点上,查询效率高

1.4、数据迁移过程

●平衡器向源节点发送movechunk指令

●源节点移动指定数据块,在迁移期间,数据块的读写操作仍路由到源节点

●目的节点如果没有需要的索引,此时会构建索引

●目的节点开始请求数据块中的数据,保存在本地

●在迁移期间,源节点上的数据如果发生变化,在迁移完之后,目的节点会同步源节点上变更的数据

●同步结束后,目的节点会与配置服务器建立连接,配置服务器更新元数据,此期间源节点阻塞写操作

●源节点上的旧数据被删除

1.5、备份数据

mongodump -h dbhost -d dbname -o directory 命令格式

mongodump -h 127.0.0.1:28002 -d test -o /home/backup

将本机数据库test中数据备份到/home/backup下

恢复数据

mongorestore -h dbhost -d dbname –directoryperdb dbdirectory dbdirectory为备份数据所在位置

复制集

2.1、概念与特性

概念

复制集是一组具有相同数据的mongod实例,包含主节点以及从节点。集群中任何时候只有一个主节点,主节点将数据变更操作写到oplog(封顶表)中,从节点读取oplog,并将oplog中的操作应用的本地数据,从而实现数据同步。

特性

●异步复制

从节点并不是实时复制主节点中的数据

●自动容灾

主节点宕机,主动发起选举

●读操作

从从节点上读到的数据可能并不是最新的

2.2、复制集成员

复制集最多包含50个节点,最多只能有7个可以投票。包含以下节点类型

●主节点primary

可以执行读写操作,所有节点均可以执行读操作。默认情况下,读请求只会发送给主节点,可以通过read preference设置。主节点的优先级priority至少为1。

●从节点secondary

只可以执行读操作。从节点通过与主节点同步,实现备份数据的功能,复制集至少有一个从节点。通过配置复制集的配置文件可以设置从节点是否参与选举(vote=0)以及是否可以被选举为主节点(priority=0)优先级priority为0的节点不能发起选举,不能被选举为主节点,但可以投票。

●隐藏节点

通过设置从节点的hidden属性,可以对客户端隐藏节点,不接受读写请求,无法被选举为主节点(priority=0),只能投票,主要用于备份数据。

●延时节点

通过设置隐藏节点的slaveDelay属性可以使节点延时一定时间从主节点复制数据,可以起到保护数据的作用。延时节点是在隐藏节点的基础上,多了一个延时属性。

●仲裁节点Arbiter

本身不存储数据,不能被选举为主节点,只能投票,仲裁节点主要用于使复制集中节点个数为奇数,从而容易达到多数派。仲裁节点只消耗极少的资源,但不要与主节点、从节点部署在同一个物理节点上。

●非投票节点

不参与投票,但存储数据,可以接受读操作

2.3、复制集管理

●use admin切换到admin数据库

●config={_id:”myset”,members:[{“_id”:0,”host”:”127.0.0.1:28001”,”priority”:2},{“_id”:1,”host”:”127.0.0.1:28002”,”priority”:1}]}

●rs.initiate(config)

修改复制集配置

●cfg=rs.conf()

●cfg.members[0].priority=1

●rs.reconfig(cfg)

复制集维护

将配置文件中的replset注释掉,从而以单机模式启动复制集,维护完毕后再加入复制集。

2.4、大多数原则

概念

如果复制集中的节点个数为N,则大多数为N/2+1(N/2向下取整),当复制集中存活节点数小于大多数时,不存在主节点,无法提供写服务。

作用

大多数原则保证了,在任何时刻复制集中的主节点个数不会超过一个。比如复制集部署在两个机房,两个机房通信发生故障,不含有主节点的机房会选举出一个主节点,等到故障恢复,复制集就会存在两个主节点,无法保证数据的一致性。

2.5、选举

选举的前提条件

复制集满足大多数原则。在选举的过程中,复制集无法进行写操作。

何时会引发选举

●复制集初始化时或被重新配置后

●主节点宕机或主节点网络不可达,即大多数节点无法连接主节点

●人为将主节点降为从节点,执行rs.stepDown(n)命令

●有更高优先级的节点加入复制集

选举特点

●优先级高的节点优先被选为主节点

●具有最高optime的节点被选为主节点

●如果优先级高的节点不具有最新的optime,那么首先会同步主节点的oplog

●优先级为0的节点无法发起选举,且无法成为主节点,只能投票。

●所有成员都可以否决选举,包括不投票的节点Non-voting

何时否决选举

●发起选举的节点不包含最新数据

●发起选举的节点优先级比其他节点低

●发起选举的节点没有持有最高的optime

2.6、数据回滚

概念:在主节点失效之前,从节点并未全部复制主节点上的数据,原先的主节点在选举出新的主节点后重新加入复制集,会导致旧主节点与新主节点数据不一致,旧主节点会将不一致的数据回滚,从而与主节点数据保持一致。

避免数据回滚

默认情况下,在主节点上写入成功后,就会向客户端返回结果,可能造成回滚,客户端可以修改写策略writeconcern为向大多数节点写入成功后才返回结果。

2.7、读写策略

writeconcern:不等待主节点写入成功,客户端就返回结果;等待主节点写入成功,就返回结果;等到大多数节点写入成功,才返回结果

readconcern:只读主节点、只读从节点、优先主节点、优先从节点、读网络延迟最小的节点

2.8、复制集优缺点

优点

●自动容灾。主节点宕机,通过投票选举主节点,保证数据安全

●自动备份数据,无需人工干预

●易于扩展

●数据可靠性高

缺点

●消耗资源高

●不能解决负载均衡的问题

●客户端读到的数据可能并未持久化 ,比如:客户端可以读到最新写入的数据,但数据有可能存在磁盘写入失败的可能;客户端读到的数据可能发生rolled back

参考

Mongodb中Sharding集群

时间: 2024-08-05 07:03:48

MongoDB之分片集群与复制集的相关文章

搭建mongodb集群(副本集+分片)

完整的搭建mongodb集群(副本集+分片)的例子... 准备四台机器,分别是bluejoe1,bluejoe2,bluejoe3,以及bluejoe0 副本集及分片策略确定如下: 将创建3个副本集,命名为shard1,shard2,shard3: 以上3个副本集作为3个分片: 每个副本集包含2个副本(主.辅): 副本分开存储,即shard1存在bluejoe1和bluejoe2上各一份...以此类推 将创建3个配置库实例,一台机器一个 bluejoe0上配置一个mongos(mongos一般可

MongoDB集群搭建-副本集

MongoDB集群搭建-副本集 概念性的知识,可以参考本人博客地址: http://www.cnblogs.com/zlp520/p/8088169.html 一.Replica Set方案(副本集或复制集): 1.搭建副本集有两种办法: 其一:在一台服务器上,通过文件的方式及端口号的方式来区分: 其二:找最少三台服务器,每台服务器都通过如下的配置: ip规划每台服务器担任的工作: 192.168.0.100:27017 主机 192.168.0.101:27017 副本集 192.168.0.

Tomcat集群session复制,httpd/nginx反代Tomcat集群

   一个大型站点都会涉及到动态应用,动态应用都需要做会话保持,常见的会话保持方式就三种,一是session stick,二是session replication,三是session share,对于小型规模的tomcat集群,大多者会采用session replication方式,但阅读官方文档也好,查询大牛博客也罢,发现均有不准确之处,所以亲测成功实现之后得出如下文档,还望高人指点. 实验环境: 操作系统:CentOS 7.2 tomcat版本:tomcat-7.0.54(yum安装方式)

Mongodb集群部署以及集群维护命令

Mongodb集群部署以及集群维护命令 http://lipeng200819861126-126-com.iteye.com/blog/1919271 mongodb分布式集群架构及监控配置 http://freeze.blog.51cto.com/1846439/884925/ 见文中: 七.监控配置:      早在去年已经出现MongoDB和Redis的Cacti模板,使用它,你可以对你的MongoDB和Redis服务进行流量监控.cacti的模板一直在更新,若企业已经用到nosql这种

Redis集群演变和集群部署

Redis系列: Redis安装和配置 Redis基本数据结构 Redis核心原理 Redis集群演变和集群部署 Redis高可用集群之水平扩展 一.Redis集群方案比较 哨兵模式 在redis3.0以前的版本要实现集群一般是借助哨兵sentinel工具来监控master节点的状态,如果master节点异常,则会做主从切换,将某一台slave作为master,哨兵的配置略微复杂,并且性能和高可用性等各方面表现一般,特别是在主从切换的瞬间存在访问瞬断的情况,而且哨兵模式只有一个主节点对外提供服务

分布式缓存技术redis学习系列(四)——redis高级应用(集群搭建、集群分区原理、集群操作)

本文是redis学习系列的第四篇,前面我们学习了redis的数据结构和一些高级特性,点击下面链接可回看 <详细讲解redis数据结构(内存模型)以及常用命令> <redis高级应用(主从.事务与锁.持久化)> 本文我们继续学习redis的高级特性--集群.本文主要内容包括集群搭建.集群分区原理和集群操作的学习. Redis集群简介 Redis 集群是3.0之后才引入的,在3.0之前,使用哨兵(sentinel)机制(本文将不做介绍,大家可另行查阅)来监控各个节点之间的状态.Redi

CAS服务器集群和客户端集群环境下的单点登录和单点注销解决方案

CAS的集群环境,包括CAS的客户应用是集群环境,以及CAS服务本身是集群环境这两种情况.在集群环境下使用CAS,要解决两个问题,一是单点退出(注销)时,CAS如何将退出请求正确转发到用户session所在的具体客户应用服务器,而不是转发到其他集群服务器上,二是解决CAS服务端集群环境下各种Ticket信息的共享. CAS集群部署 由于CAS Server是一个Web应用,因此可部署在Tomcat等容器中.直接部署CAS集群并使用负载均衡配置后,由于每次访问的CAS Server不固定,会发生通

Hadoop2.0集群、Hbase集群、Zookeeper集群、Hive工具、Sqoop工具、Flume工具搭建总结

实验开发环境所用软件: [[email protected] local]# ll total 320576 -rw-r--r-- 1 root root 52550402 Mar 6 10:34 apache-flume-1.6.0-bin.tar.gz drwxr-xr-x 7 root root 4096 Jul 15 10:46 flume drwxr-xr-x. 11 root root 4096 Jul 10 21:04 hadoop -rw-r--r--. 1 root root

Hadoop集群管理--保证集群平稳地运行

本篇介绍为了保证Hadoop集群平稳地运行,需要深入掌握的知识,以及一些管理监控的手段,日常维护的工作. HDFS 永久性数据结构 对于管理员来说,深入了解namenode,辅助namecode和datanode等HDFS组件如何在磁盘上组织永久性数据非常重要. 洞悉各文件的用法有助于进行故障诊断和故障检出. namenode的目录结构 namenode被格式化后,将在${dfs.namenode.name.dir}/current 目录下,产生如下的目录结构:VERSION.edits.fsi