Mongodb Replica Set 读写分离

环境：mongodb版本：2.4.6，Replica Set

需求：primary压力过大，期望secondary分担读压力

前言

    从应用程序角度来看，使用Replica Set 和使用单台mongo很像。默认的驱动程序会连接primary节点，并且将所有读写请求都路由到主节点。但也可以通过设置驱动程序的Read Preferences 配置其他选项，将读请求路由到其他节点。但需要知道的是将读请求路由到其他节点所带来的问题......  附:驱动程序连接到Replica Set常用的连接字符串类似：'mongodb://server1:27017,server2:27017' .具体可以查看相关驱动程序的文档,php可参考：http://php.net/manual/zh/mongo.tutorial.php.

    问题是:

    1:  一致性的考虑，对一致性要求比较高的应用程序是不应该从备份节点读取数据，备份节点通常由于加载问题，网络等原因，而落后于主节点几毫秒，几秒，几分钟 甚至更多。如果应用程序需要读取它自己的写操作（比如，先插入一个文档，再去查询它）

那么不应该从备份节点去读取数据，除非针对写操作，使用Write Concern定义w数值，在复制到所有备份节点之后，再返回执行成功与否。总之，如果从一个落后的备份节点读取数据，就要牺牲一致性。如果希望写入操作返回之前被复制到所有的副本集成员，就要牺牲写入速度。

   2: 如果路由到的备份节点，其中一台挂了，那么其他节点将承担其相应的压力，需要注意此时在线节点的负载压力。

   小结论是: 一般是不建议做读写分离，但是我们这里业务，写操作很少，大量的读请求，这里决定做读写分离来分担服务器压力,然后慢慢过度到分片。

什么是Read Preference?

    Read Preference 描述了mongodb 如何将请求路由到副本集的节点,默认下,会路由到primary节点

Read Preference 的几个模式:

    primary :  默认的模式,所有读写,都路由到primary节点

    primaryPreferred  :大部分情况,操作从primary节点读数据,除非primary节点不可用

    secondary: 所有操作从secondary节点读取数据

    secondaryPreferred:大多数情况,操作从secondary节点读取数据,除非所有secondary节点不可用.

    nearest:从最小的网络的延迟的那个节点读取数据,不管节点的类型

什么是 getLastError?

    http://docs.mongodb.org/v2.4/reference/command/getLastError/#dbcmd.getLastError

    驱动程序在执行一个写操作后,会执行getLastError ,然后通过返回的信息来判断是否执行成功,返回的可以是:

       1 :null ,说明执行成功

       2 : 一个最后的错误描述

    getLastError 可以有下面的选项来配置write concern:

       j or "journal" option:

         它会确认monod实利写入journal数据到磁盘,保证数据在突然关机的情况下不会丢失 栗子:

         > db.runCommand( { getLastError: 1, j: "true" } )

         note: If you set journal to true, and the mongod does not have journaling enabled, as with nojournal, then getLastError will provide basic receipt acknowledgment, and will include a jnote field in its return document.

     w option:

         0  : 禁用基本的acknowledgment写操作,返回socket异常和网络异常

         1  : 提供acknowledgment 的写操作,在单机或者副本集的primary节点

         >1  : 保证写操作成功的应用到副本集指定的节点(包含primary)

         majority : 确认副本集成员多数写入成功

   wtimeout option: 

         设置write concern超时的超时时间,如果不指定或指定为0 在某些情况下可以导致写操作一直block.

什么是Write Concern?

    Write concern: 当一个mongodb的写入操作成功执行后什么时候返回给客户端.通过getLastError实现.

mongodb 提供不同的等级以方便客户端特殊的请求Write Concern Levels:

    Unacknowledged: mongod不会确认写入是否成功,客户端也不会提示是否报错,除非是网络错误(在此版本之前是默认的级别).设置方法: 在你的驱动程序上设置此指定w为0.

    Acknowledged: mongodb 会确认写入是否成功,客户端也可以获取到网络,复制,或者其他的错误.(目前默认的级别)

设置方法:在你的驱动程序上设置此指定w为1.

    默认的write concern 会调用getLastError( 不带参数)来确认是否执行写入成功,  所以也可以在副本集中通过修改默认的getLastErrorDefaults来实现 write concern的级别的更改,这里没有修改mongo 的默认配置,是通过修改驱动程序的配置来实现.

getLastError: http://docs.mongodb.org/v2.4/reference/command/getLastError/#dbcmd.getLastError

getLastErrorDefaults:  http://docs.mongodb.org/v2.4/reference/replica-configuration/#local.system.replset.settings.getLastErrorDefaults

    Journaled :mongodb 会在数据提交到 journal 后才返回写操作成功.mongod服务必须开启journal,mongodb2.4默认是开启的. 另外在副本集中,只要primary的journal 写入成功就返回.还可以增加mongodb 提交到journal的频率来减小此种方式的延迟:http://docs.mongodb.org/v2.4/reference/configuration-options/#journalCommitInterval设置:指定w为1并且指定 j=true.

    Replica Acknowledged:可以保证写操作写入到副本集的成员后才返回成功 . 设置w 大于1 , 比如2  是保证2个成员写入成功后返回.

如何设置mongodb的读写分离?

1: 应用程序设置write concern 看这里: http://api.mongodb.org/?_ga=1.237665031.647167877.1420012424

    php栗子:

<?php
$m = new MongoClient("mongodb://localhost/?journal=true&w=majority&wTimeoutMS=20000");
?>

2: mongodb Replica Sets 修改默认的 getLastError (getLastErrorDefaults 的设置只会在getLastError 命令没有其他参数的情况下生效): 

cfg = rs.conf()
cfg.settings = {}
cfg.settings.getLastErrorDefaults = {w: 3,wtimeout: 6000}
rs.reconfig(cfg)

以上配置意思:数据成功写入3个节点后返回,其中包含了primary.最好设置wtimeout,当指定w的数值比副本集的成员多的情况下,写入操作会一直被block. 另外 wtimeout设置为0 意味这一直不超时.

参考:

http://docs.mongodb.org/v2.4/core/write-concern/

http://docs.mongodb.org/v2.4/reference/write-concern/

http://docs.mongodb.org/v2.4/core/replica-set-write-concern/

http://docs.mongodb.org/v2.4/reference/command/getLastError/#dbcmd.getLastError