Pull to refresh

Перевод — BoxedIce делится опытом перехода с MySQL на MongoDB

Reading time 6 min
Views 7.4K
Ссылка на эту статью уже мелькала на Хабре и я столкнулся с интересом к ней. Многие испытали проблемы с освоением оригинала на английском и я решил перевести ее.

Заметки об использовании MongoDB в продакшене


Год назад в июле я писал о том, что мы перешли с MySQL на MongoDB.
Мы запустили MongoDB в продакшене для сервиса мониторинга Server Density. С тех пор прошло 8 месяцев и мы столкнулись с некоторыми вещами.

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

Немного статистики


Взято с наших серверов MongoDB точнехонько 26-го февраля:
Коллекций (таблиц) 17 810
Индексов 43 175
Документов (строк) 664 158 090
В настоящее время у нас один мастер и один слэйв с ручным переключением в случае отказа БД (имеется в виду, что в случае катастрофы софт будет переключен с одной базы на другую вручную — прим.пер). Мастер-база работает на сервере с 72Гб оперативки, а слейв находится в другом ДЦ. У нас проблемы с местом на дисках и мы находимся в завершающей стадии перехода на использование автоматизированных «парных реплик» с ручным шардингом, которые работают на четырех серверах (два мастера и два слейва в разных ДЦ).

Была задержка запуска новых серверов из-за того, что мы целую неделю ждали пока все данные синхронизируются как надо и мы могли бы переключиться. Это обычный переход от первоначального вертикального «хардварного» масштабирования к горизонтальному путем добавления новых серверов по мере нашего роста. И хотя сейчас у нас ручной шардинг, мы планируем перейти на автоматический, который скоро появится в MongoDB.

Ограничения пространств имен (namespace)


Из-за того, что MongoDB имеет ограничение в 24 000 имен на каждую БД, мы разделили данные наших клиентов по трем базам. В общем, 24 000 — это общее количество коллекций и индексов на одну БД.

Вы можете проверить общее число занятых имен в базе из консоли MongoDB с помощью команды db.system.namespaces.count(). Так же, вы можете изменить размер пространств имен с помощью параметра --nssize, но тут есть засады и ограничения. Читайте документацию.

Отказоустойчивость


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

Если вы пострадали от потери питания или некорректного завершения MongoDB, вам предстоит процедура восстановления базы. Если база маленькая, то это простая процедура, запускаемая из консоли, которая, однако, заставляет MongoDB пройтись по каждому документу (прим.пер. документ в терминах mongo — это аналог строки в sql) и пересоздать его. Если у вас база, сопоставимая по размеру с нашей, то это займет часы времени.

Вы можете использовать мастер/слейв-репликацию (и желательно со слейвом в другом ДЦ), но в случае падения мастера вам нужно будет переключать софт вручную. Или же вы можете воспользоваться «парной репликой», которая сама решает кто в ней мастер и в случае падения второго сервера целостность данных (после его поднятия) нарушена не будет (был использован термин eventually consistent — прим.пер).

Репликация больших баз


Наши базы данных очень большие и полная заливка свежих данных на новый слейв в отдельном ДЦ через VPN занимает от 48 до 72 часов. В течении этого времени вам должно быть сцыкотно, так как слейв еще не работает.

В дополнение к этому, вы должны удостовериться в том, что ваш op log достаточно велик чтобы вместить все операции с момента начала синхронизации [с новым слейвом]. MongoDB сливает данные на диск в момент начала и завершения синхронизации, а в промежутке хранит все операции в op log’е.

Мы обнаружили, что в нашем случае необходим op log размером аж в 75Гб. Размер устанавливается параметром --oplogSize. Что интересно, эти файлы [op log] создаются до того как MongoDB начинает принимать соединения. Поэтому вам придется подождать пока операционка насоздает около 37 файлов для логов по 2Гб каждый.

На наших быстрых дисках SAS 15K [rpm] на каждый такой файл уходит от 2 до 7 секунд (около 5 минут всего), а вот на некоторых наших старых тестовых тачках на файл уходит до 30 секунд (на все файлы до 20 минут).

В течении этого времени ваша база недоступна.

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

