Если вы используете текущую версию (3.2) MongoDB как набор реплик в вашей сети, состоящей из 3 узлов:
mongo1.local
mongo2.local
mongoarbiter.local
Теперь эти узлы должны быть доступны через общедоступный Интернет (ограничен через FW). mongo1 и mongo2 получат VIP на брандмауэре и некоторые действительные A-Records:
mongo1.example.com
mongo2.example.com
Арбитр не выставлен.
Теперь некоторые клиентские реализации просто работают нормально (python), если вы передаете внешние DNS-имена через строку подключения. Но другие (Java) не смогут подключиться, поскольку набор реплик знает только свои внутренние имена. Клиенты проанализируют список узлов, предоставленный rs, заметят, что имя externel, к которому он подключился, отсутствует в списке и завершится ошибкой:
Monitor thread successfully connected to server with description ServerDescription{address=mongo1.example.com:27017, type=REPLICA_SET_PRIMARY, state=CONNECTED, ok=true, version=ServerVersion{versionList=[3, 0, 14]}, minWireVersion=0, maxWireVersion=3, maxDocumentSize=16777216, roundTripTimeNanos=5305689, setName='mongo-rs', canonicalAddress=mongo1.local:27017, hosts=[mongo2.local:27017, mongo1.local:27017], passives=[], arbiters=[mongo3.local:27017], primary='mongo1.local:27017', tagSet=TagSet{[]}, electionId=5821da77ccc118202cd2b75d, setVersion=3}
Есть ли какое-нибудь решение, кроме как возиться с / etc / hosts в клиентской системе?
Кстати: это трюк с клиентской библиотекой js, но тоже выглядит немного грязно:
replSet.connectWithNoPrimary
Официальные драйверы MongoDB реализуют Обнаружение и мониторинг сервера (SDAM) спецификация, которая доступна на GitHub в mongodb/specifications хранилище. Спецификация SDAM более подробно описывает ожидаемое поведение и причины для драйверов.
В настоящее время ожидается, что клиенты всегда будут использовать имена хостов, перечисленные в конфигурации набора реплик, а не начальный список, указанный в строке подключения. Основной мотивацией для этого является включение автоматического переключения при отказе и реконфигурации на основе согласованной конфигурации набора реплик (который включает имена хостов и порты).
Есть ли какое-либо решение, кроме как возиться с / etc / hosts в клиентской системе?
Если вам не требуется аварийное переключение, вы можете подключиться к одному серверу, а не использовать соединение с набором реплик. Автономное / прямое соединение не должно обеспечивать обнаружение сервера.
Однако, если вы подключаетесь к чему-либо, кроме автономного сервера, на данный момент нет никаких обходных решений, кроме настройки разрешения вашего имени хоста для соответствия конфигурации набора реплик или расширения вашего сетевого периметра (например, с помощью VPN).
Соответствующее предложение функции для голосования / просмотра: СЕРВЕР-1889: Поддержка разных сетей / сетевых устройств для клиентского трафика и трафика репликации. Это может позволить отделить внутреннюю сетевую связь для набора реплик от клиентских подключений.
Если вы настроили сегментированный кластер, вы можете просто подключиться напрямую к монго процесс, и пусть это заботится о внутренних / внешних именах узлов в наборе реплик.
Если вы сделаете свой набор реплик частью сегментированный кластер, то все клиентские подключения должны проходить через монго сервер. Mongos поддерживает свои собственные подключения к узлам в наборе реплик (и может делать это, используя внутренние имена mongo1.local и т. Д.); клиент подключается только к mongos, и ему разрешено делать это, используя любое имя, которое ему нравится - он не должен совпадать с именами хостов, используемыми внутри.
Итак, даже если вы не хотите использовать сегментирование для масштабирования данных, это может быть полезно для вас, чтобы избежать проблемы адресации реплики, заданной именами внешних хостов?