MongoDB 5.0 PSA副本集与分片下默认写关注差异

接上一篇MongoDB PSA架构痛点以及如何应对有朋友指出,5.0分片集群采用PSA时,出现S宕机时,客户端写入hang,并没有按官方文档描述那样PSA默认写是w:1.我当初只是验证PSA副本集发现与官方描述一致,但并没有验证分片架构.导致存在偏差.

【分析与验证过程】

【验证PSA副本集模式】

1、PSA副本集默认写关注

shard2:PRIMARY> db.adminCommand({getDefaultRWConcern:1})

{

"defaultReadConcern" : {

"level" : "local"

},

"defaultWriteConcernSource" : "implicit",

"defaultReadConcernSource" : "implicit",

"localUpdateWallClockTime" : ISODate("2022-05-17T06:03:42.239Z"),

},

2、验证50 PSA版本默认writeConcern

备注:关闭一个数据节点后写入是否正常.

shard2:PRIMARY> cfg.members[0].stateStr

PRIMARY

shard2:PRIMARY> cfg.members[1].stateStr

(not reachable/healthy)

shard2:PRIMARY> cfg.members[2].stateStr

ARBITER

shard2:PRIMARY> use test

switched to db test

--没有指定writeConcern成功写入

shard2:PRIMARY> db.testDefaultWriteConcern.insert({w:1})

WriteResult({ "nInserted" : 1 })

--指定写入失败，说明默认majority而是官方说w:1

shard2:PRIMARY>db.testDefaultWriteConcern.insert({w:1},{writeConcern:{w:"majority",wtimeout:1000}})

WriteResult({

"nInserted" : 1,

"writeConcernError" : {

"code" : 64,

"codeName" : "WriteConcernFailed",

"errmsg" : "waiting for replication timed out",

"errInfo" : {

"wtimeout" : true,

"writeConcern" : {

"w" : "majority",

"wtimeout" : 1000,

"provenance" : "clientSupplied"

}

}

}

})

【分片使用单个PSA shard来验证来验证默认写关注级别】

1、查看集群信息

mongos> sh.status()

--- Sharding Status ---

shards:

{ "_id" : "shard2",

"host" : "shard2/10.230.10.150:21017,10.230.9.150:21017", "state" : 1,

"topologyTime" : Timestamp(1652772600, 4) }

active mongoses:

"5.0.2" : 1

autosplit:

Currently enabled: yes

databases:

{ "_id" : "config", "primary" : "config", "partitioned" : true }

2、创建分片集合

mongos> sh.enableSharding("xiaoxu")

{

"ok" : 1,

}

mongos> sh.shardCollection("xiaoxu.testDefaultWriteConcern",{_id:"hashed"})

{

"collectionsharded" : "xiaoxu.testDefaultWriteConcern",

"ok" : 1,

}

3、正常情况插入测试数据

备注:不管采用默认writeConcern还是采用w:1或者w:"majority"模式都没有问题

mongos> use xiaoxu

switched to db xiaoxu

mongos> db.testDefaultWriteConcern.insert({_id:1,name:"xiaoxu"})

WriteResult({ "nInserted" : 1 })

mongos>db.testDefaultWriteConcern.insert({_id:2,name:"xiaoxu"},{writeConcern:{w:"majority",wtimeout:1000}})

WriteResult({ "nInserted" : 1 })

mongos>db.testDefaultWriteConcern.insert({_id:3,name:"xiaoxu"},{writeConcern:{w:1}})

WriteResult({ "nInserted" : 1 })

4、模拟PSA副本中S宕机的场景来插入数据

备注:手动关闭从实例

shard2:PRIMARY> cfg.members[0].stateStr

PRIMARY

shard2:PRIMARY> cfg.members[1].stateStr

(not reachable/healthy)

shard2:PRIMARY> cfg.members[2].stateStr

ARBITER

mongos> db.testDefaultWriteConcern.insert({_id:6,name:"xiaoxu"},{w:1})

WriteResult({ "nInserted" : 1 })

mongos>

