生产环境不建议仅使用PRIMARY-SECONDARY模式 当primary挂掉,并且无法恢复时,可以把secondary提升为主节点. 注意:此时从节点可能有部分数据未同步过来,部分数据可能丢失. 1.在secondary节点删除挂掉的primary节点 使用rs.conf查看当前配置 c = rs.conf() 输出内容: { "_id" : "rd_repl", "version" : 133334, "protocolVersi

http://blog.itpub.net/26812308/viewspace-2124660/ 在Replica sets 中的secondary节点默认是不可读的.使用Replica Sets实现读写分离.通过在连接时指定或者在主库指定slaveOk,由Secondary来分担读的压力,Primary只承担写操作. 在secondary上,访问mongo,进行查询.会出现如下错误: rs:SECONDARY> db.sponsor.find();Error: error: { "ok

在Altera的一些IP文档上,提到IP的资源使用情况时,会有primary logic register和secondary logic register这样的术语. 那么什么是primary/secondary logic register呢? Primary registers are the core logic registers; Secondary registers are the implementation, routing and timing closure optimi

本文整理了一年多以来我常用的MongoDB操作,涉及mongo-shell.pymongo,既有运维层面也有应用层面,内容有浅有深,这也就是我从零到熟练的历程. MongoDB的使用之前也分享过一篇,稍微高阶点:见这里:<MongoDB使用小结> 1.shell登陆和显示 假设在本机上有一个端口为17380的MongoDB服务,假设已经把mongo bin文件加入到系统PATH下. 登陆:mongo --port 17380 显示DB:show dbs 进入某DB:use test_cswuy

副本集(Replica Set)是一组MongoDB实例组成的集群,由一个主(Primary)服务器和多个备份(Secondary)服务器构成.通过Replication,将数据的更新由Primary推送到其他实例上,在一定的延迟之后,每个MongoDB实例维护相同的数据集副本.通过维护冗余的数据库副本,能够实现数据的异地备份,读写分离和自动故障转移. 一,MongoDB版本和环境 在Windows上创建包含三个节点的副本集,使用的环境: 数据库:MongoDB 版本 3.2.9 Server

本文整理了一年多以来我常用的MongoDB操作,涉及mongo-shell.pymongo,既有运维层面也有应用层面,内容有浅有深,这也就是我从零到熟练的历程. MongoDB的使用之前也分享过一篇,稍微高阶点:见这里:<MongoDB使用小结> 1.shell登陆和显示 假设在本机上有一个端口为17380的MongoDB服务,假设已经把mongo bin文件加入到系统PATH下. 登陆:mongo --port 17380 显示DB:show dbs 进入某DB:use test_cswuy

今天,在某个演示环境中,我们的产品经历过整个机房断电后,出现了mongodb二进制文件损坏,以下是故障的分析记录过程: 1.在客户处支撑的同事发现整个机房断电再恢复后,3个mongodb复制集中,有1个主机上的mongodb服务状态报错 2.登录后台发现复制集中每个mongodb主机上,mongod进程都在 3.在服务状态好着的mongodb主机上,通过mongo登录数据库,查询复制集状态,发现复制集状态正常,1个primary+2个secondary,并且optimeDate时间一致. 这个时

什么是选举? 选举是副本集选择某个成员成为primary的过程.primary是一个副本集中唯一能够接收写操作的成员. 下面的事件能够引发一次选举: 第一次初始化一个副本集 Primary失效.replSetStepDown命令能够使Primary失效,或者当前secondary成员中有合适的选举者且优先级更高.当Primary与集合中的大多数成员失去联系时也会失效,它会关闭所有的客户端连接,以此防止客户端向一个没有primary成员写数据. 一个secondary成员于primary失去联系.

自我学习,仅供参考: 数据库总是会遇到各种失败的场景,如网络连接断开.断电等,尽管journaling日志功能也提供了数据恢复的功能,但journaling通常是针对单个节点来说的,只能保证单节点数据的一致性,而复制集通常是由多个节点组成,每个节点除了journaling日志恢复功能外,整个复制集还具有故障自动转移的功能,这样能保证数据库的高可用性.在生产环境中一个复制集最少应该包含三个节点,其中有一个必须是主节点,典型的部署结构如下图: 其中每个节点都是一个mongod进程对应的实例,节点之间

前面几篇文章的分析复制集解决了数据库的备份与自动故障转移,但是围绕数据库的业务中当前还有两个方面的问题变得越来越重要.一是海量数据如何存储?二是如何高效的读写海量数据?尽管复制集也可以实现读写分析,如在primary节点上写,在secondary节点上读,但在这种方式下客户端读出来的数据有可能不是最新的,因为primary节点到secondary节点间的数据同步会带来一定延迟,而且这种方式也不能处理大量数据.mongoDB从设计之初就考虑了上面所提到的两个问题,引入了分片机制,实现了海量数据的分

1.profile profiling levels: 0,关闭profile:1,只抓取slow查询:2,抓取所有数据. 启动profile并且设置Profile级别: 可以通过mongo shell启动,也可以通过驱动中的profile命令启动,启动后记录会被保存在system.profile collection下,可以使用db.setProfilingLevel来启动.默认slow为100   毫秒.db.setProfilingLevel可以有2个参数,第一个参数指定Profiling

8 复制 Mongodb Manual阅读笔记:CH2 Mongodb CRUD 操作Mongodb Manual阅读笔记:CH3 数据模型(Data Models)Mongodb Manual阅读笔记:CH4 管理Mongodb Manual阅读笔记:CH5 安全性Mongodb Manual阅读笔记:CH6 聚合Mongodb Manual阅读笔记:CH7 索引Mongodb Manual阅读笔记:CH8 复制集Mongodb Manual阅读笔记:CH9 Sharding 8 复制 8.1

MongoDB分布式集群 MongDB分布式集群能够对数据进行备份,提高数据安全性,以及提高集群提高读写服务的能力和数据存储能力.主要通过副本集(replica)对数据进行备份,通过分片(sharding)对大的数据进行分割,分布式存储在不同节点上. 副本集(replica) 副本集由若干台服务器组成,分为三种角色:主服务器.副服务器.仲裁服务器.根据集群搭建的需求,仲裁服务器不是必需的.主服务器提供主要的对外读写的功能,副服务器作为备份.当主服务器不可用时,其余服务器根据投票选出一个新的主服务

Read Preferences/读写分离 有时候为了考虑应用程序的性能或响应性,为了提高读取操作的吞吐率,一个常见的措施就是进行读写分离,MongoDB副本集对读写分离的支持是通过Read Preferences特性进行支持的,这个特性非常复杂和灵活.以下几种应用场景可能会考虑对副本集进行读写分离: 1)操作不影响前端应用程序,比如备份或者报表: 2)在一个物理上分布的副本集群中,为了减少应用程序的延迟,可能会优先选择离应用程序更近的secondary节点而不是远在千里之外机房的主节点: 3)

