学习MongoDB--（9-3）：复制（主从复制--进阶2）

上一篇主要提及了主从复制的启动选项和从节点的一些实际用途，这篇继续进一步讲一下主从复制的一些内容。

【复制状态和本地数据库】

在复制过程中，复制状态都会被存储在本地数据库（即local）中，主节点和从节点都是。local数据库的内部不会被复制，这样就可以保证每一个MongoDB服务器上会有一个私有独立的local数据库。

local数据库不限于存储复制状态信息，用户本身希望不被复制的文档也可以存储在这个数据库的某个集合中！

主节点的复制状态包括从节点的集合（所有从节点连接到主节点后都会执行handshake命令进行握手，将自己添加到集合中），这个集合就是local数据库的slaves:

> use local
switched to db local
> db.slaves.find();
{ "_id" : ObjectId("5041670e6c920f6b7e5ee953"), "host" : "127.0.0.1", "ns" : "local.oplog.$main", "syncedTo" : { "t" : 1346463631000, "i" : 1 } }
{ "_id" : ObjectId("5041674c124d377451b7673b"), "host" : "127.0.0.1", "ns" : "local.oplog.$main", "syncedTo" : { "t" : 1346463631000, "i" : 1 } }
>

从节点的复制状态包括：在me集合中存放的从节点唯一标示符；在sources集合中存放的主节点（或称数据源）列表：

> use local
switched to db local
> db.me.find();
{ "_id" : ObjectId("5041670e6c920f6b7e5ee953"), "host" : "uf2011xxxxx" }
> db.sources.find();
{ "_id" : ObjectId("5041670e6c920f6b7e5ee952"), "host" : "localhost:10000", "sou
rce" : "main", "syncedTo" : { "t" : 1346463861000, "i" : 1 } }
>

我们可以看到，me集合中该文档的键“_id”和主节点slaves集合对应的该从节点文档的“_id”的值是一样的！

我们看到主节点的slaves集合和从节点的sources集合都有键“syncedTo”，主从节点都是通过这个键的值来跟踪从节点的更新状况！每次从节点查询主节点的oplog时，都会用 “syncedTo”作为查询条件来确认哪些操作需要执行，或者查看是否已经跟不上同步了！

【确保数据同步进行】

数据库管理员可以通过在主节点上执行getLastError命令的“w”参数来确保同步正在进行！

db.runCommand({"getLastError" : 1, "w" : N})；运行这个命令会进入阻塞阶段，知道“N”（“w”键的值）个服务器复制了最新的写操作后返回！如果该命令的N<2，则会立即返回，如果N==2，则主节点会等待至少一个从节点复制了最新写操作后返回，也就是说N这个数字包含主节点本身！

> db.runCommand({"getLastError" : 1, "w" : 3});
{
        "n" : 0,
        "connectionId" : 3,
        "wnote" : "no write has been done on this connection",
        "wtime" : 0,
        "err" : null,
        "ok" : 1
}
>

主节点执行这个命令的依据就是local数据库slaves集合中键“syncedTo”的值！默认该命令会一直阻塞直到满足条件返回，用户也可以通过键“wtimeout”指定超时时间（毫秒），如果在这么长时间内不返回，就返回超时错误信息！

通常数据库管理员会通过这个命令确保复制正在进行，或某些重要操作已被复制！但因为这个命令会阻塞复制操作，并且会严重影响主节点的写操作效率，所以使用时通常会将“N”的值设置为2或3即可！

【复制管理】

MongoDB还提供了一些有用的函数来查看复制的状态和其他信息，在主节点上执行db.printReplicationInfo函数：

> db.printReplicationInfo();
configured oplog size:   47.6837158203125MB
log length start to end: 2115secs (0.59hrs)
oplog first event time:  Sat Sep 01 2012 09:36:27 GMT+0800
oplog last event time:   Sat Sep 01 2012 10:11:42 GMT+0800
now:                     Sat Sep 01 2012 10:11:42 GMT+0800
>

我们看，在shell中执行函数后，返回的结果显示：oplog的大小大概为47M多，能放置大约2115秒的操作！这个2115秒（此处）的统计是不准确的，其计算方式就是上面返回结果第3,4项（第一次同步和最后一次同步）的时间差，刚启动主节点时，这两个时间差较短，即使oplog剩余空间很大，这个时长统计却很小！所以我们要等主节点服务跑了一段时间后，oplog转了一圈，这个统计数字才具有一定的意义，表明当前空间所能承载的操作时长！

从节点上可以调用db.printSlaveReplicationInfo()函数，能得到从节点的一些信息：

> db.printSlaveReplicationInfo();
source:   localhost:10000
         syncedTo: Sat Sep 01 2012 19:11:19 GMT+0800
                 = 12 secs ago (0hrs)
>

显示了主节点的地址，和数据的滞后时间，上例中，数据滞后12秒。

如果在使用中发现oplog空间不足了（上例中oplog的大小可以用操作时长来描述，这个时长需要大于主节点数据一次完整同步的时长，否则新加入的从节点就可能中途停止复制），我们就需要变更oplog的大小，具体做法为：停止主节点，删除主节点中local数据库文件，然后通过选项--oplogSize重新制定oplog的大小并重启主节点的服务，重启后，所有从节点需要通过使用选项--autoresync来重启，或手动运行命令重新进行一遍完整同步！

【复制管理--复制的认证问题】

按照书上描述，如果主节点需要进行认证，则主从节点需要进行一些处理后，才可以同步。这个处理就是，在主从节点的local数据库中加入相同的用户和密码！但我在Windows平台上测试（32位或64位），始终没有成功，不知是不是因为主从结构搭建在同一台机器的原因！因为在测试过程中，我发现了如下MongoDB的认证原则：

MongoDB的用户认证，如果admin数据库中没有添加用户，其他数据库添加了，即使通过--auth启动服务，本机的访问也是不需要认证的！admin数据库中添加了用户，并通过--auth启动服务，则任何对数据库的访问首先必须经过认证！

关于复制的认证部分，我的测试为：

在同一台机器上搭建一主一从的结构，如果只是在主节点的local数据库（或其他非admin数据库）添加用户，则这个认证不会干扰从节点的同步，即使从节点不添加任何用户信息！但如果主节点在admin中添加了用户，则从节点就无法同步了，即使从节点在local数据库中添加相同用户也无法进行！

这部分我后面后再进行进一步测试！