Почему моя копия MongoDB продолжает отставать?

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

Поскольку это облако, в конце концов, я создал образ моего основного (который должен копировать все данные), хотя я не мог запустить db.fsyncLock() в то время, потому что он брал некоторые записи, Новое изображение заканчивается, и я запускаю новый сервер на основе этого образа, добавляю его в свой набор реплик, удаляю старую вторичную, и жизнь хороша, не так ли? Не совсем - новая средняя отстает примерно на час назад, и в течение дня (и сегодня) в конечном итоге доходит до точки, где она отстает на 14 часов (хотя, как ни странно, все еще в окне oplog).

Я делаю следующий шаг от "повторной синхронизации устаревшей страницы участника". Завершите mongod на обоих серверах, gzip и скопируйте папку моих данных с первичной на вторичную, разархивируйте, запустите их обоих, db.fsyncLock() мой основной. Что заставляет меня думать, что даже с ТОЛЬКО ДАННЫМИ, после инициализации, мой второстепенный говорит об этом на 1 час. Я добавляю его обратно в набор реплик, и он быстро добирается до 5 минут.

Все хорошо, правда? Нет - флеш вперед, вторично продвигается sloooooowly, и теперь на 20 минут отстает. Mongostat имеет вторичный привязку с 95 + заблокированными%, iostat -xm 2 не показывает ничего сумасшедшего - первичный в настоящее время не работает, не беря записи, вторично, конечно, совсем не делает (0,04 wMB/second). Не уверен, стоит ли упоминать об этом, но в настоящее время в нем чувствуется медленная собака, не реагирующая на запись в оболочку монго и т.д.

Что дает, Монго? Почему ты не можешь догнать? Что я делаю неправильно, пытаясь заставить меня вторгаться?

ИЗМЕНИТЬ Ответы на вопросы:

  • Версия: 2.0.4
  • Аппаратное обеспечение. Оба узла - это одно и то же аппаратное обеспечение, как я могу сказать - 8 ГБ оперативной памяти, четырехъядерный процессор. Я предполагаю, что это что-то виртуализованное.
  • Скорость записи: она меняется. Как уже упоминалось, прошлой ночью я переходил на ограниченную коллекцию, которая вызвала все это. В одночасье был процесс, который записывал около нескольких сотен небольших документов (~ 155 байт каждый) несколько раз в час, поэтому макс я бы оценил около 100-200 кбайт/час. В течение дня обработка была более интенсивной, обновляя сотни тысяч 500-байтных документов и записывая еще пару сотен тысяч. Тем не менее, речь не идет об огромных количествах данных. РЕДАКТИРОВАТЬ нашел один выход из iostat с сегодняшнего дня:
Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
xvda              1.00  2564.50  243.50  282.50  8986.00 11388.00    77.47    11.32   21.46    2.36   37.93   0.50  26.50

Этот был особенно раздираем в 11 wMB/s, видел, что использование% составляло 34% с 7 wMB/s и 72% при 52 rMB/s. Так что не насыщенный, но, безусловно, тяжелая рабочая нагрузка утром. Интересно, хотя, несмотря на то, что имеет объект. размер ~ 5 ГБ и индексы ~ 1 ГБ (см. ниже), так много активности диска. Не должно ли это быть в ОЗУ?

  • Рабочий набор: я до сих пор не нашел принятую методологию расчета рабочего набора, но если это помогает:
    "collections" : 21,
    "objects" : 15540092,
    "avgObjSize" : 325.26198326238995,
    "dataSize" : 5054601144,
    "storageSize" : 5874327552,
    "numExtents" : 132,
    "indexes" : 43,
    "indexSize" : 864366720,
    "fileSize" : 10666115072,
    "nsSizeMB" : 16,
    "ok" : 1

Я не могу себе представить, что это огромная 8 ГБ ОЗУ, хотя я мог ошибаться.

  • некоторые недавние образцы мангостата из вторичных:
insert  query update delete getmore command flushes mapped  vsize    res faults locked % idx miss %     qr|qw   ar|aw  netIn netOut  conn    set repl       time 
    *0     *0     *0     *0       0     1|0       0  22.2g  44.9g   912m      0     99.2          0       0|0     0|1     2k   303b   151 mySet  SEC   03:47:54 
    *0     *0     *0     *0       0     1|0       0  22.2g  44.9g  1.85g      0      101          0       0|0     0|1     3k   303b   151 mySet  SEC   03:48:04

ИЗМЕНИТЬ

Пробовал больше вещей. Я отключил основной (теперь называемый A, вторичный будет B), удалил его данные и разархивировал его снимок (теперь пару часов назад, но на данный момент мы ничего не пишем). Начинал A up с - fastsync, и он все еще как 45 секунд позади B (теперь первичного) optime, который болтался приблизительно в 02: 19: 52UTC. Наконец, примерно через час, A догоняет, поэтому я вызываю rs.stepDown() на B. Мгновенно, rs.status() показывает мне, что оба сервера имеют опционы около 04:08 UTC, но B (теперь вторичный) снова отстает на 17 секунд... затем 30 секунд... теперь 7 минут...

ИЗМЕНИТЬ

Через несколько минут после принятия предложения @matulef и повторного создания индексов в моих закрытых коллекциях, а также повторного запуска вторичного процесса mongod, его optime только увеличился на несколько секунд. Вторичная блокировка% от монгостата по-прежнему колеблется от 95-104%, и, что интересно, размер резонатора довольно дико колебался от 100 М до 2 ГБ и обратно до оседания около 1 ГБ.

EDIT (следующий вечер)

Заключение к истории - @matulef был на правильном пути, я должен был быть более осторожным в преобразовании реплицированной коллекции в ограниченную коллекцию. Далее следует, что произошло, хотя я не рекламирую это как безопасное для данных - я свободно признаю, что, возможно, потерял некоторые данные в этом процессе, поэтому YMMV.

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

Ответы

Ответ 1

Проблема заключается в том, что у закрытых коллекций по умолчанию нет индекса _id (а команда "convertToCapped" фактически снижает все индексы для этой коллекции). Это проблема, потому что вторичные пользователи выполняют обновления, применяя ops из oplog, которые ссылаются на документы по их _ids. Если вам не хватает индекса _id, каждое обновление требует полного сканирования таблицы на вторичных устройствах, что приводит к значительному отставанию.

Решение состоит в создании индекса _id в закрытой коллекции. Однако, если вы создаете индекс на первичном, но ваши вторичные пользователи уже отстают, они не получат операцию создания индекса достаточно быстро. Вместо этого лучший способ исправить ситуацию - сначала исправить каждую отстающую вторичную, одну за другой. Для каждого из них закройте его и перезапустите в автономном режиме (на другом порту, без опции --replSet), создайте индекс _id, а затем добавьте его обратно в набор. Наконец, после того, как второстепенные объекты будут исправлены, вы можете уйти с основного и повторить процесс вместе с ним.

Обновить. В mongoDB 2.0.x и более ранних версиях по умолчанию у закрытых коллекций нет индекса _id. Тем не менее, поведение по умолчанию планируется изменить в mongoDB 2.2, так что ограниченные коллекции, созданные в версии 2.2+, будут иметь индекс _id, созданный автоматически, так же как и с коллекциями без ограничений. Для закрытых коллекций, созданных до 2.2, вам все равно придется вручную создавать индекс _id, используя описанные выше шаги, но новые коллекции не должны страдать от проблем, описанных выше.