Другим сценарием является то, что вы нанесли нулевой объект в тип значения . Например, код ниже:
object o = null;
DateTime d = (DateTime)o;
Он выкинет NullReferenceException
в роли. В приведенном выше примере это кажется совершенно очевидным, но это может произойти в более «поздних связующих» сложных сценариях, где нулевой объект был возвращен из некоторого кода, которого вы не являетесь, и приведение, например, генерируется некоторой автоматической системой.
Одним из примеров этого является этот простой фрагмент привязки ASP.NET с элементом управления календарем:
" />
Здесь SelectedDate
на самом деле является свойством - типа DateTime
- типа Calendar
Web Control, и привязка может отлично вернуть что-то null. Неявный генератор ASP.NET создаст кусок кода, который будет эквивалентен приведенному выше методу. И это поднимет NullReferenceException
, что довольно сложно определить, потому что он лежит в сгенерированном ASP.NET коде, который компилирует отлично ...
Когда у меня была та же проблема, я остановил свой сервер mongo и снова начал его с помощью команды
mongod --repair
Перед запуском операции восстановления вы должны проверить, достаточно ли свободного места на вашем жестком диске (мин - размер вашей базы данных)
Если вам нужно выполнить полный ремонт, используйте параметр repairpath
. Направьте его на диск с более доступным пространством.
Например, на моем Mac я использовал:
mongod --config /usr/local/etc/mongod.conf --repair --repairpath /Volumes/X/mongo_repair
Обновление: на Билет основного сервера MongoDB 4266 , вам может потребоваться добавить --nojournal
, чтобы избежать ошибки:
mongod --config /usr/local/etc/mongod.conf --repair --repairpath /Volumes/X/mongo_repair --nojournal
Только один способ, которым я смог это сделать. Нет гарантии безопасности ваших существующих данных.
Немедленно удалите файлы данных и перезапустите mongod.
Например, с помощью ubuntu (путь по умолчанию к данным: / var / lib / mongodb) у меня было пару файлов с именем вроде: collection. #. Я сохраняю коллекцию.0 и удаляю все остальные.
Кажется более простым способом, если у вас нет серьезных данных в базе данных.
UPDATE: с командой compact
и WiredTiger похоже, что дополнительное пространство на диске будет фактически выпущено в OS .
UPDATE: с v1.9 + есть команда compact
.
Эта команда выполняет уплотнение «в строке». Это все равно потребуется дополнительное пространство, но не так много.
MongoDB сжимает файлы:
Вы можете сделать это «сжатие» на mongod --repair
или путем прямого подключения и запуска db.repairDatabase()
.
В любом случае вам нужно место для копирования файлов. Теперь я не знаю, почему у вас недостаточно места для выполнения компрессии, однако у вас есть некоторые опции, если у вас есть другой компьютер с большим объемом.
mongoexport
), а затем вы можете импортировать ту же базу данных (используя mongoimport
). Это приведет к сжатию новой базы данных. Теперь вы можете остановить замену оригинала mongod
новыми файлами базы данных, и вам хорошо идти. В настоящее время нет хорошего способа «сжать на месте» с помощью Mongo. И Mongo может определенно сосать много места.
Лучшей стратегией сейчас для уплотнения является запуск настройки Master-Slave. Затем вы можете сжать Slave, позволить ему догнать и переключить их. Я знаю еще немного волосатого. Может быть, команда Монго придумает лучшее уплотнение на месте, но я не думаю, что это высоко в их списке. В настоящее время пространство на диске считается дешевым (и обычно оно).
Mongodb 3.0 и выше имеет новый механизм хранения - WiredTiger. В моем случае при переключении двигателя уменьшено использование диска с 100 Гб до 25 ГБ.
Файлы базы данных не могут быть уменьшены по размеру. В то время как «восстанавливая» базу данных, только сервер mongo может удалить некоторые из своих файлов. Если большой объем данных был удален, сервер mongo «освободит» (удалить), во время ремонта, некоторые из его существующих файлов.
Нам нужно решить два способа, основанных на StorageEngine.
1. MMAP (): команда
: db.repairDatabase ()
ПРИМЕЧАНИЕ: repairDatabase требует свободного дискового пространства, равного размеру вашего текущего набора данных плюс 2 гигабайта. Если на томе, на котором хранится dbpath, недостаточно места, вы можете установить отдельный том и использовать его для ремонта. При установке отдельного тома для repairDatabase вы должны запустить repairDatabase из командной строки и использовать переключатель --repairpath, чтобы указать папку для хранения временных файлов восстановления. например: Представьте, что размер БД составляет 120 ГБ, (120 * 2) +2 = 242 ГБ. Требуется место на жестком диске.
другой способ, которым вы коллекционируете мудрый, команда: db.runCommand ({compact: 'collectionName '})
2. WiredTiger: он автоматически разрешил сам.
В MongoDB наблюдается некоторая значительная путаница в вопросе о мелиорации, и некоторые рекомендуемые практики совершенно опасны для определенных типов развертывания. Подробнее см. Ниже:
TL; DR repairDatabase
пытается спасти данные из автономных развертываний MongoDB, которые пытаются восстановить повреждение диска. Если он восстанавливает пространство, это чисто побочный эффект.
WiredTiger: для автономного узла с WiredTiger запуск compact
приведет к освобождению места к ОС, с одной оговоркой: команда compact
на WiredTiger на MongoDB 3.0.x была затронута этой ошибкой: SERVER-21833 , которая была исправлена в MongoDB 3.2.3. До этой версии compact
на WiredTiger можно было бы терпеть неудачу.
MMAPv1: Из-за того, как работает MMAPv1, нет безопасного и поддерживаемого метода для восстановления пространства с помощью механизма хранения MMAPv1. compact
в MMAPv1 будет дефрагментировать файлы данных, потенциально делая больше свободного места для новых документов, но он не освободит место обратно в ОС.
Вы можете быть в состоянии запустите repairDatabase
, если вы полностью понимаете последствия этой потенциально опасной команды (см. ниже), поскольку repairDatabase
по существу перезаписывает всю базу данных, отбрасывая поврежденные документы. В качестве побочного эффекта это создаст новые файлы данных MMAPv1 без какой-либо фрагментации на нем и освободит место обратно в ОС.
Для менее предприимчивого метода возможно выполнение mongodump
и mongorestore
хорошо в развертывании MMAPv1, при условии размера вашего развертывания.
Для конфигураций набора реплик лучший и самый безопасный способ для восстановления пространства - это выполните начальную синхронизацию как для WiredTiger, так и для MMAPv1.
Если вам нужно восстановить пространство со всех узлов в наборе, вы можете выполнить скользящую начальную синхронизацию. То есть, выполнить начальную синхронизацию для каждого из вторичных, прежде чем, наконец, отступить от основного и выполнить начальную синхронизацию. Роллинг-метод начальной синхронизации - самый безопасный способ выполнения обслуживания реплик, а также не требует простоев в качестве бонуса.
Обратите внимание, что возможность выполнения начальной синхронизации также зависит от размера вашего развертывания , Для чрезвычайно больших развертываний может быть невозможно выполнить первоначальную синхронизацию, и, следовательно, ваши варианты несколько более ограничены. Если используется WiredTiger, вы можете иметь возможность вывести одну вторичную из набора, запустить ее как автономную, запустить compact
на ней и вернуться к ней.
repairDatabase
Пожалуйста, не запускайте repairDatabase
на узлах набора реплик. Это очень опасно, как указано на странице repairDatabase page и описано более подробно ниже.
Имя repairDatabase
немного вводит в заблуждение, так как команда не пытается ремонт ничего. Команда была предназначена для использования при повреждении диска на автономном узле , что может привести к повреждению документов.
Команда repairDatabase
может быть более точно описана как «спасение» база данных". То есть, он воссоздает базы данных, отбрасывая поврежденные документы, пытаясь получить базу данных в состояние, в котором вы можете запустить ее, и избавить от него неповрежденный документ.
В развертываниях MMAPv1 эта перестройка файлов базы данных освобождает место для ОС как побочный эффект. Освобождение пространства для ОС никогда не было целью.
repairDatabase
для набора реплик В наборе реплик MongoDB ожидает, что все узлы в наборе будут содержать одинаковые данные. Если вы запустили repairDatabase
на узле набора реплик, есть вероятность, что узел содержит необнаруженное повреждение, а repairDatabase
послушно удалит поврежденные документы для вас.
Как и ожидалось, это делает этот узел другой набор данных из остальной части набора. Если произойдет обновление, которое ударит по этому единственному документу, весь набор может сработать.
Чтобы ухудшить ситуацию, вполне возможно, что эта ситуация может оставаться бездействующей в течение длительного времени, только чтобы внезапно ударить без видимых причина.
Похоже, что Mongo v1.9 + имеет поддержку компактности на месте!
> db.runCommand( { compact : 'mycollectionname' } )
См. документы здесь: http://docs.mongodb.org/manual/reference / command / compact /
«В отличие от repairDatabase, компактная команда не требует двойного дискового пространства для выполнения своей работы. Для работы требуется небольшое количество дополнительного пространства. Кроме того, compact быстрее. "
Компактность всех коллекций в текущей базе данных
db.getCollectionNames().forEach(function (collectionName) {
print('Compacting: ' + collectionName);
db.runCommand({ compact: collectionName });
});
Начиная с версии 2.8 Mongo, вы можете использовать сжатие . У вас будет 3 уровня сжатия с движком WiredTiger, mmap (который по умолчанию в 2.6 не обеспечивает сжатия):
Ниже приведен пример того, сколько места вы сможете сохранить для 16 ГБ данных:
[/g4]
данные взяты из этой статьи .
В общем случае компактность предпочтительнее repairDatabase. Но одно преимущество ремонта по сравнению с компактным - вы можете выполнить ремонт всего кластера. компактный, вам нужно входить в каждый осколок, что раздражает.
У меня была та же проблема, и я решил просто сделать это в командной строке:
mongodump -d databasename
echo 'db.dropDatabase()' | mongo databasename
mongorestore dump/databasename
В случае удаления большого фрагмента данных из коллекции, и коллекция никогда не использует удаленное пространство для новых документов, это пространство должно быть возвращено в операционную систему, чтобы оно могло использоваться другими базами данных или коллекциями.
Поведение процесса уплотнения зависит от механизма MongoDB следующим образом
db.runCommand({compact: collection-name })
MMAPv1
Операции дефрагментации операций уплотнения данных и amp; индексов. Однако он не освобождает место для операционной системы. Операция по-прежнему полезна для дефрагментации и создания более непрерывного пространства для повторного использования MongoDB. Тем не менее, это бесполезно, когда свободное место на диске очень мало.
Во время операции уплотнения требуется дополнительное пространство на диске до 2 ГБ.
Блокировка уровня базы данных
WiredTiger
Механизм WiredTiger обеспечивает сжатие по умолчанию, которое потребляет меньше места на диске, чем MMAPv1.
Компактный процесс освобождает свободное пространство к операционной системе. Для выполнения компактной операции требуется минимальное дисковое пространство. WiredTiger также блокирует все операции с базой данных, так как он нуждается в блокировке уровня базы данных.
Для механизма MMAPv1 компактность не возвращает пространство в операционную систему. Для освобождения неиспользуемого пространства вам потребуется выполнить операцию восстановления.
db.runCommand({repairDatabase: 1})
Здесь вы можете найти подробную информацию о компактной работе здесь