Как читать / писать второстепенному члену набора реплик MongoDB?

В настоящее время я планирую некоторую серверную инфраструктуру. У меня два сервера в разных местах. Мои приложения (API и прочее) работают на них обоих. Клиент подключается к ближайшему (лучшее соединение). В случае отказа одного сервера другой может обрабатывать запросы. Я хочу использовать mongodb для своих проектов. Первая идея - использовать набор реплик, поэтому я могу гарантировать согласованность данных. Если один сервер выходит из строя, данные по-прежнему доступны, а вторичный переключается на первичный. Когда приложение на основном сервере хочет использовать данные, это нормально, но другой сервер должен подключиться к основному серверу, чтобы обрабатывать данные (это решило бы аварийное переключение, но не лучшую проблему с подключением). В Mongodb есть возможность читать данные со вторичных серверов, но тогда я должен убедиться, что вставки (возможны только на первичном) согласованы на каждом вторичном сервере. Также есть вариант по этому поводу написать. Можно ли как-то указать «writeConcern на конкретном вторичном сервере»? Потому что, если добавить второй вторичный сервер без приложений, writeConcern на каждом вторичном сервере не потребуется. И если я укажу конкретное значение, я действительно не знаю, на каком вторичном сервере доступны данные, верно?

Резюме: я хочу уменьшить количество соединений между серверами при вызове api.

scheme

Пожалуйста, поделитесь некоторыми мыслями или идеями, чтобы решить мою проблему.


mongodb replicaset
person Jonaswinz    schedule 18.02.2021    source источник
comment
Если один сервер выходит из строя, данные все еще доступны, а вторичный переключается на первичный. В наборе реплик с двумя узлами это невозможно. Прежде всего, для выбора первичной обмотки требуется большинство из двух (в случае сбоя). Взгляните на Первичный-вторичный-арбитр. См. Этот пост. Имеет ли набор реплик с двумя члены имеют смысл?.   -  person prasad_    schedule 18.02.2021
comment
Хорошо, вы правы. Мне нужно как минимум 3 сервера, но вопрос все тот же.   -  person Jonaswinz    schedule 18.02.2021
comment
Приложение всегда подключается к a набору реплик, а не к конкретному члену набора реплик. Первичный реплицирует данные другим участникам (и все участники подключены). Когда член (первичный) выходит из строя, проводятся выборы между оставшимися двумя членами и избираются новые первичные выборы. Итак, приложение подключается к только что избранному первичному серверу для записи.   -  person prasad_    schedule 18.02.2021

Ответы (1)


arrow_upward
1
arrow_downward

Писать можно только на праймериз.

Чтобы контролировать, на какой вторичный объект направляются чтения, вы можете использовать max staleness, а также теги.

что вставки (возможны только на первичном) согласованы на всех вторичных.

Я не понимаю, что вы имеете в виду под этой фразой.

Если у вас есть два географически разделенных центра обработки данных, A и B, физически невозможно записать данные в A и сразу увидеть их в B. Вы должны либо дождаться распространения записи, либо дождаться, пока чтение будет извлекать данные из удаленного узла.

Чтобы оплатить стоимость во время записи, задайте для своей задачи записи количество узлов в развертывании (2 в вашем предложении). Чтобы оплатить стоимость во время чтения, используйте первичные чтения.

Обратите внимание, что простая установка задачи записи, равной количеству узлов, не приводит к тому, что все узлы всегда будут иметь одни и те же данные - это просто заставляет ваше приложение считать запись успешной только тогда, когда все узлы ее получили. Первичное звено по-прежнему может опережать конкретное вторичное с точки зрения совершаемых операций.

И, как отмечено в комментариях, набор реплик с двумя узлами не будет принимать записи, если оба члена не работают, поэтому обычно использовать такую ​​конфигурацию нецелесообразно.

Резюме: я хочу уменьшить количество соединений между серверами при вызове api.

Это не имеет ничего общего с остальной частью вопроса, и если вы действительно имеете в виду это, то это преждевременная оптимизация.

Если вам нужен более быстрый сетевой ввод-вывод, я предлагаю подумать о настройке лучшего соединения между вашим приложением и вашей базой данных (например, я полагаю, AWS предложит довольно хорошее соединение между их различными регионами).

person D. SM    schedule 18.02.2021