现象: 机房反馈9点左右,机房交换机故障,导致网络出现问题 业务人员反馈某个接口超时 初查:通过业务日志查看分析发现,在连接mongo的某个collections时候,报错错误如下: 在写入数据的时候报错: Mongo::Error::OperationFailure - no progress was made executing batch write op rounds ( ops completed rounds total) (): 因此初步确定问题出在mongo分片集群上 进入mon

1.MSC添加shard节点 mkdir -p /mongodb/38027/conf  /mongodb/38027/log  /mongodb/38027/datamkdir -p /mongodb/38028/conf  /mongodb/38028/log  /mongodb/38028/datamkdir -p /mongodb/38029/conf  /mongodb/38029/log  /mongodb/38029/datacat >  /mongodb/38027/conf/m

Shard部署 准备测试环境 为准备数据文件夹 Cd  /home/tiansign/fanr/mongodb/Shard mkdir configdb1 configdb2 configdb3 mkdir shard1 shard2 shard3 mkdir mongos 准备配置文件 为Config准备配置文件 dbpath=/home/tiansign/fanr/mongodb/Shard/configdb1 fork = true logpath=/home/tiansign/fanr/

最近项目会用到mongodb的oplog触发业务流程,开发时的debug很不方便.所以在本地创建一个单台mongodb 集群进行开发debug. 大概:mongodb可以产生oplog的部署方式应该是两种,一种是replica set ,一种是shard;项目中使用的的shard,所以参照文档本地部署了单节点shard集群-只为debug. 根据文档整理的内容包含三部分: 1.配置文件 配置文件有三个,分别是config.conf,shard.conf,mongos.conf;一下是内容 #co

在进行副本集部署时我们会添加一个或多个仲裁节点,仲裁节点不用于备份数据,由于它职责的职责是负责选举主节点,所以对硬件没有太高要求,可以将它部署在单独的服务器上,这个服务器可以是监听服务器,也可以部署在虚拟机上,但是有一点仲裁节点一定不能备份数据．仲裁节点和注解点都可以参与选举,而选举对象是各个非投票成员,也就是需要备份数据的从节点． 图列 这让我想起了以前了解过的zookeeper集群中的选举方案,它和MongoDB有所不同． ZooKeeper采用一种称为Leader election的选举算

设备: 三个1G.20G.1核的虚拟机,系统是SentOS7 min 清除原始自数据目录: rm -fr /home/mongosingle/ 创建目录: mkdir -p /home/mongosingle/data/replset   启动服务: Server1: /usr/local/mongodb/bin/mongod --shardsvr --replSet replyset --port 27020 --dbpath /home/mongosingle/data/replset  -

Mongodb5节点异地两中心故障转移恢复测试案例 架构方式:5节点,主中心(2数据1仲裁),备中心(1数据1仲裁) 1基本情况 操作系统:Red Hat Enterprise Linux Server release 6.3 (Santiago) Mongodb版本:db version v3.6.3 Mongodb架构: Ip,端口规划 "hosts" : [##数据节点 "10.15.7.114:28001",#主中心 "10.15.7.114:28

今天由于kafka集群搭建时的配置不当,由于一台主消费者挂掉(服务器崩了,需要维修),导致了所有新版消费者(新版的offset存储在kafka)都无法拉取消息. 由于是线上问题,所以是绝对不能影响用户的,使用老版客户端(offset存储在zk)进行消费,然后将kafka迁移到备用服务. 下面来说一下这次事故的具体处理思路 首先要确保获取到的消息不能丢失,所以老版消费者进行消费 线上服务通过均衡负载一台一台的进行切换kafka服务,当原生产者数据都消费完时,将消费者切换到备用服务 开始配置线上ka

1.查看集群中各节点的状态: rs0:PRIMARY> rs.status() 2.查看集群中各节点配置情况: rs0:PRIMARY> rs.conf() 3.主节点降级为从节点: rs0:PRIMARY> rs.stepDown() 4.将从节点添加至集群中: rs0:PRIMARY> rs.add("172.16.1.31:27017") 5.从集群中移除从节点: rs0:PRIMARY> rs.remove("172.16.1.31:27

简述 为何要分片 减少单机请求数,降低单机负载,提高总负载 减少单机的存储空间,提高总存空间. 常见的mongodb sharding 服务器架构 要构建一个 MongoDB Sharding Cluster,需要三种角色: Shard Server 即存储实际数据的分片,每个Shard可以是一个mongod实例,也可以是一组mongod实例构成的Replication Set.为了实现每个Shard内部的auto-failover(自动故障切换),MongoDB官方建议每个Shard为一组Re

1 , node 的 数量 应该大于等于 副本(指的是单个 shard 的 主副本+备份副本数)的 数量 ,如果 副本的数量大于 node 数量,那么 一个node 必定有2 个相同的 副本,这个多出来的副本毫无意义.(如果是为了提高效率,可以提高 切片的 个数 ) 2 ,因为 副本 shard  和 主 shard  不会出现在同一个 节点上 ,那么 一 挂一个节点 最多挂掉一个 shard  的 一个副本. 3,所以要保证的 50% 的 节点挂了 数据不丢的  最低副本数数 = 节点数*50

写在前面的话 上一节的复制集也就是主从能够解决我们高可用和数据安全性问题,但是无法解决我们的性能瓶颈问题.所以针对性能瓶颈,我们需要采用分布式架构,也就是分片集群,sharding cluster! 架构说明 架构规划: 我们这里准备了 4 台虚拟机:192.168.200.101-104 在分片集群中,mongodb 包含以下三个角色:mongos(router),config server,shard. mongos 节点:用于服务连接,不存数据,有点像路由器. config server

MongoDB在单节点中也可以做复制集,但是仅限于测试实验,最大的好处就是部署方便快速,可以随便添加新节点,节省资源.在这里我使用的是MongoDB 3.2版本进行复制集实验(但MongoDB配置文件使用的是老版本格式),一共使用三个节点,一个是主节点(PRIMARY),一个是从节点(SECONDARY),一个是投票节点(ARBITER).如下图: 一.实验环境 1)节点信息:192.168.60.10 3)节点确保iptables和selinux已关闭   1 2 [root@node1 ~]

