2019/08/15 数据库分片的概念及mongodb sharding的实现(04)~1-白红宇

2019/08/15 数据库分片的概念及mongodb sharding的实现(04)~1

阅读量：3925 次

发布时间：2019-05-23

本文共 5005 字，大约阅读时间需要 16 分钟。

在这里插入图片描述

对于副本集核心的两个工具，oplog，heatbeat
副本集至少需要三个节点，其中一个节点纯粹做仲裁

现在尝试用三个节点部署副本集，node1,2，3 ，172.。7、8、9

先把刚才的mongodb服务停掉 在这里插入图片描述

副本集名字至关重要，决定每个节点加入到到底哪个副本集

**有多个mongodb节点，副本集可能不止一个，所以区别是哪个副本集的只有replset，类似集群名称 ** 在这里插入图片描述

副本集的索引预取，none 不取任何索引，id only（每个collection默认就有id字段，id是作为collection中的主键的，这是由mongodb自行维护的），只取id，定义也没关系，只在从节点有效
all

加上replset就代表要加入副本集，启动会加oplog

重启，进入mongod的shell接口，现在还不知道谁是主节点，没做初始化 在这里插入图片描述

先把文件复制到其他两个节点上 在这里插入图片描述

在其他节点上先安装包 在这里插入图片描述

创建数据目录 在这里插入图片描述

把主机的配置文件复制到其他节点上 在这里插入图片描述

直接启动服务 在这里插入图片描述

创建副本集以后，相关命令是rs开头 在这里插入图片描述

获取副本集当前状态信息 在这里插入图片描述

把当前副本做初始化 在这里插入图片描述

指定的配置文件对当前副本做初始化 在这里插入图片描述

获取当前rs的配置信息，null表示我们没有做初始化 在这里插入图片描述

提示你需要做初始化 在这里插入图片描述

使用initiate做初始化 在这里插入图片描述

members是显示所有副本集的成员信息，是一个列表，列表里有文档描述相关节点的状态
id节点的标识符，name对应节点名称，health健康状态，statstr状态字串，primary主节点，second从节点
uptime运行时长，optime最近一次oplog操作的时间戳，electiontime 选举时间，electiondatae 选举日期，self，是否是当前节点

添加节点进来，可以指定主机或者object，可以给一大串stat信息也可以给个地址

添加主机只需要指定ip+端口

starkup 2表示去追赶主节点了

追赶成功了就显示secondary 在这里插入图片描述

到node2上看看，testdb就有了 在这里插入图片描述

不是主节点，也没有slave=ok不让查询，从节点默认不让查
运行下面选项即可在这里插入图片描述

主节点有了，用ping的方式传送心跳信息，1s

查看node2节点是否是主节点，第二节点实现了slave ok了，就可以使用查询 在这里插入图片描述

获取第一个数据 在这里插入图片描述

加入第三个节点 在这里插入图片描述

已经成为secondary 在这里插入图片描述

试试查询

conf显示配置信息，version随着你的改变会增加，写操作不能在从节点上执行 在这里插入图片描述

在主节点上生成一个新的数据库试试 在这里插入图片描述

在从节点查询试试 在这里插入图片描述

在从节点上是不允许插入的 在这里插入图片描述

conf显示当前配置信息
members列表在这里插入图片描述

https://docs.mongodb.com/manual/reference/replica-configuration/{

_id: ,

version: ,

protocolVersion: ,

writeConcernMajorityJournalDefault: ,

configsvr: ,

