MongoDB高可用与分片

目录
  • 一、复制
  • 二、如何进行选举
  • 三、优先级
  • 四、选举仲裁者
  • 五、同步
  • 六、处理过时数据
  • 七、哈希片键
  • ​​​​​​八、多热点
  • 九、分片规则
    • 1、分片的限制
    • 2、片键的基数
  • 十、控制数据分发
    • 1、自动分片
    • 2、手动分发

一、复制

在MongoDB中,创建副本集后就可以使用复制功能了,副本集是一组服务器,其中一个用于处理写操作的主节点primary,还有多个用于保存主节点数据副本的从节点secondary。如果主节点崩溃了,则从节点会选取出一个新的主节点。

如果使用复制功能时有一台服务器停止运行了,那么仍然可以从副本集中的其它服务器访问数据。如果服务器上的数据已损坏或无法访问,则可以从副本集中的其它成员中创建一个新的数据副本。

副本集中的每个成员都必须能够连接到其它成员,如果收到有关成员无法访问到其它成员,则可能需要更改网络配置以允许它们之间的连接。

二、如何进行选举

当一个从节点无法与主节点连通时,它就会联系并请求其它的副本集成员将自己选举为主节点。

其它成员会做几项健全性检查:

  1. 它们能否连接到主节点,而这个主节点是发起选举的节点无法连接到的?
  2. 这个发起选举的从节点是否有最新数据?
  3. 有没有其它更高优先级的成员可以被选举为主节点?

MongoDB在3.2版本中引入了第1版复制协议。这是一个类PAFT的协议,并且包含了一些特定于MongoDB的副本集概念,比如仲裁节点、优先级、非选举成员、写入关注点等。还提出了很多新概念,比如更短的故障转移时间,大大减少了检测主节点失效的时间,它还通过使用term ID来防止重复投票。

RAFT是一种共识算法,它被分解成了相对独立的子问题。共识是指多台服务器或进程在一些值上达成一致的过程。RAFT确保了一致性,使得同一序列的命令产生相同序列的结果,并在所部署的各个成员中达到相同序列的状态。

副本集成员相互间每隔两秒发送一次心跳。如果某个成员在10秒内没有反馈心跳,则其它成员会将不良成员标记为无法访问。选举算法将尽最大努力尝试让具有最高优先权的从节点发起选举。成员优先权会影响选举的时机和结果。优先级高的从节点要比优先级低的从节点更快发起选举,而且也更有可能成为主节点。然而,低优先级的从节点也是有可能被短暂的选举为主节点的,副本集成员会继续发起选举直到可用的最高优先级成员被选举为主节点。被选举为主节点的从节点必须拥有最新的复制数据。

三、优先级

优先级用于表示一个成员称为主节点的优先程度,取值范围是0 ~ 100。数值越大,优先级越高。默认为1,如果将priority设置为0,表示此节点永远无法成为主节点,这样的成员还有一个名字~被动成员。

四、选举仲裁者

大多数小型项目,MongoDB只有两个副本集,为了参与选举,MongoDB支持一种特殊类型的成员,称为仲裁者,其唯一作用就是参与仲裁。仲裁者不参与存储数据,也不会为程序提供服务,它只是为了帮助只有两个副本集的集群选举主节点(为了满足大多数),需要注意的是,只能有一个仲裁者。

仲裁者的缺点:

假设有一个主节点,两个从节点,一个仲裁者。如果一个从节点停止运行了,那么就需要一个新的从节点,并且将主节点的数据复制到新的从节点,复制数据会父服务器造成很大的压力,降低程序运行速度。所以,尽可能使用奇数的从节点,而不是使用仲裁者。

五、同步

MongoDB通过保存操作日志oplog使多台服务器间保持相同的数据,oplog中保存着主节点执行的每一次写操作。oplog存在于主节点local数据库中的一个固定集合中,从节点通过查询此集合以获取需要复制的操作。

每个从节点同样维护着自己的oplog,用来记录它从主节点复制的每个操作。这使得每个成员都可以被用作其他成员的同步源。如果应用某个操作失败,则从节点会停止从当前数据源复制数据。

