mongoDB的读书笔记(04)_【Replica】(01)

数据库分布已经是当下互联网的标准配置。原来单节点标准配置，一台web服务器，一台数据库服务器的1+1模式，可以应对一个小公司或者少量的访问量。而随着服务的提升，对于7×24×365的高可用性的要求的需求，以及访问量的增大我们的1+1的模式早已不能满足需求，单点故障早已不允许在当下的系统中，大并发的访问也不能轻易搞死系统，那么就有了服务器的cluster，数据库的分布式，使得对于访问服务器的用户来讲使用体验是透明的，而面的服务到底是谁来给提供的就变得“飘忽不定”起来。

在接触mongoDB之前，接触过mysql以及oracle的rac，对于分布式有一定的了解。不过真正自己配置Replicaset还是拿mongoDB进行了落地。原因是，mongoDB首先很轻巧，配置很简单，用户界面虽然全都是Command但是并没有复杂得让人抓狂的程度（比如从最初下载CentOS开始配置Hadoop环境那么麻烦。。），一切都是手到擒来，一气呵成的感觉。不得不说mongoDB的配置以及应用对于现在的快速迭代以及变化多端的需求运用场景来讲都提供了很好的支持，使得原来做关系数据库那么教条的范式思路在mongoDB中就显得有些古板了，呵呵。

首先，先来介绍一下mongoDB的Replica set的一些基本的对象。以下和未来Replica的内容大部分来源于官网，例子有书上的也有官网的。因为我读书后发现其实官网的顺序以及讲解更好一些。

Primary

Replica set翻译过来叫做副本集，也就是相当于备份。那么有备胎就要有正选咯？是的。mongoDB的结构按照官方网站的图片来说是酱的：

从图中可以看出，只有正选的“Primary”才可以接受Writes写和Reads的请求，而所有的Secondary的备胎们，只能作为仆人去Read。思路来说的话也很简单也很常规，就是Primary去接受所有的Write然后存成log，所有的Secondary去读这些log来备份数据。如下面的mongoDB的官网的解释：

Primary¶
The primary is the only member in the replica set that receives write operations. MongoDB applies write operations on the primary and then records the operations on the primary’s oplog. Secondary members replicate this log and apply the operations to their data sets.
In the following three-member replica set, the primary accepts all write operations. Then the secondaries replicate the oplog to apply to their data sets.

对于写，只能去向Primary请求，默认的，所有的读操作也是先请求到Primary的。不过也可以通过修改设置来直接读Secondary的数据。另外，Primary是可以动态改变的，当一个Primary已经变得不可用，那么剩余的Secondary可以通过选举选出一个Secondary作为新的Primary来用（嗯。。。充分体现了民主-v-）。

Secondary

嗯，所有的后宫都在这里了。顺便说下，mongoDB的Replica Set不是无穷尽的，最多只支持12个成员。12个成员都是什么成员之后再说。那么，对于所有的Secondary来说，最根本的任务就是从oplog中读取Primary过来的所有写操作，而且上文也说过，在Primary挂掉的时候，不会后宫大乱而是理性通过投票机制选出来一个Primary来继续统领，整个操作对客户端来说都是透明的。通过一些设定，可以限制或者指定Secondary的动作行为，来自官网的解释：

You can configure a secondary member for a specific purpose. You can configure a secondary to:
•Prevent it from becoming a primary in an election, which allows it to reside in a secondary data center or to serve as a cold standby. See Priority 0 Replica Set Members.
你可以人为阻止Secondary参加选举（类似于剥夺你的政x权利），也就是不让这个Secondary有机会参选为Primary。成为一个被打入冷宫（cold standby）的纯粹的备胎。
•Prevent applications from reading from it, which allows it to run applications that require separation from normal traffic. See Hidden Replica Set Members.
阻止客户程序去读取这个节点，使得这个节点变成隐藏透明状，不参与到外面的混战操作中，不被外界打扰，踏踏实实做一些自己要执行的操作。
•Keep a running “historical” snapshot for use in recovery from certain errors, such as unintentionally deleted databases. See Delayed Replica Set Members.
可以定义历史快照，当你不小心误操作或者搞坏你的db，通过这些快照点来恢复你的数据。

Arbiter

这个比较拽了。既不是领导者也不是跟班的，不参与任何对于数据的存储或者分布的操作，仅仅是一个仲裁机构。试想这种场景：1个Primary带着4个Secondary在玩耍，突然，Primary驾崩，其中4个Secondary中被投票成为Primary的Secondary的得票是2：2，咋办？。。。（其实，这个2v2的结果还有深层次的意思和意义，这也是我刚开始理解mongoDB的副本不到位的地方，后面会详细阐述这个数字的的意义以及奇数偶数副本节点的概念）这个时候，Arbiter的作用就来了，随便给哪一方一票，得票方就成为新的Primary了。这就是Arbiter的作用。只管投票，没有当选和执行其他事物的权利。当然，如果你加入了一个Arbiter那使得你的members成为了4个，那么你的选举就变成了Tied election，自己给自己找麻烦哦。所以，一般来说我们还是喜欢用奇数个成员来直接出选举结果的，而不使用Arbiter，这也是mongoDB的建议。

つづく・・