MongoDB replicaSet
MongoDB 的replication机制除了最普通的Master/Slave模式之外，更强大的就是其支持自动故障转移的Replica Sets模式了。相对于其问题多多的auto-sharding机制，Replica Sets还是相对比较稳定。
作为MongoDB使用大户，Foursquare（简称4sq） 在MongoDB使用上有相当丰富的经验，下面是4sq的一篇文章，描述了Replica Sets机制在4sq 中的几种架构方式。
原文链接：Fun with MongoDB replica sets
1.在原有的Master/Slave 机制上添加一台arbiter
4sq 在早期有一些Master/Slave的MongoDB架构，但这种模式不能实现自动的故障转移，需要在发生故障时手动进行切换。在Replica Sets出现后，这种结构被迁移成为三台机器的Replica Sets：一台Primary，一台Secondary，一台Arbiter。
迁移过程：
修改Master和slave的配置，添加如下几项，并重启MongoDB。
replSet = auxdb
fastsync = true
rest = true
fastsync 使得重启动可以使用到原来的数据文件，重启会非常快。然后再在Primary上用rs.add 和 rs.addArb 将Secondary和Arbiter添加上。就算完成了。
2.一个 Primary用于写，多个Secondary用于读和一个Secondary用于备份
在写多读少的应用中，4sq主要使用了Replica Sets来实现读写分离。通过在连接时指定slaveOk，将读操作放到Secondary上，Primary只承担写操作。同时指定一台priority为0，hidden为true的Secondary来进行备份（这样设置后此机器在读写中都不可见，并且不会被选举为Primary）
3.MongoDB经典配置，上层是Auto-Sharding，每个Sharding结点又是一个Replica Sets
虽然4sq在这上面吃过亏，但很明显他们已经吸取了教训并且在更合理更小心的使用Auto-Sharding这一诱人的功能。
注意：如果 一个 Primary，一个Secondary，一个Arbiter的时候，不能指定slaveOk，因为用slaveOk指定读写分离后，写全部到primary,读全部到secondary,如果primary宕掉,secoryary就变成primary,而此时就没有secondary,也就没法读。
最新文章
- JavaScript getComputedStyle
- jar包制作
- CM_RESOURCE_LIST structure
- [转]WIN7系统安装Apache 提示msvcr110.DLL
- Chorme 快捷键
- maven lean install 的时候出错 Failed to clean project
- Struts2的配置和一个简单的例子
- call是什么？一次说个明白
- 一口一口吃掉Hibernate（五）——一对多单向关联映射
- ubuntu中文乱码解决
- 雅礼 noip2018 模拟赛day3 T2
- 298. Binary Tree Longest Consecutive Sequence最长连续序列
- jQuery的介绍
- linux上 安装软件
- HTTP Status 400 - description The request sent by the client was syntactically incorrect.
- PCA图
- JAVA各种系统架构图及其简介
- 页面的缓存设置与meta的作用详细解释
- Jquery 在多个相同标签click的问题
- MySQL实现允许远程用户登录(使用Navicat for MySQL工具)