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

时间: 2024-12-20 18:26:17

Mongodb Replica Set 读写分离的相关文章

mongodb副本集-读写分离

一.设置连接字符串读写分离 1.通过MongoDB连接字符串配置:mongodb://example1.com,example2.com,example3.com/?readPreference=secondary   --只从secondary中读,如果secondary访问不了的时候就不能进行查询 2.通过MongoDB连接字符串配 置:mongodb://example1.com,example2.com,example3.com /?readPreference=secondaryPre

C# 连接mongodb副本集读写分离字符串配置

一.副本集配置 搭建完毕,1台主实例.1台从实例.1台仲裁实例.mongodb建议副本集中的机器数量为奇数 二.C#连接字符串 1.读 mongodb://secondary.com/?SlaveOk=true 2.写 mongodb://primary.com 三.经验之谈 1.使用的是1.7的C#驱动,不支持直接在连接字符串中配置/?readPreference=secondary或 /?readPreference=SecondaryPreferred 2.readPreference参数

第五部分 架构篇 第十四章 MongoDB Replica Sets 架构(自动故障转移/读写分离实践)

说明:该篇内容部分来自红丸编写的MongoDB实战文章. 1.简介 MongoDB支持在多个机器中通过异步复制达到故障转移和实现冗余,多机器中同一时刻只有一台是用于写操作,正是由于这个情况,为了MongoDB提供了数据一致性的保障,担当primary角色的服务能把读操作分发给Slave(详情请看前两篇关于Replica Set成员组成和理解). MongoDB高可用分为两种: Master-Slave主从复制:只需要在某一个服务启动时加上-master参数,而另外一个服务加上-slave与-so

关于mongodb读写分离 及 日志切换

mongodb的读写分离使用Replica Sets来实现 对于replica set 中的secondary 节点默认是不可读的.在写多读少的应用中,使用Replica Sets来实现读写分离.通过在连接时指定或者在主库指定slaveOk,由Secondary来分担读的压力,Primary只承担写操作. 如果通过shell访问mongo,要在secondary进行查询.会出现如下错误:imageSet:SECONDARY> db.fs.files.find()error: { "$err

MongoDb的“not master and slaveok=false”错误及解决方法,读写分离

首先这是正常的,因为SECONDARY是不允许读写的, 在写多读少的应用中,使用Replica Sets来实现读写分离.通过在连接时指定或者在主库指定slaveOk,由Secondary来分担读的压力,Primary只承担写操作. 对于replica set 中的secondary 节点默认是不可读的, [[email protected] bin]$ mongo 127.0.0.1:33333 MongoDB shell version: 2.0.1 connecting to: 127.0.

mongo 的replica set的集群模式 实现读写分离

对于replica set 中的secondary 节点默认是不可读的.在写多读少的应用中,使用Replica Sets来实现读写分离.通过在连接时指定或者在主库指定slaveOk,由Secondary来分担读的压力,Primary只承担写操作. 如果通过shell访问mongo,要在secondary进行查询.会出现如下错误:imageSet:SECONDARY> db.fs.files.find()error: { "$err" : "not master and

012.MongoDB读写分离

一 读写分离概述 1.1 读写分离描述 从应用程序角度来看,使用Replica Set 和使用单台mongo很像.默认的驱动程序会连接primary节点,并且将所有读写请求都路由到主节点.但也可以通过设置驱动程序的Read Preferences 配置其他选项,将读请求路由到其他节点. 通常官网中建议不使用向从节点取数据.原因如下: 所有的从节点拥有与主节点一样的写入负载,读的加入会增加其负载: 对于分片的集合,在平衡器的关系下,数据的返回结果可能会缺失或者重复某部分数据: 相对而言,官方建议使

mongoDB的读写分离

一.ReadPreference读偏好 在副本集Replica Set中才涉及到ReadPreference的设置,默认情况下,读写都是分发都Primary节点执行,但是对于写少读多的情况,我们希望进行读写分离来分摊压力,所以希望使用Secondary节点来进行读取,Primary只承担写的责任(实际上写只能分发到Primary节点,不可修改). MongoDB有5种ReadPreference模式: primary: 主节点,默认模式,读操作只在主节点,如果主节点不可用,报错或者抛出异常. p

Mongodb副本集实现及读写分离

在前面的文章"Mongodb的主从模式搭建实例"中,我们对如何搭建一个主从结构的Mongodb服务器环境进行了简单的介绍.但是对于主从结构,Mongodb官方并不推荐我们使用了,可能是因为主从模式存在以下两个缺点: (1)主节点不可用之后,无法自动切换到从节点,无法确保业务访问的不间断性: (2)所有的读写操作都是对主节点的,造成主节点的访问压力较大: 因此,Mongodb为我们提供了另外一种推荐的使用方法,那就是使用副本集ReplicaSets.在这篇文章中简单描述一下副本集是如何实