Есть решение проблемы. Нужно самим создать эти файлы. Тогда MongoDB не будет пытаться сделать это самостоятельно. Выполните команды ниже (после того как вы нажмете ввод после done будет создано 80Гб файлов):
   for i in {0..40}
    do
    echo $i
    head -c 2146435072 /dev/zero > local.$i
    done

Теперь остановите MongoDB, убедитесь что все старые local.* файлы удалены и после этого переместите новые файлы в директорию с данными. После этого запустите MongoDB.

Это будет работать для --oplogSize=75000. Имейте в виду, что создание этих файлов засрет I/O и замедлит все что есть, но не уронит базу, она будет доступна. Ессно, ничто не мешает вам создать эти файлы на другой тачке и скопировать по сети (имхо, полезнее сделать renice «создавалке файлов», поправьте если что — прим.пер).

Замедление при первой синхронизации


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

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

Это приводит к тому, что процессам веб-сервера требуется больше времени на обработку каждого запроса, так что увеличивается загрузка процессора.

У меня есть теория. Так как слейв читает с мастера все данные из всех коллекций всех баз данных, то кеш активно инвалидируется и пользы от него ноль. Но я не уверен. Это не было заявлено в MongoDB, так как это реально не проблема.

Однако, это может быть проблемой, если ваш сервер не сможет переварить нагрузку от процессов апача (sic!). Короче, на грани.

Запуск демона MongoDB и логгирование


В прошлом мы запускали MongoDB под screen'ом, но теперь при запуске достаточно указать параметр --fork и MongoDB запустится как нормальный демон.

Не забудьте указать --logpath чтобы быть в курсе возникающих ошибок. Еще мы используем параметр --quiet, так как в лог записывается слишком много, он быстро растет и у MongoDB нет встроенной ротации логов.

Настройки операционки


Мы столкнулись с проблемой ограничения числа открытых файлов, которая вызвана лимитом по-умолчанию. Обычно это 1024, что маловато. В документации по MongoDB есть пара слов об этом, но вы можете увеличить лимит. В Redhat это меняется в файле /etc/security/limits.conf. Так же вам нужно включить UsePAM в /etc/ssh/sshd_config для того, чтобы новые лимиты распространялись на вас при логине.

Еще мы выключили atime на всех серверах с базами, чтобы файловая система не обновляла дату и время доступа к файлу каждый раз как MongoDB к нему обращается.

Блокировки при создании индексов


Мы создаем наши индексы первым делом, так что времени это занимает мало.
Однако, если вы создаете новый индекс в существующей коллекции, это этот процесс заблокирует базу пока создание индекса не закончится.

Это исправлено в ветке MongoDB 1.3 — там появилось фоновое индексирование.

Эффективность использования дискового пространства


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

Очевидно, слейв копирует данные и складирует их у себя наиболее оптимальным способом (нет проплешин из-за удаленных данных), так что после первой синхронизации слейва он занимает меньше места на диске чем мастер. Однако, мы видели мастера с почти 900Гб по диску, слейв которого получился размером в 350Гб.

Мы запостили эту проблему в коммерческую службу поддержки MongoDB.

Техническая поддержка радует


Даже до того как 10gen (компания разрабатывающая MongoDB) получила 1,5 млн. долларов инвестиций, поддержка была клевой. И является такой и в настоящий момент.

Мы взяли у них услугу Золотой коммерческой поддержки и она много раз приносила пользу когда мы сталкивались с проблемами.
Их система тикетов юзабельна, плюс мы невероятно быстро получаем ответы от разработчиков. Так же я могу названивать им голосом круглые сутки семь дней в неделю.

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

Заключение — был ли переход на MongoDB верным шагом?


Да. MongoDB оказалась отличным выбором. Администрирование больших баз данных простое, база отлично масштабируется, а поддержка — высший класс.

Единственная фишка, которой мне не хватает и я ее с нетерпением жду — это авто-шардинг. Мы делаем шардинг вручную, но если этим будет рулить сама MongoDB, то это будет реально круто!

— David Mytton, оригинал
— перевод Snick

PS: с радостью исправлю ошибки перевода и опечатки, но прошу, пишите по этому поводу в личку, а комментариям оставим суть.
Tags:
Hubs:
+44
Comments 11
Comments Comments 11

Articles