Состояние индекса Mongodb после аварии и этапы индексации

Question

Этот вопрос имеет два аспекта, оба связаны с индексами.

У меня есть набор данных с 530 миллионами записей, каждая запись имеет массив из 10 элементов.Я использую один Mongod.Я строю индекс для массива после массовой вставки.Массив имеет две пары ключ-значение типа string - int.

Я уже вывел / исследовал , что создание индекса перед построением - это то, для чего предназначен mongodb, и такие большие наборы данных не могутбыть (после вставки) проиндексированным без огромного объема оперативной памяти / swappable-virtual-memory.

one: фазы построения индекса

Какие фазы индексаПри построении, я смотрел на бревно и видел, как оно поднялось один раз с 0 до 100%, только для того, чтобы начать считать, когда оно достигнет 100% (что-то связанное с сортировкой??).Второй этап был НАМНОГО медленнее, чем первый.Есть ли еще проходы, которые нужно сделать?

два: состояние индекса

Я не собирался наблюдать за построением индекса с такой скоростью, , и у меня есть индексированный набор данных в качестве резервной копии (которому я больше не могу доверять, продолжайте читать).Итак, я kill -9'd процесс.Я снова запустил процесс, и в журналах указана база данных, подтверждающая, что операция построения индекса выполнялась и завершилась неправильно, но ничего кроме этого.Индекс отображается в списке db.<db-name>.getIndexes().

Я нахожу это ОЧЕНЬ странным, особенно бит getIndexes, я точно знаю, что создание индекса в этом случае никогда не заканчивалось, и теперь я не могу доверять резервным копиям, в которые я верюиндексация закончилась нормально.

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

Итак, как мне узнать, находится ли моя база данных в согласованном состоянии, особенно индексы?

Answer 1

Так как мне узнать, находится ли моя база данных в согласованном состоянии, в частности, индексы?

Для этого есть команда validate . Эта команда является командой блокировки, как и ремонт, но, похоже, у нее есть несколько параметров.

Итак, либо откатите конструкцию индекса, завершите ее или откажитесь запускать без операции восстановления.

Согласовано. И журналы должны быть предельно ясны о состоянии, когда БД перезапускается. Однако MongoDB определенно еще не «там».

Второй этап был НАМНОГО медленнее, чем первый. Есть ли еще проходы, которые нужно сделать?

Действительно, после завершения второго этапа БД затем блокирует и выполняет гигантский fsync, когда он сбрасывает вновь созданный индекс на диск. Вероятно, это было здесь, когда ты убил его.

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