members: [

{

_id: ,

host: ,

arbiterOnly: , 当前是否是仲裁节点

buildIndexes: , 是否去构建索引

hidden: ,是不是一个隐藏节点

priority: , 被选举的优先级

tags: , 当前文档标识

slaveDelay: , 延迟复制的从节点

votes:

…

settings: {

chainingAllowed : , 是否做链接式轮循

heartbeatIntervalMillis : ,

heartbeatTimeoutSecs: ,获取心跳信息的超时时间

electionTimeoutMillis : ,

catchUpTimeoutMillis : ,

getLastErrorModes : ,获取最近一次错误信息的方式

getLastErrorDefaults : , 获取最新一次的错误信息

replicaSetId:

}

就是保存在local.system,replset下的id 在这里插入图片描述

members有很多属性
n.host设定它的主机名在这里插入图片描述

设定是否是仲裁节点的 在这里插入图片描述

支持链式复制的。一个从节点可以指向另外的从节点 在这里插入图片描述

一般副本集replicaset将会使用写操作，得到最后的错误状态信息，一般使用默认 在这里插入图片描述

偶尔进行手动设定 在这里插入图片描述

现在把主节点宕机，从节点找不到主的，10s会找出新的主 在这里插入图片描述

让自己临时链接不上去 在这里插入图片描述

现在第二个从是主的

选举新的主节点考虑的因素有很多，包括优先级，以及oplog大小，
保存范围是140s 在这里插入图片描述

第一个事件产生时间，最后的产生时间
now 当前时间

从节点的时间应该跟主节点一致 在这里插入图片描述

副本集支持失效转移，默认每隔两S给其他节点发送心跳信息，通告自己处于健康状态
health=1表示健康

随便找个节点下线，其他节点10s没有收到心跳信息 在这里插入图片描述

状态为0

再次启动

应该health为1

影响选举的条件：

心跳信息
优先级（优先级一样就看其他条件，0没有被选举权，一个节点优先级过高，也可以触发选举重新上台）
optime（某成员节点，最近一次应用于本地oplog，条目的时间戳，比其他节点慢的不可能成为主的，因为成为主的其他节点等于多数据了）成为主节点的optime一定是最新的
网络链接（一旦发生分区以后，拥有票数多，超过法定票数一半的的一方，继续使用副本集的一方，票数多的重新选取主节点）
网络分区，主节点离线，副节点分为多个网络部分，任何部分需要通过法定票数来选主节点和网路链接概念相同

选举机制：（能够触发选举的条件）

新副本集初始化时
从节点联系不到主节点时
主节点"下台"时
（主节点下台，会关闭副本集写请求，保证数据一致）
主节点收到stepdown()命令时，下台
某从节点有更高的优先级且已经满足成主节点其他所有条件
主节点无法联系导副本集的"多数方" 在这里插入图片描述

如果1的节点计算机性能较好，期望它优先成为主节点
现在把2的节点优先级变高
设置个cfg变量先保存当前配置在这里插入图片描述

通过cfg来设置 在这里插入图片描述

需要生效，重新配置，读取刚才的配置，提示你的操作必须在主节点 在这里插入图片描述

已经改变了 在这里插入图片描述

想让第三个节点成为仲裁节点 在这里插入图片描述

直接被加进来就是仲裁节点
或者修改为仲裁节点

现在把第三个节点设定为仅仲裁的节点 在这里插入图片描述

应该是节点已经复制导数据，不允许这么做 在这里插入图片描述

只能先移除这个节点

这个方法可以查看每个从节点是否落后于主节点 在这里插入图片描述

在指定时间范围内，不允许一个节点选举成为主的，冻结 在这里插入图片描述

mongodb的分片功能

（单个节点IO出现瓶颈，CPU,Memory,IO）把数据放在多个节点来实现，把数据切块每个放一部分数据
mysql也支持分片的：（Gizzard,HiveDB,my sql proxy+HSACLE,Hibernate，Shard,Pyshards，需要借助外部工具实现）
sharding，mongodb自动实现分片在这里插入图片描述

分片架构

有三个组件，router（相当于框架，mongos，2个是为了做冗余的）用户请求都到mongos，把用户请求路由到合适的分片上来执行，

分片中的架构角色有三个，

mongos：router
config server 元数据服务器，存储集群元数据的
shard 各分片节点，mongod节点，也称mongod实例，负责将用户请求的数据或响应给客户端的

mogilfs的客户端是自己联系各存储节点的，先去找trunk，trunk告诉它哪个节点有，客户端再去找节点

每个shard就是个复制集，每个shard至少有三个节点，config server也需要三个节点（不然挂了，整个集群挂了）

要借助zookeeper，能实现选举机制，并决定最终谁是主节点的，通常用来分布式节点的协调，zookeeper可以自行内部构成三个节点自动选举的
router 要高可用，可以用keepalived

shard主要目的就是让数据分散在多个shard上的，较大的数据即切割成片，一个collection会被切割成大小固定的块，类似raid，可以按照64M块来分一个个节点上，config server按照索引来分配数据，比如0-20的放1，20-40的放2.如果0-20的人过多，第一个节点存储的块就多，就缩减索引，比如1节点改成0-15的，2 节点改成15-30的。所以每一次数据均衡可能全局都要动的
(mysql的分片框架也是在某个表上以某个字段为例，在这个索引当作分片的元数据，而后大数据切割成trunk，把trunk平均分配到其他节点上去)

config server是放的元数据，但是不能对所有的数据字段进行索引，所以构建索引的时候，只是对有限的几个字段做索引，真正分片的时候就是根据你的索引来分片，索引判断告诉config server有几个shard节点，索引尝试把索引每个数据开始做平均分隔，平均完以后，做shard ABCD，分隔以后，把原始数据分隔成trunk，而后存储到shard节点，

索引有索引类型，不太的索引类型，分法是不一样的

BTREE是一种排序索引，是一个连续的区间
根据业务模型选择（一个方针，分片以后，写要离散，读集中）
基于范围进行分片：
range
基于列表切片
list列表，离散值（省份）
基于hash切片
hash 在这里插入图片描述