MongoDB 5.0.8 在 PSA（Primary-Secondary-Arbiter）设置中的写入性能不佳

Question

当一个数据承载成员出现故障时，我在 PSA（Primary-Secondary-Arbiter）部署中与 MongoDB 5.0.8 存在一些写入性能问题。

我知道“ 缓解 PSA 副本集的性能问题”页面以及临时解决此问题的过程。

但是，在我看来，这里描述的手动干预在操作过程中应该是不必要的。 那么我该怎么做才能确保即使节点发生故障，系统也能继续高效运行呢？ 换句话说，就像在 MongoDB 4.x 中使用“enableMajorityReadConcern=false”选项一样。

据我了解，这个问题与 defaultRWConcern 有关。 在 MongoDB 中配置 PSA 副本集时，您必须设置 DefaultRWConcern。 否则调用 rs.addArb 时会出现以下消息：

MongoServerError: Reconfig 尝试安装会更改隐式默认写入问题的配置。 使用 setDefaultRWConcern 命令设置集群范围的写入问题并再次尝试重新配置。

所以我做了

db.adminCommand({
    "setDefaultRWConcern": 1,
    "defaultWriteConcern": {
        "w": 1
    },
    "defaultReadConcern": {
        "level": "local"
    }
})

我希望这种配置在读取/写入只有一个数据承载节点可用的 PSA 系统时不会出现延迟。

但我在 mongod 日志中观察到“慢查询”消息，如下所示：

{
    "t": {
        "$date": "2022-05-13T10:21:41.297+02:00"
    },
    "s": "I",
    "c": "COMMAND",
    "id": 51803,
    "ctx": "conn149",
    "msg": "Slow query",
    "attr": {
        "type": "command",
        "ns": "<db>.<col>",
        "command": {
            "insert": "<col>",
            "ordered": true,
            "txnNumber": 4889253,
            "$db": "<db>",
            "$clusterTime": {
                "clusterTime": {
                    "$timestamp": {
                        "t": 1652430100,
                        "i": 86
                    }
                },
                "signature": {
                    "hash": {
                        "$binary": {
                            "base64": "bEs41U6TJk/EDoSQwfzzerjx2E0=",
                            "subType": "0"
                        }
                    },
                    "keyId": 7096095617276968965
                }
            },
            "lsid": {
                "id": {
                    "$uuid": "25659dc5-a50a-4f9d-a197-73b3c9e6e556"
                }
            }
        },
        "ninserted": 1,
        "keysInserted": 3,
        "numYields": 0,
        "reslen": 230,
        "locks": {
            "ParallelBatchWriterMode": {
                "acquireCount": {
                    "r": 2
                }
            },
            "ReplicationStateTransition": {
                "acquireCount": {
                    "w": 3
                }
            },
            "Global": {
                "acquireCount": {
                    "w": 2
                }
            },
            "Database": {
                "acquireCount": {
                    "w": 2
                }
            },
            "Collection": {
                "acquireCount": {
                    "w": 2
                }
            },
            "Mutex": {
                "acquireCount": {
                    "r": 2
                }
            }
        },
        "flowControl": {
            "acquireCount": 1,
            "acquireWaitCount": 1,
            "timeAcquiringMicros": 982988
        },
        "readConcern": {
            "level": "local",
            "provenance": "implicitDefault"
        },
        "writeConcern": {
            "w": 1,
            "wtimeout": 0,
            "provenance": "customDefault"
        },
        "storage": {},
        "remote": "10.10.7.12:34258",
        "protocol": "op_msg",
        "durationMillis": 983
    }

这里涉及的集合处于适当的负载下，每秒来自不同（并发）客户端的大约 1000 次读取和 1000 次写入。

MongoDB 4.x 与“enableMajorityReadConcern=false”在这里执行“正常”，我没有注意到我的应用程序有任何性能损失。 MongoDB 5.x 无法做到这一点，并且在我的应用程序中，数据堆积如山，无法以高效的方式被写入。

所以我的问题是，如果我能恢复 MongoDB 4.x 的行为。 在故障场景中可用的单个数据承载节点的写保证对我来说是可以的。 但在发生故障的情况下，实际上应该避免手动重新配置故障节点。

感谢您的任何建议！

Answer 1

最后，我们将设置更改为 PSS 布局。 这也在MongoDB 社区论坛中被推荐。