Во время преобразования коллекции в ограниченную коллекцию прошлой ночью мой вторичный оптимум начал отставать от основного. Он продвигался медленно, пару секунд каждые несколько минут и, в конце концов, выпал из основного окна. В соответствии с инструкциями здесь я остановил 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 снова были счастливы, а репликация вернулась синхронизация с тех пор.