MongoDB在单节点中也可以做复制集,但是仅限于测试实验,最大的好处就是部署方便快速,可以随便添加新节点,节省资源.在这里我使用的是MongoDB 2.6版本进行复制集实验(但MongoDB配置文件使用的是老版本格式),一共使用三个节点,一个是主节点(PRIMARY),一个是从节点(SECONDARY),一个是投票节点(ARBITER).如下图: 一.实验环境 1)节点信息:192.168.60.60 3)节点确保iptables和selinux已关闭   1 2 [root@node1 ~]

场景描述 MongoDB副本集中有一台Secondary节点出现RECOVERING的状态 状态如下: arps:RECOVERING> rs.status() { "set" : "arps", "date" : ISODate("2017-12-22T02:31:58.803Z"), "myState" : 3, "members" : [ { "_id"

1.相对于传统主从模式的优势 传统的主从模式,需要手工指定集群中的Master.如果Master发生故障,一般都是人工介入,指定新的Master.这个过程对于应用一般不是透明的,往往伴随着应用重新修改配置文件,重启应用服务器等. 而MongoDB副本集,集群中的任何节点都可能成为Master节点.一旦Master节点故障,则会在其余节点中选举出一个新的Master节点.并引导剩余节点连接到新的Master节点.这个过程对于应用是透明的. 2. Bully选举算法 Bully算法是一种协调者(主节

Docker方式部署 为了避免过分冗余,并且在主节点挂了,还能顺利自动提升,所以加入仲裁节点 mongodb版本: 环境:一台虚拟机 三个configsvr 副本: 端口为 27020,27021,27022 两个分片: shard1:-> 三个副本,端口为 27010,27011,27012 shard2:-> 三个副本,端口为 27013,27014,27015 一个路由:mongos -> 端口为 27023 前置条件: 创建数据存储文件的目录 mkdir /usr/local/m

1.分片的原理概述 分片就是把数据分成块,再把块存储到不同的服务器上,mongodb的分片是自动分片的,当用户发送读写数据请求的时候,先经过mongos这个路由层,mongos路由层去配置服务器请求分片的信息,再来判断这个请求应该去那一台服务器上读写数据. 2.分片的条件 1):服务器磁盘不够的时候 2):服务器出现写瓶颈的时候 3):想将大量数据放在内存中提高性能 3.分片中的角色,有三种: 1):配置服务器:存放分片信息,分片的数据与片的关系 2):mongos路由:是一个路由进程,把所有对

5.1.MongoDB 用户管理 1.用户管理1.1.添加用户为 testdb 添加 tom 用户 use testdb db.createUser({user:"tom",pwd:"123",roles:[{ role:"dbAdmin",db:"testdb"}]}) 具体角色有read:允许用户读取指定数据库readWrite:允许用户读写指定数据库dbAdmin:允许用户在指定数据库中执行管理函数,如索引创建.删除,查

前面的文章介绍了Mongodb的安装使用,在 MongoDB 中,有两种数据冗余方式,一种 是 Master-Slave 模式(主从复制),一种是 Replica Sets 模式(副本集). Mongodb一共有三种集群搭建的方式: Replica Set(副本集). Sharding(切片) Master-Slaver(主从)[目前已不推荐使用了!!!] 其中,Sharding集群也是三种集群中最复杂的. 副本集比起主从可以实现故障转移!!非常使用! mongoDB目前已不推荐使用主从模式,取