Mongodb Replica Set read/write separation

Environment: MongoDB version: 2.4.6,replica Set

Demand: Primary pressure is too high, expect secondary share reading pressure

Objective

From an application perspective, it is much like using replica Set and using a single MONGO. The default driver connects to the primary node and routes all read and write requests to the master node. However, you can also configure additional options by setting the driver's read Preferences to route read requests to other nodes.  But what you need to know is the problem of routing read requests to other nodes ... Attached: Driver connected to replica set common connection string similar to: ' mongodb://server1:27017,server2:27017 '. See the documentation for the relevant driver, PHP for reference: http://php.net/ manual/zh/mongo.tutorial.php.

The problem is:

1: Consistency considerations, the application of high consistency requirements should not be read from the backup node, the backup node is usually due to load problems, network and other reasons, and lag behind the main node for a few milliseconds, a few seconds, a few minutes or more. If the application needs to read its own write operation (for example, insert a document first, then query it)

Then the data should not be read from the backup node, unless the write concern is used to define the W value, after copying to all the backup nodes, the execution succeeds or not. In short, if you read data from a backward backup node, you sacrifice consistency. If you want the write operation to be copied to all replica set members before it is returned, the write speed is sacrificed.

2: If one of the backup nodes is routed to, one of them hangs, then the other nodes will bear their corresponding pressure, and pay attention to the load pressure of the online node at this time.

Small conclusion is: generally is not recommended to do read and write separation, but we here business, write very little, a large number of read requests, here decided to do read and write separation to share the server pressure, and then slowly over to the Shard.

What is read Preference?

Read Preference describes how MongoDB routes requests to the replica set node, which, by default, is routed to the primary node

Several modes of Read Preference:

Primary: Default mode, all read and write, routed to primary node

Primarypreferred: In most cases, the operation reads data from the primary node unless the primary node is not available

Secondary: All operations read data from the secondary node

Secondarypreferred: In most cases, the operation reads data from the secondary node unless all secondary nodes are unavailable.

Nearest: Reads data from the node of the smallest network delay, regardless of the type of node

What is GetLastError?

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

After performing a write operation, the driver executes the GetLastError and then, through the returned information, determines whether the execution is successful, and the return can be:

1:null, indicating successful execution

2: A final description of the error

GetLastError can have the following options to configure the write concern:

J or "journal" option:

It confirms that Monod writes journal data to the disk, ensuring that the data does not lose the chestnuts in the event of a sudden shutdown:

> Db.runcommand ({getlasterror:1, J: "True"})

Note:if you set Journal to True, and the Mongod does not has journaling enabled, as with Nojournal, then GetLastError WI ll provide basic receipt acknowledgment, and would include a jnote field in its return document.

W option:

0: Disable basic acknowledgment write operation, return socket exception and network exception

1: Provide acknowledgment write operation, primary node in stand-alone or replica set

>1: Ensure that the write operation is successfully applied to the node specified by the replica set (including primary)

Majority: Confirm majority of replica set member writes succeeded

Wtimeout option:

Setting the write concern timeout time-out if not specified or specified as 0 in some cases can cause the write operation to block.

What is write Concern?

Write concern: When a MongoDB write operation is executed successfully, it is returned to the client. Implemented by GetLastError.

MongoDB offers different levels to facilitate client-specific requests for the write Concern levels:

Unacknowledged:mongod does not confirm that the write was successful, and the client does not prompt for an error unless it is a network fault (the default level before this version). Setup method: Set this specified W to 0 on your driver.

650) this.width=650; "src=" Http://docs.mongodb.org/v2.4/_images/crud-write-concern-unack.png "width=" 460 "height=" "alt=" Crud-write-concern-unack.png "/>"

Acknowledged:mongodb will confirm that the write is successful and the client can get to the network, copy, or other error. (the current default level)

Setup method: Set this specified W to 1 on your driver.

The default write concern calls GetLastError (without parameters) to confirm that the write succeeds, so you can also implement the level change of write concern by modifying the default getlasterrordefaults in the replica set. The default configuration for MONGO is not modified, and is implemented by modifying the driver configuration.

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

650) this.width=650; "src=" Http://docs.mongodb.org/v2.4/_images/crud-write-concern-ack.png "width=" 460 "height=" "alt=" Crud-write-concern-ack.png "/>"

Journaled:mongodb will not return the write operation until the data is submitted to journal. The Mongod service must be turned on journal,mongodb2.4 default is on. Also in the replica set, as long as primary journal Writes are returned successfully. You can also increase the frequency at which MongoDB submits to journal to reduce the delay in this way:http://docs.mongodb.org/v2.4/reference/ configuration-options/#journalCommitInterval setting: Specify W to 1 and specify J=true.

650) this.width=650; "src=" Http://docs.mongodb.org/v2.4/_images/crud-write-concern-journal.png "width=" "Height = "alt=" "Crud-write-concern-journal.png"/>

Replica acknowledged: The write operation can be guaranteed to be written to a member of the replica set before it returns success. Setting w greater than 1, such as 2, guarantees that 2 members are returned after a successful write.

650) this.width=650; "src=" Http://docs.mongodb.org/v2.4/_images/crud-write-concern-w2.png "width=" 520 "height=" 540 "alt=" Crud-write-concern-w2.png "/>

How do I set up a read/write separation for MongoDB?

1: Application settings Write concern look here: http://api.mongodb.org/?_ga=1.237665031.647167877.1420012424

PHP Chestnuts:

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

2:mongodb Replica Sets Modify the default GetLastError (the settings for Getlasterrordefaults will only take effect if the GetLastError command has no other parameters):

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

The above configuration means: The data was successfully written to 3 nodes and returned, including primary. It is best to set the Wtimeout, and when the value of W is greater than the number of members of the replica set, the write operation will always be block. Another wtimeout setting of 0 means that this has not timed out.

Reference:

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

This article is from the "Cclo blog" blog, make sure to keep this source http://xuclv.blog.51cto.com/5503169/1614114

Mongodb Replica Set read/write separation