如果一个从节点由于某种原因停止工作了,它重新启动后,会从oplog中的最后一个操作开始同步。由于这些操作是先应用到数据上然后再写入oplog,因此从节点可能会重复已经应用到数据上的操作。MongoDB在设计时考虑了这点,oplog中的操作执行一次和多次,效果都是一样的,oplog中的每个操作都是幂等的。

六、处理过时数据

如果某个从节点的数据远远落后于同步源当前的操作,那么这个从节点就是过时的。过时的从节点无法赶上同步源,如果继续同步,从节点就需要跳过一些操作。此时,需要从其它节点进行复制,看看其它成员是否有更长的oplog以继续同步。如果都没有,该节点当前的复制操作将停止,需要进行完全同步或从最近的备份中恢复。

为了避免出现不同步的节点,让主节点拥有比较大的oplog以保存足够多的操作日志。

七、哈希片键

为了尽可能快地加载数据,哈希片键是最好的选择。哈希片键可以使任何字段随机分发。如果打算在大量查询中使用升序键,但又想在写操作时随机分发,哈希片键是不错的选择,不过需要注意的是,哈希片键无法执行指定目标的范围查询。

创建哈希片键:

db.users.createIndex({"name":"hashed"})

有一点需要注意,哈希片键的字段,不能是数组。

Error: hashed indexes do not currently support array values

​​​​​​八、多热点

单独的mongod服务器在执行升序写操作时效率最高,这与分片相冲突,当写操作分发在集群中时分片效率最高。每个分片上都有几个热点,便于写操作在集群中均匀分发。

可以使用复合片键实现均匀分发,复合片键的第一个值可以是一个基数较小的值,片键的第二部分是一个升序值,这意味着在块的内部,值总是在增加的。

九、分片规则

1、分片的限制

比如上图的异常,片键不能是数组,大多数特殊类型的索引不能用作片键。特别是,不能在地理空间索引上进行分片。

2、片键的基数

片键与索引类似,在基数高的字段上进行分片,性能会更好。如果有一个status键,只有“正常”、“异常”、“错误”几个值,MongoDB是无法将数据拆分成3个以上的块(因为目前只有三个值),如果想将一个取值较小的键作为片键,那么可以将其与另一个拥有多值的键组成复合片键,比如createTime字段。这样复合片键就拥有了较高的基数。

十、控制数据分发

1、自动分片

MongoDB将集合均匀分发在集群中的每个分片上,如果存储的是同构数据,那么这种方式非常高效。如果有一个日志集合,价值不是很大,你可能不希望它存储在性能最好的服务器上,性能最好的服务器一般会存储重要的实时数据,而不允许其它集合使用它。

可以通过sh.addShardToZone("shard0","hign")sh.addShardToZone("shard1","low")sh.addShardToZone("shard2","low")实现它。

可以将不同的集合分配给不同的分片,比如,对及其重要的实时集合执行:

sh.updateZoneKeyRange("super.important",{"<shardKey>":MinKey},...{"<shardKey>":MaxKey},"high")

这条命令指的是:

对于这个集合super.important,将片键从负无穷到正无穷的数据保存在标记为“high”的分片上。这不会影响其它集合的均匀分发。

同样可以通过low,将不重要的日志集合存放在性能较差的服务器上。

sh.updateZoneKeyRange("super.logs",{"<shardKey>":MinKey},...{"<shardKey>":MaxKey},"low")

此时,日志集合就会均匀的分发到shard1和shard2上。

同样,可以通过removeShardFromZone()从区域中删除分片。

sh.removeShardFromZone("super.logs",{"<shardKey>":MinKey},...{"<shardKey>":MaxKey})

2、手动分发

可以通过关闭均衡器 sh.stopBalancer()启动手动分发。

如果当前正在进行迁移,则此设置在迁移完成之前不会生效。一旦正在运行的迁移完成,均衡器就会停止移动数据。

除非遇到特殊情况,否则,MongoDB应该使用自动分片,而不是手动分片。

