网站后台数字排版该怎么做,莱州唯佳网络科技有限公司,产品宣传册设计网站建设,石家庄的网站公司一、前言 MongoDB 有三种集群架构模式#xff0c;分别为主从复制#xff08;Master-Slaver#xff09;、副本集#xff08;Replica Set#xff09;和分片#xff08;Sharding#xff09;模式。
Master-Slaver 是一种主从复制的模式#xff0c;目前已经不推荐使用。 Re…一、前言 MongoDB 有三种集群架构模式分别为主从复制Master-Slaver、副本集Replica Set和分片Sharding模式。
Master-Slaver 是一种主从复制的模式目前已经不推荐使用。 Replica Set 模式取代了 Master-Slaver 模式是一种互为主从的关系。Replica Set 将数据复制多份保存不同服务器保存同一份数据在出现故障时自动切换实现故障转移在实际生产中非常实用。 Sharding 模式适合处理大量数据它将数据分开存储不同服务器保存不同的数据所有服务器数据的总和即为整个数据集。
二、主从复制模式 Master-Slave 架构一般用于备份或者做读写分离一般是一主一从设计和一主多从设计。
Master-Slave 由主从角色构成
Master ( 主 )
可读可写当数据有修改的时候会将 Oplog 同步到所有连接的 Salve 上去。
Slave ( 从 )
只读所有的 Slave 从 Master 同步数据从节点与从节点之间不感知。
如图 2.1 主从复制对读写分离的思考
主从复制老生常谈的问题数据不一致的问题。
根本原因在于只有 Master 节点可以写Slave 节点只能同步 Master 数据并对外提供读服务当你查询 Slave 节点的数据时由于网络延迟等其它因素导致 Slave 节点还没有完全同步 Master 节点的数据这就会导致主从不一致跟 MySQL 的主从复制如出一辙只不过 MySQL 时 binlog 同步而 MongoDB 是 oplog 同步。
大多数情况主从不一致可以忽略不计但是对于关系型数据库来说如果存在长事物那么是可以的
2.2 主从复制对容灾的思考
当 Master 节点出现故障的时候由于 Slave 节点有备份数据可以通过人为 Check 和操作手动把 Slave 节点指定为 Master 节点这样又能对外提供服务了。
Master-Slave 只区分两种角色Master 节点Slave 节点 Master-Slave 的角色是静态配置的不能自动切换角色必须人为指定 用户只能写 Master 节点Slave 节点只能从 Master 拉数据 还有一个关键点Slave 节点只和 Master 通信Slave 之间相互不感知这种好处对于 Master 来说优点是非常轻量缺点是系统明显存在单点那么多 Slave 只能从 Master 拉数据而无法提供自己的判断
MongoDB 3.6 起已不推荐使用主从模式自 MongoDB 3.2 起分片群集组件已弃用主从复制。因为 Master-Slave 其中 Master 宕机后不能自动恢复只能靠人为操作可靠性也差操作不当就存在丢数据的风险。
三、副本集模式
3.1 副本集模式角色
副本集Replica Set是 mongod 的实例集合包含三类节点角色
Primary 主节点
只有 Primary 是可读可写的Primary 接收所有的写请求然后把数据同步到所有 Secondary 。一个 Replica Set 只有一个 Primary 节点当 Primary 挂掉后其他 Secondary 或者 Arbiter 节点会重新选举出来一个 Primary 节点这样就又可以提供服务了。
读请求默认是发到 Primary 节点处理如果需要故意转发到 Secondary 需要客户端修改一下配置注意是客户端配置决策权在客户端。
那有人又会想了这里也存在 Primary 和 Secondary 节点角色的分类岂不是也存在单点问题
这里和 Master-Slave 模式的最大区别在于Primary 角色是通过整个集群共同选举出来的人人都可能成为 Primary 人人最开始只是 Secondary 而这个选举过程完全自动不需要人为参与。
Secondary 副本节点
数据副本节点当主节点挂掉的时候参与选主。
思考一个问题Secondary 和 Master-Slave 模式的 Slave 角色有什么区别
最根本的一个不同在于Secondary 相互有心跳Secondary 可以作为数据源Replica 可以是一种链式的复制模式。
Arbiter 仲裁者
不存数据不会被选为主只进行选主投票。使用 Arbiter 可以减轻在减少数据的冗余备份又能提供高可用的能力。
如下图 3.2 为什么要使用副本集
3.2.1 高可用
防止设备服务器、网络故障提供自动 failover 功能技术来保证高可用
3.2.2 灾难恢复
当发生故障时可以从其他节点恢复用于备份。
3.2.3 功能隔离
我们可以在备节点上执行读操作减少主节点的压力比如用于分析、报表数据挖掘系统任务等。
3.3 副本集集群架构原理
一个副本集中Primary节点上能够完成读写操作Secondary节点仅能用于读操作。Primary节点需要记录所有改变数据库状态的操作这些记录保存在 oplog 中这个文件存储在 local 数据库各个Secondary 节点通过此 oplog 来复制数据并应用于本地保持本地的数据与主节点的一致。oplog 具有幂等性即无论执行几次其结果一致这个比 mysql 的二进制日志更好用。
oplog的组成结构
{ts : Timestamp(1446011584, 2),h : NumberLong(1687359108795812092),v : 2,op : i,ns : test.nosql,o : { _id : ObjectId(563062c0b085733f34ab4129), name : mongodb, score : 10}
}ts:操作时间当前timestamp 计数器计数器每秒都被重置
h:操作的全局唯一标识
v:oplog版本信息
op:操作类型i:插入操作u:更新操作d:删除操作 c:执行命令(如createDatabasedropDatabase)
n:空操作特殊用途
ns:操作针对的集合
o:操作内容
o2:更新查询条件,仅update操作包含该字段
副本集数据同步分为初始化同步和keep复制同步。初始化同步指全量从主节点同步数据如果Primary 节点数据量比较大同步时间会比较长。而keep复制指初始化同步过后节点之间的实时同步一般是增量同步。
初始化同步有以下两种情况会触发:
Secondary 第一次加入。 Secondary 落后的数据量超过了 oplog 的大小这样也会被全量复制。 MongoDB的Primary节点选举基于心跳触发。一个复制集N个节点中的任意两个节点维持心跳每个节点维护其他N-1个节点的状态。 心跳检测:
整个集群需要保持一定的通信才能知道哪些节点活着哪些节点挂掉。mongodb节点会向副本集中的其他节点每2秒就会发送一次pings包如果其他节点在10秒钟之内没有返回就标示为不能访问。每个节点内部都会维护一个状态映射表表明当前每个节点是什么角色、日志时间戳等关键信息。如果主节点发现自己无法与大部分节点通讯则把自己降级为secondary只读节点。
主节点选举触发的时机
第一次初始化一个副本集
Secondary节点权重比Primary节点高时发起替换选举 Secondary节点发现集群中没有Primary时发起选举 Primary节点不能访问到大部分(Majority)成员时主动降级 当触发选举时Secondary节点尝试将自身选举为Primary。主节点选举是一个二阶段过程多数派协议。
第一阶段:
检测自身是否有被选举的资格如果符合资格会向其它节点发起本节点是否有选举资格的 FreshnessCheck进行同僚仲裁。
第二阶段:
发起者向集群中存活节点发送Elect(选举)请求仲裁者收到请求的节点会执行一系列合法性检查如果检查通过则仲裁者(一个复制集中最多50个节点其中只有7个具有投票权)给发起者投一票。
pv0通过30秒选举锁防止一次选举中两次投票。
pv1使用了terms一个单调递增的选举计数器来防止在一次选举中投两次票的情况。
多数派协议:
发起者如果获得超过半数的投票则选举通过自身成为Primary节点。获得低于半数选票的原因除了常见的网络问题外相同优先级的节点同时通过第一阶段的同僚仲裁并进入第二阶段也是一个原因。因此当选票不足时会sleep[0,1]秒内的随机时间之后再次尝试选举。
四、分片模式
4.1 什么是分片
分片 (sharding) 是MongoDB用来将大型集合水平分割到不同服务器或者副本集上所采用的方法。 不需要功能强大的大型计算机就可以存储更多的数据处理更大的负载。
4.2 为什么要分片
存储容量需求超出单机磁盘容量。活跃的数据集超出单机内存容量导致很多请求都要从磁盘读取数据影响性能。IOPS超出单个MongoDB节点的服务能力随着数据的增长单机实例的瓶颈会越来越明显。副本集具有节点数量限制。
垂直扩展增加更多的CPU和存储资源来扩展容量。水平扩展将数据集分布在多个服务器上水平扩展即分片。
4.3 分片的工作原理 详细架构图
分片集群由以下3个服务组成:
Router Server: 数据库集群的请求入口所有请求都通过Router(mongos)进行协调不需要在应用程序添加一个路由选择器Router(mongos)就是一个请求分发中心它负责把应用程序的请求转发到对应的 Shard服务器上。mongos建议做一个HA,不然任何一个挂了对于集群都是打击 Shards Server: 每个shard由一个或多个mongod进程组成用于存储数据。 Config Server: 配置服务器。存储所有数据库元信息路由、分片的配置。
4.3.1 片键(shard key)
为了在数据集合中分配文档MongoDB使用分片主键分割集合。
4.3.2 区块(chunk)
在一个shard server内部MongoDB还是会把数据分为chunks每个chunk代表这个shard server内部一部分数据。MongoDB分割分片数据到区块每一个区块包含基于分片主键的左闭右开的区间范围。
4.3.3 分片策略
4.3.3.1 hash分片(Hashed Sharding)
把 Key 作为输入输入到一个 Hash 函数中计算出一个整数值值的集合形成了一个值域我们按照固定步长去切分这个值域每一个片叫做 Chunk 这里的 Chunk 则就是整数的一段范围而已。
优点
计算速度快均衡性好纯随机
缺点
正因为纯随机排序列举的性能极差比如你如果按照 name 这个字段去列举数据你会发现几乎所有的 Shard 都要参与进来
4.3.3.2 范围分片(Ranged Sharding) 优点
对排序列举场景非常友好因为数据本来就是按照顺序依次放在 Shard 上的排序列举的时候顺序读即可非常快速 缺点
容易导致热点举个例子如果 Sharding Key 都有相同前缀那么大概率会分配到同一个 Shard 上就盯着这个 Shard 写其他 Shard 空闲的很却帮不上忙
4.3.3.3 zone 分片(Zones in Sharded Clusters)
五、总结 本文介绍了 3 种 MongoDB 的高可用架构Master-Slave 模式Replica Set 模式Sharding 模式这也是常见的架构演进的过程是不是有点恍惚Redis 也是类似这种架构的演进。
MongoDB Master-Slave 已经不推荐甚至新版已经不支持这种冗余模式 Replica Set 通过数据多副本组件冗余提高了可靠性并且通过分布式自动选主算法减少了停服时间窗提高了可用性 Sharding 模式通过横向扩容的方式为用户提供了近乎无限的空间 MongoDB 客户端掌握了很大的配置权限通过指定写多数策略和 strong 模式只从主节点读数据能保证数据的高可靠和强一致性
六、搭建集群如何查看状态
1、mongo命令
用来连接MongoDB数据库 上图中是连接mongos服务器这里是指MongoDB路由服务器。 上图中是连接MongoDB分片集群的服务器是MongoDB中实实在在存储数据的服务器。
2、db命令
查看当前数据库的名称。 在上图中通过use命令可以切换到指定的数据库。
3、stats()函数 在上图中是在MongoDB路由服务器中运行db.stats()函数可以看到当前分片集群的情况可以知道MongoDB集群中有多少个分片每个分片中有多少个主从库其实每个分片就是一个副本集此外还可以知道每个分片中有多少个集合、索引、数据量大小等。 在上图中是在分片服务器中运行db.stats()函数可以看到当前分片服务器中当前数据库的情况。
4、status()函数 在上图中是在MongoDB路由服务器中运行rs.status()函数时的情况通过提示可以知道在mongos中是不能运行rs.status()函数的。不过该函数可以在分片服务器上使用如下图所示 通过上述几张截图可以知道当前分片中副本集的部署情况知道哪个是主库其余的就都是从库并且还知道主从库当前运行情况例如可访问或者不能访问。 参考
https://blog.csdn.net/riemann_/article/details/134024634
https://www.cnblogs.com/bien94/p/13095258.html
