История страницы

...

В MongoDB репликация осуществляется объединением нескольких (в типовой конфигурации - 3) узлов в Replica Set. Replica Set состоит из одного primary узла и нескольких secondary (подробнее https://docs.mongodb.com/v4.0/administration/replica-set-deployment/). Для упрощения предлагаем схему:

Primary — основной сервер mongoDB.

Secondary — точные копии баз(ы) данных с real-time синхронизацией.

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

Все операции по изменению данных выполняются только на primary. При этом MongoDB автоматически выполняет failover и смену primary на живой узел, если текущий primary выйдет из строя. Но это требует 3+ узлов в replica set.

...

где <replica_set_name> имя replica set, выбирается произвольно, но должно быть одинаково на обоих всех серверах.

Разрешить внешние подключения, прописав в параметре bindIp (bind_ip в старой версии mongo) адрес 0.0.0.0 (0.0.0.0 - разрешает подключения с любых ip адресов)

...

Параметр "host" должен содержать ip-адрес этого сервера.

Добавить в Replica Set второй узел Secondary (выполнять на первом сервере):

...

Если MongoDB отвечает на эту команду ошибкой, возможно, нет связи со вторым узлом (или там прописан bind_ip = прописан bindIp: 127.0.0.1), или там не настроен блок replication. Правильный ответ должен быть таким.
На втором узле приглашение консоли управления MongoDB должно смениться на:

root@swlc01-server:/# mongo
replica_set_name:SECONDARY>

То же самое выполнить для остальных узлов.Добавить в Replica Set узел Arbiter (выполнять на первом сервере):

replica_set_name:PRIMARY> rs.add("<ip_server3>:27017",true)
{ "ok" : 1 } 

Проверить состояние Replica Set можно выполнив в консоли MongoDB команду rs.status()

...