Shulou(Shulou.com)06/01 Report--

Environment: mongodb version: 2.4.6 Magi replica Set

Demand: primary is under too much pressure. Secondary is expected to share the reading pressure.

Preface

From an application perspective, using Replica Set is very similar to using a single mongo. The default driver connects to the primary node and routes all read and write requests to the primary node. However, you can also route read requests to other nodes by setting the driver's Read Preferences to configure other options. But what you need to know is the problem of routing read requests to other nodes. Attachment: the common connection string used by the driver to connect to Replica Set is similar to: 'mongodb://server1:27017,server2:27017'. For more information, please see the relevant driver documentation. Php can refer to: http://php.net/manual/zh/mongo.tutorial.php.

The question is:

1: for the consideration of consistency, applications that require high consistency should not read data from the backup node, which usually lags behind the master node for milliseconds, seconds, minutes or more due to loading problems, network and other reasons. If the application needs to read its own writes (for example, insert a document first and then query it)

Then you should not read data from the backup node unless you use Write Concern to define the w value for the write operation, copy it to all backup nodes, and then return whether the execution was successful or not. In short, if you read data from a backward backup node, consistency is sacrificed. If you want the write operation to be copied to all replica set members before the write operation returns, you have to sacrifice the write speed.

2: if one of the routed backup nodes dies, the other nodes will bear the corresponding pressure, so you need to pay attention to the load pressure of the online nodes at this time.

The small conclusion is: generally, it is not recommended to do read-write separation, but in our business here, there are few write operations and a large number of read requests, so we decide to do read-write separation to share the pressure on the server, and then slowly transition to fragmentation.

What is Read Preference?

Read Preference describes how mongodb routes requests to nodes in the replica set, which by default are routed to primary nodes

Several modes of Read Preference:

Primary: the default mode, where all reads and writes are routed to the 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, operations read data from secondary nodes unless all secondary nodes are unavailable.

Nearest: read data from the node with the smallest network latency, 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 getLastError, and then determines whether the execution is successful or not by the returned information, which can be:

1: null, indicating that the execution is successful

2: a final error description

GetLastError has the following options to configure write concern:

J or "journal" option:

It confirms that monod Shili writes journal data to disk, ensuring that the data will not lose 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 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: disable basic acknowledgment write operations and return socket and network exceptions

1: provide acknowledgment write operation on the primary node of a stand-alone machine or replica set

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

Majority: confirm that most of the members of the replica set are written successfully

Wtimeout option:

Setting the timeout of the write concern timeout, if not specified or specified as 0, in some cases can cause the write operation to remain block.

What is Write Concern?

Write concern: when a mongodb write operation is successfully executed, when it is returned to the client. Realized by getLastError.

Mongodb provides different levels to facilitate client-side special request 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 error (the default level before this version). Setting method: set this specified w to 0. 0 on your driver.

Acknowledged: mongodb confirms that the write is successful, and the client can get network, replication, or other errors. (current default level)

Setting method: set this specified w to 1 on your driver.

The default write concern calls getLastError (without parameters) to confirm whether the write is successful, so you can also change the level of write concern in the replica set by modifying the default getLastErrorDefaults. Here, the default configuration of mongo is not modified, but by modifying the configuration of the driver.

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 will not return a successful write operation until the data is submitted to journal. The journal,mongodb2.4 service must be enabled by default. In addition, in the replica set, it is returned as long as the journal of primary is successfully written. You can also increase the frequency with which mongodb is submitted to journal to reduce latency in this way: http://docs.mongodb.org/v2.4/reference/configuration-options/#journalCommitInterval setting: specify w as 1 and specify j=true.

Replica Acknowledged: it is guaranteed that the write operation is written to the member of the replica set before returning success. Set w greater than 1, such as 2 to ensure that 2 members are returned after successful writing.

How to set the read-write separation of mongodb?

1: application settings write concern see here: http://api.mongodb.org/?_ga=1.237665031.647167877.1420012424

Php Chestnut:

2: mongodb Replica Sets modifies the default getLastError (the setting of getLastErrorDefaults will only take effect if the getLastError command has no other parameters):

Cfg = rs.conf () cfg.settings = {} cfg.settings.getLastErrorDefaults = {w: 3 Magazine wtimeout: 6000} rs.reconfig (cfg) the above configuration means: data is returned after being successfully written to 3 nodes, including primary. It is best to set wtimeout, when the value of the specified w is more than the members of the replica set, the write operation will always be block. In addition, setting wtimeout to 0 means that it does not time out all the time.

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

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.