Несколько мастеров MongoDB в ReplicaSet

Наборы реплик в MongoDB на данный момент могут иметь только одного мастера. (Он называется первичным в наборе реплик.) Для вашего сценария решение часто заключается в использовании сегментированного кластера. В вашем примере у вас будет два сегмента: один для данных сервера A, а другой для данных сервера B. Оба сегмента реализованы в виде наборов реплик, поэтому каждый из них имеет как минимум три сервера. Затем вы поместите основной сегмент A в тот же центр обработки данных A, а основной сегмент B — в центр обработки данных B. Как минимум одна реплика каждого сегмента (называемая вторичной) будет находиться в другом центре обработки данных.

Это означает, что все данные доступны в каждом центре обработки данных, но запись в сегмент A всегда должна выполняться в центре обработки данных A, а запись в сегмент B — в центре обработки данных B. (Хотя запись также может выполняться удаленно, поэтому вы может писать в шард A из центра обработки данных B, просто в данном случае это удаленная запись.)

MongoDB не является единственным мастером.

Единственный способ создать две отдельные реплики, подобные этой, в настоящее время, сохраняя их синхронизированными, — это сделать это вручную, но это не рекомендуется.

Оба экземпляра MongoDB организованы в один и тот же набор реплик.

Можно ли развернуть набор реплик с двумя мастерами, чтобы данные с сервера А были доступны в MongoDB на сервере Б и наоборот?

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

Если вы его настроили, вы УЖЕ достигли своей цели. Шардинг имеет мало (если вообще ничего) общего с высокой доступностью.

Вам не нужна конфигурация с несколькими мастерами, если у вас работает автоматическое аварийное переключение. Для этого убедитесь, что у вас есть как минимум 3 участника реплики, несущих данные, или 2+1 арбитр, чтобы они могли сформировать большинство и выбрать нового мастера в случае, если старый отключится.

Возможно, вы захотите настроить параметр electionTimeoutMillis, чтобы проверки автоматической отработки отказа происходили чаще.

При записи важных данных в БД вы можете использовать { w: большинство запись, чтобы убедиться, что ваши изменения были отражены на большинстве серверов, несущих данные, и, следовательно, долговечны.