Фоновые индексы Mongodb-они все еще фоновые после создания?

при создании индекса в MongoDB, вы можете указать background: true флаг, который заставляет создание индекса быть неблокирующим. Это здорово в производстве, так как вы не хотите, чтобы вся база данных была заблокирована при создании индекса, который вам явно не нужен раньше (поскольку у вас его не было).

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

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

3 ответов


после создания они действуют так же, как обычные индексы. Они упорствуют в getIndexes просто как напоминание, похожее на how unique, sparse и так далее.

но это также имеет другое значение. Просто потому что изображения индексы блокируют всех писателей, в этом случае вы не сможете выполнить db.testCollection.getIndexes() пока не будут созданы все индексы. Между тем, когда вы создаете фон, то вы можете позвонить db.testCollection.getIndexes() и вы увидите, что индекс, похоже, уже созданный.

но в этом случае мы не можем быть уверены, действительно ли индексы были созданы или нет. В этом случае вам нужно позвонить db.currentOp () и если вы видите что-то вроде

{
  "inprog": [
    {
      "opid": 2001060,
      "active": true,
      "secs_running": 1,
      "op": "insert",
      "ns": "test.system.indexes",
      "insert": {
        "v": 1,
        "key": {
          "a": 1
        },
        "ns": "test.testCollection",
        "name": "a_1",
        "background": 1
      },
          ....
      "msg": "bg index build Background Index Build Progress: 368640/1000000 36%",
      "progress": {
        "done": 368640,
        "total": 1000000
      }
      ...
    }
  ]
}

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

например, вы можете сделать некоторые грубые расчеты: 368640 из 1000000 занимает 1 секунду (+1 секунда, как это возможно смещение), поэтому все должно занять 3-6 секунд (в конечном итоге это заняло 4,8 с).

очевидно, если вы не можете видеть такую операцию в процессе, то индексы уже созданы.

Примечание: если у вас много параллельных операций, вы можете указать аргумент поиска для db.currentOp(), Ф.е.

db.currentOp({"insert.background":1})

есть несколько вариантов индексирования-передний план ( по умолчанию) и фон. Передний план относительно быстрый, и он блокирует всех писателей и читателей. Другие базы данных, до которых мы еще можем добраться. Предполагается, что это не делается в производственной среде.

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

начало в MongoDB 2.6, создание индекса в фоновом режиме на первичном приведет к созданию индексов в фоновом режиме на вторичных, а также. Второстепенные начнут создание индекса, когда первичный завершит построение своего индекса.

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


У вас есть три варианта построения индексов 1) на переднем плане 2) фон 3) Роллинг (сервер за сервером)

все методы имеют свои плюсы/минусы. Мой предпочтительный метод для производственного кластера-3). Более подробную информацию в блоге я написал -https://scalegrid.io/blog/the-perils-of-building-indexes-on-mongodb/