Поддержание зеркальной базы данных набора реплик MongoDB

Мы запускаем набор реплик MongoDB с тремя участниками в производственной среде.

Нам нужно будет поддерживать клон этого набора реплик, который называется «зеркалом», для внутренней аналитики. Это зеркало не обязательно должно быть в режиме реального времени, но чем больше оно обновлено, тем лучше (может быть отставание максимум на 1 день).

Каковы наиболее подходящие методы обслуживания такой зеркальной базы данных? (Обратите внимание, что это зеркало может быть набором реплик с 1 участником или автономным экземпляром)

К вашему сведению, мы пробовали 2 варианта, но их скорость оказалась неприемлемой:

  1. Переигрывание оплога. Но это заняло так много времени (~ 40 часов, чтобы воспроизвести оплог из первичного набора реплсетов).
  2. Периодически использовал снимок из производственного набора, но новый том (созданный из снапшота) был очень медленным, потому что он не прогревался (мы используем AWS EBS, прогрев занял ~12 часов)

Update #1: Мы также пытались сделать зеркало членом набора реплик, но мы хотели отделить зеркало от набора реплик, поэтому этот вариант не удовлетворяет требованиям.

Update #2: Причина, по которой мы не хотим, чтобы это зеркало было членом replset: мы выполняли тяжелые запросы к этому зеркалу и привели к тому, что у него закончились кредиты ресурсов (дисковый ввод-вывод, сетевой ввод-вывод, ЦП), и экземпляр стал временно недоступен. Это изменило всю структуру набора повторений (потому что он потерял один узел). Когда экземпляр снова стал доступен, он снова изменил структуру replset (добавил еще один узел). Эти изменения сильно повлияли на реплсет.

Спасибо.


person tung    schedule 17.12.2014    source источник
comment
Использовать отложенный набор реплик? (docs.mongodb.org/manual/tutorial/) Вы можете выбрать задержку.   -  person joao    schedule 17.12.2014
comment
Спасибо. Есть ли возможность отделить зеркало? Задержанный элемент по-прежнему принадлежит к набору реплик.   -  person tung    schedule 17.12.2014
comment
Почему вы не хотите, чтобы он принадлежал набору реплик?   -  person joao    schedule 17.12.2014
comment
Поскольку мы выполняли тяжелые запросы к этому зеркалу, из-за чего у него закончились кредиты ресурсов (дисковый ввод-вывод, сетевой ввод-вывод, ЦП), и экземпляр стал временно недоступен. Это изменило всю структуру набора повторений (потому что он потерял один узел). Когда экземпляр снова стал доступен, он снова изменил структуру replset (добавил еще один узел). Эти изменения сильно повлияли на реплсет. Вот почему я не хочу, чтобы зеркало было членом replset.   -  person tung    schedule 18.12.2014
comment
вы установили его приоритет на 0 и голоса на 0? и скрыто от истины? таким образом, это не меняет количество членов с правом голоса, кворум или большинство, необходимое для избрания новых предварительных выборов.   -  person Asya Kamsky    schedule 27.12.2014
comment
Точно не помню, но надо попробовать и оценить. Спасибо.   -  person tung    schedule 29.12.2014


Ответы (2)


Вы можете использовать «скрытый вторичный», как описано здесь: http://docs.mongodb.org/manual/tutorial/configure-a-hidden-replica-set-member/

Мы используем их в среде сегментированных реплик (4 сегмента, несколько вторичных серверов на сегмент) для резервного копирования. Мы отключаем скрытые вторичные серверы, делаем снимки файловой системы и после этого запускаем машины. Никогда не было проблем с производственным кластером во время/после резервного копирования. В зависимости от ваших потребностей вы можете установить задержку на индивидуальное время, чтобы реплика либо работала, либо имела настроенную задержку.

