MongoDB副本集提高读写速率

一、提高副本集写的速率

1、通过设置Write Concern for Replica Sets¶

cfg = rs.conf()
##cfg.settings.getLastErrorDefaults = { w: "majority", wtimeout: 5000 }

cfg.settings.getLastErrorDefaults ={w:1}
rs.reconfig(cfg)

2、insert数据时带上配置参数

db.products.insert(
{ item: "envelopes", qty : 100, type: "Clasp" },
##{ writeConcern: { w: "majority" , wtimeout: 5000 } }

{ writeConcern: { w: 1 } }
)

配置w:1，入库速度34m,提升到14m（500w数据），但是当主库数据导入完毕后，从库一直在追赶应用主库日志

3、w Option¶

The w option requests acknowledgment that the write operation has propagated to a specified number of mongod instances or to mongod instances with specified tags.

Using the w option, the following w: <value> write concerns are available:

Value Description

Value	Description
`<number>`¶	Requests acknowledgment that the write operation has propagated to the specified number of `mongod` instances. For example: `w: 1` Requests acknowledgment that the write operation has propagated to the standalone `mongod` or the primary in a replica set. `w: 1` is the default write concern for MongoDB. `w: 0` Requests no acknowledgment of the write operation. However, `w: 0` may return information about socket exceptions and networking errors to the application. If you specify `w: 0` but include j: true, the j: true prevails to request acknowledgment from the standalone `mongod` or the primary of a replica set. `w` greater than 1 requires acknowledgment from the primary and as many additional data-bearing secondaries to meet the specified write concern. For example, consider a 3-member replica set with no arbiters. Specifying `w: 2` would require acknowledgment from the primary and one of the secondaries. Specifying `w: 3` would require acknowledgment from the primary and both secondaries. Note Hidden, delayed, and priority 0 members can acknowledge `w: <number>` write operations. Delayed secondaries can return write acknowledgment no earlier than the configured `slaveDelay`. See Acknowledgment Behavior for when `mongod` instances acknowledge the write.
`"majority"`¶	Requests acknowledgment that write operations have propagated to the calculated majority of the data-bearing voting members (i.e. primary and secondaries with `members[n].votes` greater than `0`). For example, consider a replica set with 3 voting members, Primary-Secondary-Secondary (P-S-S). For this replica set, calculated majority is two, and the write must propagate to the primary and one secondary to acknowledge the write concern to the client. Note Hidden, delayed, and priority 0 members with `members[n].votes` greater than `0` can acknowledge `"majority"` write operations. Delayed secondaries can return write acknowledgment no earlier than the configured `slaveDelay`. After the write operation returns with a `w: "majority"` acknowledgment to the client, the client can read the result of that write with a `"majority"` readConcern. See Acknowledgment Behavior for when `mongod` instances acknowledge the write.
`<custom write concern name>`¶	Requests acknowledgment that the write operations have propagated to `tagged` members that satisfy the custom write concern defined in `settings.getLastErrorModes`. For an example, see Custom Multi-Datacenter Write Concerns. See Acknowledgment Behavior for when `mongod` instances acknowledge the write.

<number>¶

Requests acknowledgment that the write operation has propagated to the specified number of mongod instances. For example:

w: 1

Requests acknowledgment that the write operation has propagated to the standalone mongod or the primary in a replica set. w: 1 is the default write concern for MongoDB.

w: 0

Requests no acknowledgment of the write operation. However, w: 0 may return information about socket exceptions and networking errors to the application.

If you specify w: 0 but include j: true, the j: true prevails to request acknowledgment from the standalone mongod or the primary of a replica set.

w greater than 1 requires acknowledgment from the primary and as many additional data-bearing secondaries to meet the specified write concern. For example, consider a 3-member replica set with no arbiters. Specifying w: 2 would require acknowledgment from the primary and one of the secondaries. Specifying w: 3 would require acknowledgment from the primary and both secondaries.

Note

Hidden, delayed, and priority 0 members can acknowledge w: <number> write operations.

Delayed secondaries can return write acknowledgment no earlier than the configured slaveDelay.

See Acknowledgment Behavior for when mongod instances acknowledge the write.

"majority"¶

Requests acknowledgment that write operations have propagated to the calculated majority of the data-bearing voting members (i.e. primary and secondaries with members[n].votes greater than 0).

For example, consider a replica set with 3 voting members, Primary-Secondary-Secondary (P-S-S). For this replica set, calculated majority is two, and the write must propagate to the primary and one secondary to acknowledge the write concern to the client.

Note

Hidden, delayed, and priority 0 members with members[n].votes greater than 0 can acknowledge "majority" write operations.

Delayed secondaries can return write acknowledgment no earlier than the configured slaveDelay.

After the write operation returns with a w: "majority" acknowledgment to the client, the client can read the result of that write with a "majority" readConcern.

See Acknowledgment Behavior for when mongod instances acknowledge the write.

<custom write concern name>¶

Requests acknowledgment that the write operations have propagated to tagged members that satisfy the custom write concern defined in settings.getLastErrorModes.

For an example, see Custom Multi-Datacenter Write Concerns.

See Acknowledgment Behavior for when mongod instances acknowledge the write.

二、提高副本集读取效率

PSA 3-member Architecture¶

Starting in MongoDB 3.6, "majority" read concern, available for WiredTiger, is enabled by default. However, for MongoDB 4.0.3+, if you have a three-member replica set with a primary-secondary-arbiter (PSA) architecture, you can disable "majority" read concern. Disabling "majority" for a three member PSA architecture avoids possible cache-pressure build up.

The procedure below disables "majority" read concern for MongoDB 4.0.3 PSA architecture by including --enableMajorityReadConcern false. If you are running a MongoDB 4.0.1 or 4.0.2 PSA architecture, first upgrade to the latest 4.0 version in order to disable this read concern.

Note

Disabling "majority" read concern disables support for Change Streams for MongoDB 4.0 and earlier. For MongoDB 4.2+, disabling read concern "majority" has no effect on change streams availability.

For more information on PSA architecture and read concern "majority", see Disable Read Concern Majority.

https://www.jianshu.com/p/c8236068204c

https://yq.aliyun.com/articles/60553

https://blog.csdn.net/qq_33642970/article/details/104155807