Mongo 主从复制 原理浅析

主从复制

最基本的设置是建立一个主节点和多个从节点，每个从节点要知道主节点的地址。

运行mongod --master就启动了主服务器。运行mongod --slave --source master_address则启动了从服务器，其中master_address就是上面的主节点地址。

生产环境下有多台服务器，不过这里我们的例子就在同一机器上试验。

1.给主节点建立数据目录，并绑定端口(10000)。

$ mkdir -p ~/dbs/master

$ ./mongod --dbpath ~/dbs/master --port 10000 --master

2.接着设置从节点，记得要选择不同的端口号，并且用--source为从节点指定主节点地址。

$ mkdir -p ~/dbs/slave

$ ./mongod --dbpath ~/dbs/slave --port 10001 --slave --source localhost:10000

这样就完成了主从复制，注意不超过12个从节点的集群就可以运行良好。

  

添加及删除源

启动从节点时，可以用--source指定主节点，也可以在shell中配置这个选项。

假设主节点绑定了localhost:27017。启动从节点时可以不添加源，而是随后向sources集合添加主节点信息。

$ ./mongod --slave --dbpath ~/dbs/slave --port 27018

现在可以在shell中运行如下命令，将localhost:27017作为源添加到从节点上：

> use local

> db.sources.insert({"host":"localhost:27017"})

假设在生产环境下，想更改从节点的配置，改为www.xiaozhe.com为源，则可以用insert和remove来完成。

> db.sources.insert({"host","www.xiaozhe.com"})

> db.sources.remove({"host","localhost:27017"})

可以看到，sources集合可以当做普通集合进行操作，而且为管理从节点提供了很大的灵活性。

注：要是切换的两个主节点有相同的集合名，则MongoDB会尝试合并，但不能保证正确合并，要是使用一个从节点对应多个不同的主节点，最好使用不同的命名空间。

副本集（相当于集群）

副本集就是有自动故障恢复功能的主从集群。主从集群和副本集最为明显的区别就是副本集没有固定的主节点。可以把副本集当做一个集群，整个集群会选出一个主节点，当其不能正常工作时则会激活其他节点。

设置副本集比主从稍微复杂点，我们从2个服务器开始：

注意不能用localhost作为地址成员，我们需要找到主机名，$ cat /etc/hostname(假如主机名是morton) 。然后为每一个服务器创建数据目录，选择端口，$ mkdir -p ~/dbs/node1 ~/dbs/node2 。在启动之前，我们需要给副本集一个名字，这里命名为blort 。之后我们用 --replSet选项，作用是让服务器知晓在这个blort副本集还有别的同伴。

$ ./mongod --dbpath ~/dbs/node1 --port 10001 --replSet blort/morton:10002

$ ./mongod --dbpath ~/dbs/node2 --port 10002 --replSet blort/morton:10001

如果想添加第三台：

$ ./mongod --dbpath ~/dbs/node3 --port 10003 --replSet blort/morton:10001,morton:10002

现在我们启动一个服务器morton:10001，并进行初始化设置

$ ./mongo morton:10001/admin

> db.runCommand({"replSetInitiate":{

"_id" : "blort",

"members" : [

{

"_id" : 1,

"host" : "morton:10001"

},

{

"_id" : 2,

"host" : "morton:10002"

}

}})

副本集中节点的类型

standard:常规节点，它存储一份完整的数据副本，参与选举投票可以成为活跃节点。

passive:存储了完整的数据副本，参与投票，不能成为活跃节点。

arbiter:仲裁者只参与投票，不能接受复制数据，也不能成为活跃节点。

每个参与节点（非仲裁者）都有个优先权，优先权为0是被动的，不能成为活跃节点，优先值不为0，则按照大小选出活跃节点。如果2个值一样，则数据最新的为活跃节点。

在节点配置中修改priority键，来配置成标准节点或被动节点。

>member.push({

"_id":3,

"host":"morton:10003",

"priority":40

})

默认优先级是1，可以是0~1000

arbiterOnly键可以指定仲裁节点

>member.push({

"_id":4,

"host":"morton:10004",

"arbiterOnly":true

})

在从服务器上执行操作

读扩展

用mongodb扩展读取的一种方式就是将查询放在从节点上。这样主节点的负载就减轻了。一般来说，当负载是读取密集型时这是非常不错的方案。要是写入密集型，则要参见第十章用分片来进行扩展。

扩展读取本身很简单，和往常一样设置主从复制，连接从服务器处理请求，唯一的技巧是告诉从服务器是否可以处理请求（默认是不可以的）。这个选项叫做slaveOkay。

用从节点做数据处理

我们可以使用--master参数启动一个普通的从节点。同时使用--slave和--master有点矛盾，其实这意味着如果对从节点进行写入，则把从节点就当做普通的MongoDB。其实它还是会不断的复制主节点的数据，这样就可以对节点执行阻塞操作而不影响主节点性能。

注意：用这种技术的时候，一定要确保不能对正在复制的主节点的从节点进行数据库插入。而且从节点第一次启动时也不能有正被复制的数据库。

工作原理

Oplog

主节点的操作记录称为oplog(operation log)。Oplog存储在一个特殊的数据库中，叫做local。Oplog就在其中的oplog.$main集合里面。Oplog中的每个文档都代表主节点执行的一个操作。

ts:操作的时间戳

op:操作的类型,只有1字节代码（如i代表插入）

ns：执行操作的命令空间

o：进一步指定要执行的操作的文档，对插入来说，就是要插入的文档

注意：oplog不记录查询操作，oplog存储在固定集合里面，所以它们会自动替换旧的操作。我们在启动服务器的时候可以用--oplogSize指定这个大小（MB）

重新同步

如果从节点的数据被主节点的数据拉开太远了，则从节点可能跟不上主节点的步

子，有可能造成同步失败。解决方法是从新进行同步{"resync":1}，也可以在启动从节点的时候用--autoresync选项让其自动启动。建议oplog的大小是剩余磁盘空间的5%。

复制状态和本地数据库

本地数据库（local）用来存放所有内部复制状态。其内容不会被复制，从而确保了一个MongoDB服务器只有一个本地数据库。

管理

诊断

当连接到主节点后，使用db.printReplicationInfo函数

>db.printReplicationInfo(); 这些信息是oplog的大小和oplog中操作的时间范围。

当连接到从节点时，用db.printSlaveReplicationInfo()函数，能得到从节点的一些信息。

变更oplog的大小

若发现oplog大小不适合，最简单的方法是停掉主节点，删除local数据库的文件，用新的设置(--oplogSize)重新启动。

$ rm /data/db/local.*

$ ./mongod --master --oplogSize size(新大小)

重启主节点后，所有的从节点要用--autoresync重启，否则需要手动同步更新。