Обновление: чтобы объяснить, почему я так уверен, что это сработает: наш кластер выполняет (в масштабе MongoDB) действительно тяжелую работу с огромными заданиями M/R, высокой скоростью вставки, обновления и запросов и общей БД. размер около 10ТБ. Все на довольно небольших инстансах EC2. Мы можем без проблем отключить резервные резервные копии в любом состоянии производственного кластера. Мы делаем резервные копии более 5 раз в день уже более года и провели несколько тестов с архитектурой. Никогда не видел никаких проблем на производственном кластере. Поскольку наше приложение действительно чувствительно к задержкам, мы увидим огромное влияние на нашу систему, если во время резервного копирования возникнет какое-либо влияние задержки.

person Osterjour    schedule 27.12.2014
comment
Я тоже долго искал лучший метод. Это оно. Тот факт, что он имеет 0-приоритет, также означает, что он не может участвовать в голосовании и трахаться с вашим основным, если ему когда-либо понадобится перезапуск. У меня небольшая компания, и я могу позволить себе только 2 узла, главный и резервный-ведомый. До того, как я обнаружил это, было нервно перезапускать мастер и видеть, как он становится вторичным с slaveOk = false, пока сайт. С mongodump вам даже не нужно закрывать его, просто убедитесь, что вы также записали oplog. - person Blizz; 28.12.2014
comment
Раньше у нас был один и тот же рекомендуемый набор реплик, но когда скрытый стал недоступен (из-за того, что кредиты ресурсов закончились), весь набор реплик значительно замедлился. К вашему сведению, у нас было hidden:true и priority:0. Я не уверен, что это из-за того, что нам не хватило голосов :0? (см. комментарий @asya-kamsky под моим первоначальным вопросом) - person tung; 29.12.2014

Вы можете настроить mongodb, чтобы сделать предпочтение чтения для определенных узлов: http://docs.mongodb.org/manual/core/read-preference/#tag-sets, http://docs.mongodb.org/manual/tutorial/configure-replica-set-tag-наборы/. Использование тегов не сложно и является неплохой альтернативой «ближайшему» предпочтению чтения.

Таким образом, вы можете сделать это «зеркало» подчиненным элементом для набора реплик и использовать тег "production", чтобы ваши производственные клиенты могли читать с производственных вторичных узлов, и использовать специальный тег "mirror" для этого экземпляра «зеркала» только в случае необходимости. читать с этого экземпляра. Таким образом, зеркальный экземпляр будет полноправным членом реплики и будет постоянно обновляться. Член набора отложенных реплик для этого "зеркального " экземпляр также имеет смысл в этом случае.

Однако есть небольшая вещь, которую следует учитывать:

Когда предпочтение чтения включает набор тегов, клиент пытается найти вторичные элементы, соответствующие указанному набору тегов, и направляет чтение случайному вторичному элементу из ближайшей группы. Если ни один вторичный объект не имеет совпадающих тегов, операция чтения выдает ошибку. [1]

Во всяком случае, я бы попытался сделать это на вашем месте.

P.S. одна важная вещь о сборе статистики и аналитики ваших коллекций в MongoDB. Эксперты Mongodb в этих курсах рекомендуют \сохранять такую ​​статистику, как счетчики и т. д. во время операций записи: это означает, что если вы у вас есть коллекция пользователей, вы должны подсчитывать несколько сообщений для каждого пользователя или некоторые другие статистические данные, серия записей с $inc в некоторые поля счетчика *** будет размазывать нагрузку на базу данных, и общая производительность будет лучше, чем если вы используете сложный запросы агрегации каждый раз, когда вам нужно что-то подсчитать или получить среднее значение или сделать аналогичные запросы статистики из базы данных.

person Alexander Arutinyants    schedule 26.12.2014
comment
Спасибо. Похоже, нам нужно внести изменения в наши приложения для использования тегов. Это правильно? Это то, чего мы действительно не хотим делать. - person tung; 29.12.2014
comment
Да, к сожалению. Однако эти изменения очень легко применить. В случае с Java это похоже на установку собственных предпочтений чтения, и все: docs.mongodb.org/ecosystem/drivers/java-replica-set-semantics/. На других языках, надеюсь, тоже будет легко. И это широко распространенная передовая практика для распространения данных между удаленными центрами обработки данных, для резервного копирования и для диверсификации задач обработки данных. - person Alexander Arutinyants; 29.12.2014