概念: 在了解了这篇文章之后,可以进行该篇文章的说明和测试.MongoDB 副本集(Replica Set)是有自动故障恢复功能的主从集群,有一个Primary节点和一个或多个Secondary节点组成.类似于MySQL的MMM架构.更多关于副本集的介绍请见官网.也可以在google.baidu上查阅. 副本集中数据同步过程:Primary节点写入数据,Secondary通过读取Primary的oplog得到复制信息,开始复制数据并且将复制信息写入到自己的oplog.如果某个操作失败,则备份节点

一.副本集基本概念 副本集(replica set) MongoDB的replica set是一个mongod进程实例簇,数据在这个簇中相互复制,并自动进行故障切换. MongoDB的数据库复制增加了冗余,确保了高可用性,简化了管理任务如备份,并且增加了读能力.大多数产品部署都使用了复制.MongoDB中primary处理写操作,其它进行复制的成员则是secondaries. 一个副本集可以最多支持12个成员,但是只有7个成员可以参与投票. 注:MongoDB同时提供了传统的master/sla

http://www.cnblogs.com/guoyuanwei/p/3279572.html  概述了复制集,整体上对复制集有了个概念,但是复制集最重要的功能之一数据同步是如何实现的?带着这个问题,下面展开分析. 先利用mongo客户端登录到复制集的primary节点上. >mongo --port 40000 查看实例上所有数据库 rs0:PRIMARY> show dbs local   0.09375GB 可以看到只有一个local数据库,因为此时还没有在复制集上创建任何其它数据库,

1.mongoDB节点介绍 主节点(Primary) 在复制集中,主节点是唯一能够接收写请求的节点.MongoDB在主节点进行写操作,并将这些操作记录到主节点的oplog中.而从节点将会从oplog复制到其本机,并将这些操作应用到自己的数据集上.(复制集最多只能拥有一个主节点) 从节点(Secondaries) 从节点通过应用主节点传来的数据变动操作来保持其数据集与主节点一致.从节点也可以通过增加额外参数配置来对应特殊需求.例如,从节点可以是non-voting或是priority 0. 仲裁节

MongoDB 的replication机制除了最普通的Master/Slave模式之外,更强大的就是其支持自动故障转移的Replica Sets模式了.相对于其问题多多的auto-sharding机制,Replica Sets还是相对比较稳定. 作为MongoDB使用大户,Foursquare(简称4sq) 在MongoDB使用上有相当丰富的经验,下面是4sq的一篇文章,描述了Replica Sets机制在4sq 中的几种架构方式. 原文链接:Fun with MongoDB replica

Replica Set 选举过程 心跳检测 假设我们有三个节点的replica sets:X,Y和Z节点.在replica sets结构中,这三个节点每2秒会各自向其它两个节点发送一个心跳检测请求.比如X节点向Y和Z节点各发送了一个心跳检测请求,在正常情况下,Y.Z会返回一个包含自身信息的回复包,回复包中主要包括了下面一些信息:它们现在是什么角色(primary 还是 secondary),他们是否能够在必要的时候成为 primary,以及他们当前时钟时间等等. X节点在收到回复包后,会用这些信

我们知道,MongoDB不提供单机的数据安全性,取而代之的是提供了Replica Sets的高可用方案.官方文档中提到的案例是三个节点组成的Replica Sets,这样在其中任何一个节点宕机后都会自动选举出新的Primary提供写操作.而下面要提到的是一个大家可能忽略的问题. 配置方法 两个节点的Replica Sets,启动后一个选举成为Primary,一个成为Secondary. 问题 这时候如果Secondary宕机,那么Primary会怎么样呢?Primary会立刻变成Secondar