副本集

在上一篇文章《搭建高可用mongodb集群（二）—— 副本集》 介绍了副本集的配置，这篇文章深入研究一下副本集的内部机制。还是带着副本集的问题来看吧！ 副本集故障转移，主节点是如何选举的？能否手动干涉下架某一台主节点。 官方说副本集数量最好是奇数，为什么？ mongodb副本集是如何同步的？如果同步不及时会出现什么情况？会不会出现不一致性？ mongodb的故障转移会不会无故自动发生？什么条件会触发？频繁触发可能会带来系统负载加重？ Bully算法 mongodb副本集故障转移功能得益于它的选举机制。选举机制采用了Bully算法，可以很方便从分布式节点中选出主节点。一个分布式集群架构中一般都有一个所谓的主节点，可以有很多用途，比如缓存机器节点元数据，作为集群的访问入口等等。主节点有就有吧，我们干嘛要什么Bully算法？要明白这个我们先看看这两种架构： 指定主节点的架构，这种架构一般都会申明一个节点为主节点，其他节点都是从节点，如我们常用的mysql就是这样。但是这样架构我们在第一节说了整个集群如果主节点挂掉了就得手工操作，上架一个新的主节点或者从从节点恢复数据，不太灵活。 mongodb4 不指定主节点，集群中的任意节点都可以成为主节点。mongodb也就是采用这种架构，一但主节点挂了其他从节点自动接替变成主节点。如下图： mongodb故障转移 好了，问题就在这个地方

在上一篇文章 《搭建高可用MongoDB集群（一）——配置MongoDB》 提到了几个问题还没有解决。 主节点挂了能否自动切换连接？目前需要手工切换。 主节点的读写压力过大如何解决？ 从节点每个上面的数据都是对数据库全量拷贝，从节点压力会不会过大？ 数据压力大到机器支撑不了的时候能否做到自动扩展？ 这篇文章看完这些问题就可以搞定了。NoSQL的产生就是为了解决大数据量、高扩展性、高性能、灵活数据模型、高可用性。但是光通过主从模式的架构远远达不到上面几点，由此MongoDB设计了副本集和分片的功能。这篇文章主要介绍 副本集 ： mongoDB官方已经 不建议使用主从模式 了，替代方案是采用副本集的模式， 点击查看 ，如图： 那什么是副本集呢？打魔兽世界总说打副本，其实这两个概念差不多一个意思。游戏里的副本是指玩家集中在高峰时间去一个场景打怪，会出现玩家暴多怪物少的情况，游戏开发商为了保证玩家的体验度，就为每一批玩家单独开放一个同样的空间同样的数量的怪物，这一个复制的场景就是一个副本，不管有多少个玩家各自在各自的副本里玩不会互相影响。 mongoDB的副本也是这个，主从模式其实就是一个单副本的应用，没有很好的扩展性和容错性。而副本集具有多个副本保证了容错性，就算一个副本挂掉了还有很多副本存在，并且解决了上面第一个问题“主节点挂掉了，整个集群内会自动切换”

一、环境 $ cat /etc/redhat-release CentOS Linux release 7.0.1406 (Core) $ uname -a Linux zhaopin-2-201 3.10.0-123.el7.x86_64 #1 SMP Mon Jun 30 12:09:22 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux $ mongo MongoDB shell version: 3.0.6 connecting to: test rs0:PRIMARY> rs.status(); { "set" : "rs0", "date" : ISODate("2015-09-28T07:00:05.507Z"), "myState" : 1, "members" : [ { "_id" : 0, "name" : "172.30.2.201:27017", "health" : 1, "state" : 1, "stateStr" : "PRIMARY", "uptime" : 83, "optime" : Timestamp(1443423600, 1), "optimeDate" : ISODate("2015-09-28T07:00:00Z"), "electionTime" : Timestamp(1443423535, 2),

主要流程 MongoDB 2.8 版本特性与功能 MongoDB 在赶集网的应用 MongoDB 最佳实践 MongoDB 2.8 版本特性与功能 TJ MongoDB 开发者 TJ 强调 MongoDB 没有实际意义上的锁，只有 Latch，门栓。 2.6 库级锁 Latch，没有 Lock，写内存的一刹那锁住内存 2.8 无锁的 MVCC 并发，WIREDTIGER，snapshot isolation 2.6 MMAP 内存映射，库级锁 2.8 MMAP 集合级锁 2.8 WIREDTIGER 无锁 WIREDTIGER 存储模式 LSM(HBASE, Cassandra) - Log Structured Merge B-TREE LSM 数据写内存，异步写硬盘 读性能有问题，性能一般 高并发写应用场景 压缩算法 SNAPPY - 默认压缩方式，速度快，压缩率OK，32k cache 压缩 ZLIB - 压缩率高，占用 CPU 高，随时压缩，凑够 32k 落盘 更大的复制集群数: 12 - 50 2.6 Logging 控制 2.8 Logging 可控制 更新的工具集 Go 语言重写 多线程 支持输入校验 增强的导入导出性能 运维 OpsManager 监控，备份，集群管理 MongoDB 最佳实践 京东 DBA 复制集 分片架构 监控和备份 MS 不支持读写分离，不支持