Плохая производительность записи с MongoDB 5.0.8 в настройке PSA (Primary-Secondary-Arbiter)

Question

У меня есть некоторые проблемы с производительностью записи с MongoDB 5.0.8 в развертывании PSA (Primary-Secondary-Arbiter), когда один член, несущий данные, выходит из строя.

Мне известно о странице « Устранение проблем с производительностью с помощью набора реплик PSA » и о процедуре временного решения этой проблемы.

Однако, на мой взгляд, описанное здесь ручное вмешательство не должно быть необходимым во время работы. Итак, что я могу сделать, чтобы система продолжала работать эффективно даже в случае сбоя узла? Другими словами, как в MongoDB 4.x с параметром «enableMajorityReadConcern=false».

Насколько я понимаю, проблема как-то связана с файлом defaultRWConcern. При настройке набора реплик PSA в MongoDB вы вынуждены установить 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 .