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

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

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

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

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

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

РЕДАКТИРОВАТЬ Ответы на вопросы:

• Версия :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 Вт МБ/с, показатель util% достиг 34% при скорости 7 Вт МБ/с и 72% при скорости 52 юаней/с. Так что не насыщенная, но определенно тяжелая нагрузка по чтению -по утрам. Интересно, что, несмотря на наличие obj. размер ~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 с --fastsync, и он все еще примерно на 45 секунд отстает от (теперь основного )оптимального времени B, которое зависало примерно в 02 :19 :52UTC. Наконец, примерно через час, A догоняет, поэтому я вызываю rs.stepDown ()на B. Мгновенно rs.status ()показывает мне, что оба сервера имеют оптимальное время около 04 :08 UTC, но B (теперь вторичный )снова отстает на 17 секунд... потом 30 секунд... теперь 7 минут...

РЕДАКТИРОВАТЬ

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

РЕДАКТИРОВАТЬ (следующим вечером)

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

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