mongos>

mongos>db.testDefaultWriteConcern.insert({_id:7,name:"xiaoxu"},{w:"majority",wtimeout:10000})

WriteResult({

"nInserted" : 1,

"writeConcernError" : {

"code" : 64,

"codeName" : "WriteConcernFailed",

"errmsg" : "waiting for replication timed out; Error details: { wtimeout: true, writeConcern: { w: \"majority\", wtimeout: 10000, provenance: \"clientSupplied\" } } at shard2",

"errInfo" : {

}

}

})

异常:此时没有指定writeConcern,采用默认的行为.此时写入hang住.

mongos> db.testDefaultWriteConcern.insert({_id:8,name:"xiaoxu"})

5、分片下写入数据默认的writeConcern来源哪里？

备注:查询发现defaultWriteConcern是w:majority.这个信息是来自于config.而不是shard层面.目前config是单节点的副本集.尝试改成PSA架构试试？

mongos> db.adminCommand({getDefaultRWConcern:1})

{

"defaultReadConcern" : {

"level" : "local"

},

"defaultWriteConcern" : {

"w" : "majority",

"wtimeout" : 0

},

"defaultWriteConcernSource" : "implicit",

"defaultReadConcernSource" : "implicit",

}

6、尝试把config副本集改成PSA架构

备注:confg副本集中禁止加入仲裁节点.那么config默认是writeConcern就是{w:majority}.

config:PRIMARY> rs.reconfigForPSASet(2, cfg);

Running first reconfig to give member at index 2 { votes: 1, priority: 0 }

{

"ok" : 0,

"errmsg" : "Arbiters are not allowed in replica set configurations being used for config servers",

"code" : 103,

"codeName" : "NewReplicaSetConfigurationIncompatible",

"$gleStats" : {

"lastOpTime" : {

"ts" : Timestamp(1652693376, 3),

"t" : NumberLong(1)

}

7、针对分片集群下DefaultRWConcern相关说明

解释;

1、连接到mongos时没有显式指定writeConcern时,mongos使用全局默认设置,这个全局设置来自config副本集，而不是底层分片，所有底层分片PSA下架构默认writeConcern:{w:1}直接被config副本集全局设置覆盖.因为config不支持仲裁,所以默认是writeConcern:{w:"majority"}

8、5.0 PSA出现S宕机时,为了避免上一篇文章提到问题外.还包括如下:

如果客户端没有指定writeConcern采用默认行为会导致写入hang的情况

应对措施:

1、采用方案2.注意是临时的,等从库恢复及时重置回去，否则当主库宕机,没有办法选出新主，从而影响系统可用性,此时从宕机或者机器挂了,需要及时监控并修改配置，否则可能会影响应用使用.

2、修改config默认writeConcern为w:1虽然能解决写入hang问题，但无法解决底层分片内存压力以及性能下降问题等问题.详细查看上一篇文档说明.

9、修改分片中宕机的实例节点信息来验证写入

shard2:PRIMARY> cfg.members[1].priority=0

0

shard2:PRIMARY> cfg.members[1].votes=0

0

shard2:PRIMARY> rs.reconfig(cfg)

10、再次验证mongos插入数据

备注:经过修改后，不管是否指定writeConcern还是指定majority都可以。

注意:应用此时指定w:2就有问题.

mongos> db.testDefaultWriteConcern.insert({_id:9})

WriteResult({ "nInserted" : 1 })

mongos>db.testDefaultWriteConcern.insert({_id:10},{writeConcern:{w:"majority",wtimeout:1000}})

WriteResult({ "nInserted" : 1 })

总结:至此完成分析PSA架构包括集群下使用PSA分片存在问题以及对应方案,不管怎么应对,都需要注意潜在的影响.例如当单个数据节点宕机或者长延迟时,可以通过程序定时检测节点状态,出现异常时临时将优先级别与投票设置0来避免5.0分片集群下默认多节点写入导致hang或者客户端指定多节点写入hang问题.由此带来一致性问题与高可用性问题需要关注的.