到此这篇关于MongoDB高可用与分片的文章就介绍到这了,更多相关MongoDB高可用与分片内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • Mongodb副本集和分片示例详解

    前言 因为之前没用过mongo,所以最近的开发踩了不少坑,现在熟练了不少. mongo在许多地方用起来还有许多不如意的地方,比如不知道如何加行锁,虽然mongo本身可以加写锁, 多写的时候保证原子性,但不能向mysql在事务中 select ... for update 这样加锁, 这样可以在应用代码中添加逻辑并且保证该对应行不被读取或修改. 还好的是Mongodb4.0是支持事务的(看网上貌似3.6就支持了,但得自己开启).刚好前端时间有些业务需求需要用到事务来保证数据的准确性,因为一个动作内

  • 深入理解MongoDB分片的管理

    前言 在MongoDB(版本 3.2.9)中,分片集群(sharded cluster)是一种水平扩展数据库系统性能的方法,能够将数据集分布式存储在不同的分片(shard)上,每个分片只保存数据集的一部分,MongoDB保证各个分片之间不会有重复的数据,所有分片保存的数据之和就是完整的数据集.分片集群将数据集分布式存储,能够将负载分摊到多个分片上,每个分片只负责读写一部分数据,充分利用了各个shard的系统资源,提高数据库系统的吞吐量. 数据集被拆分成数据块(chunk),每个数据块包含多个do

  • mongodb3.4集群搭建实战之高可用的分片+副本集

    前言 最近因为工作的原因,在学习使用mongodb数据库,mongodb是最常用的nodql数据库,在数据库排名中已经上升到了前六.这篇文章介绍如何搭建高可用的mongodb(分片+副本)集群,分享出来供大家参考学习,下面话不多说了,来一起看看详细的介绍: 在搭建集群之前,需要首先了解几个概念:路由,分片.副本集.配置服务器等. 相关概念 先来看一张图: 从图中可以看到有四个组件:mongos.config server.shard.replica set. mongos,数据库集群请求的入口,

  • MongoDB搭建高可用集群的完整步骤(3个分片+3个副本)

    配置脚本以及目录下载:点我下载 一.规划好端口ip 架构图如下,任意抽取每个副本集中的一个分片(非仲裁节点)可以组成一份完整的数据. 1. 第一个副本集rs1 share1 10.0.0.7:30011:/data/share_rs/share_rs1/share1/data/ share2 10.0.0.7:40011:/data/share_rs/share_rs1/share2/data/ share3 10.0.0.7:50011:/data/share_rs/share_rs1/sha

  • MongoDB高可用与分片

    目录 一.复制 二.如何进行选举 三.优先级 四.选举仲裁者 五.同步 六.处理过时数据 七.哈希片键 ​​​​​​八.多热点 九.分片规则 1.分片的限制 2.片键的基数 十.控制数据分发 1.自动分片 2.手动分发 一.复制 在MongoDB中,创建副本集后就可以使用复制功能了,副本集是一组服务器,其中一个用于处理写操作的主节点primary,还有多个用于保存主节点数据副本的从节点secondary.如果主节点崩溃了,则从节点会选取出一个新的主节点. 如果使用复制功能时有一台服务器停止运行了

  • MySQL数据库的高可用方案总结

    高可用架构对于互联网服务基本是标配,无论是应用服务还是数据库服务都需要做到高可用.虽然互联网服务号称7*24小时不间断服务,但多多少少有一些时候服务不可用,比如某些时候网页打不开,百度不能搜索或者无法发微博,发微信等.一般而言,衡量高可用做到什么程度可以通过一年内服务不可用时间作为参考,要做到3个9的可用性,一年内只能累计有8个小时不可服务,而如果要做到5个9的可用性,则一年内只能累计5分钟服务中断.所以虽说每个公司都说自己的服务是7*24不间断的,但实际上能做到5个9的屈指可数,甚至根本做不到

  • 基于mysql+mycat搭建稳定高可用集群负载均衡主备复制读写分离操作

    数据库性能优化普遍采用集群方式,oracle集群软硬件投入昂贵,今天花了一天时间搭建基于mysql的集群环境. 主要思路 简单说,实现mysql主备复制-->利用mycat实现负载均衡. 比较了常用的读写分离方式,推荐mycat,社区活跃,性能稳定. 测试环境 MYSQL版本:Server version: 5.5.53,到官网可以下载WINDWOS安装包. 注意:确保mysql版本为5.5以后,以前版本主备同步配置方式不同. linux实现思路类似,修改my.cnf即可. A主mysql.19

  • Redis为什么快如何实现高可用及持久化

    前言 作为Java程序员,在面试过程中,缓存相关的问题是躲不掉的,肯定会问,例如缓存一致性问题,缓存雪崩.击穿.穿透等.说到缓存,那肯定少不了Redis,我在面试的时候也是被问了很多关于Redis相关的知识,但是Redis的功能太强大了,并不是一时半会儿能掌握好的,因为有些高级特性或是知识平时并不会用到. 所以回答的不好,人家就会觉得你对自己平时使用的工具都没有了解,自然就凉凉了.其实很早就有这个打算,打算好好总结一下Redis的知识,但也是由于自己都没有好好的了解Redis呢,所以一直没有开始

  • redis三种高可用方式部署的实现

    前言 一.主从复制 概念 和mysql的主从复制一样 都是将服务器的数据复制到另一个数据库中 发送的称为master 接受的叫slave 数据为单向传输 只可以主到从 每台Redis服务器都是主节点:且一个主节点可以有多个从节点(或没有从节点),但一个从节点只能有一个主节点. 作用 数据冗余 实现了数据的热备份,是持久化之外的一种数据冗余方式 故障切换 当主节点宕机或者出现错误时 由从服务器来提供服务 实现故障切换 负载均衡:在主从复制的基础上,配合读写分离,可以由主节点提供写服务,由从节点提供

  • Redis高可用之持久化

    目录 一.高可用 什么是高可用 二.Redis持久化 持久化功能 RDB持久化 触发条件 bgsave执行流程 AOF持久化 执行流程 命令追加 文件写入和文件同步 文件重写 文件重写流程 三.RDB和AOF的优缺点 RDB持久化的优缺点 优点 缺点 AOF持久化优缺点 四.Redis性能管理 查看Redis内存使用 内存碎片率 内存碎片如何产生 跟踪内存碎片率 解决碎片率大的问题 内存使用率 内回收key 回收策略 五.Redis的优化 一.高可用 什么是高可用 在web服务器中,高可用是指服

  • Oracle和MySQL的高可用方案对比分析

    关于Oracle和MySQL的高可用方案,其实一直想要总结了,就会分为几个系列来简单说说.通过这样的对比,会对两种数据库架构设计上的细节差异有一个基本的认识.Oracle有一套很成熟的解决方案.用我在OOW上的ppt来看,是MAA的方案,今年是这个方案的16周年了. 而MySQL因为开源的特点,社区里推出了更多的解决方案,个人的见解,InnoDB Cluster会是MySQL以后的高可用方案标配. 而目前来看,MGR固然不错,MySQL Cluster方案也有,PXC,Galera等方案,个人还

  • keepalived实现nginx高可用

    keepalived直译就是保持存活,在网络里面就是保持在线了,也就是所谓的高可用或热备,用来防止单点故障(单点故障是指一旦某一点出现故障就会导致整个系统架构的不可用)的发生,keepalived实现的基础是vrrp,至于vrrp是什么请直接看这里vrrp,下面我们直接看应用吧. keepalived使用 为了方便使用,写了一个基于ubuntu 16.04 server 的一键配置脚本,配置使用相关就在脚本里见吧 #!/bin/bash # nginx+keepalived 高可用一键脚本for

  • Keepalived+HAProxy实现MySQL高可用负载均衡的配置

     Keepalived 由于在生产环境使用了mysqlcluster,需要实现高可用负载均衡,这里提供了keepalived+haproxy来实现. keepalived主要功能是实现真实机器的故障隔离及负载均衡器间的失败切换.可在第3,4,5层交换.它通过VRRPv2(Virtual Router Redundancy Protocol) stack实现的. Layer3:Keepalived会定期向服务器群中的服务器.发送一个ICMP的数据包(既我们平时用的Ping程序),如果发现某台服务的

随机推荐