Любая база данных имеет множество журналов, и MongoDB не является исключением. В MongoDB существует четыре типа журналов, а именно системный журнал, журнал журнала, журнал oplog master-slave, журнал медленных запросов и т. д. Эти журналы отслеживают различные аспекты базы данных MongoDB. Эти типы журналов описаны ниже.
Системный журнал
Системный журнал очень важен в базе данных MongoDB, он записывает операции запуска и остановки MongoDB, а также любую ненормальную информацию, возникающую во время работы сервера.
Метод настройки системного журнала относительно прост, вы можете указать параметр logpath при запуске mongod.
mongod -logpath=/data/log/mongodb/serverlog.log -logappend
Системный журнал будет постоянно добавляться к файлу, указанному в logpath.
Журнал журнала
Функция ведения журнала — очень важная функция в MongoDB, которая обеспечивает целостность данных сервера базы данных в случае непредвиденного сбоя питания, стихийных бедствий и т. д. Он повышает надежность MongoDB за счет ведения журнала повторов с опережающей записью. Когда эта функция включена, MongoDB будет создавать журнал журнала при записи, который содержит адрес диска и байты, специально измененные операцией записи. Таким образом, в случае внезапного отключения сервера журнал можно воспроизвести при запуске для повторного выполнения операций записи, которые не были сброшены на диск до отключения.
MongoDB настраивает механизм WiredTiger для использования буфера в памяти для сохранения записей журнала, а WiredTiger синхронизирует буферизованные записи журнала с диском в соответствии со следующими интервалами или условиями.
- Синхронизируйте буферизованные данные журнала с диском каждые 50 мс, начиная с MongoDB 3.2.
- WiredTiger принудительно синхронизирует файлы журналов, если для операций записи установлено значение j:true.
- Поскольку ограничение размера файла журнала, используемое MongoDB, составляет 100 МБ, WiredTiger создает новый файл журнала примерно каждые 100 МБ данных. Когда WiredTiger создает новый файл журнала, WiredTiger синхронизирует предыдущий файл журнала.
Когда MongoDB достигает указанной выше фиксации, она записывает операцию обновления в журнал. Это означает, что MongoDB фиксирует изменения пакетами, то есть каждая запись не сразу сбрасывается на диск. Однако при настройках по умолчанию невозможно потерять более 50 мс записанных данных при сбое системы.
Файлы данных сбрасываются на диск каждые 60 секунд по умолчанию, поэтому файлы журнала должны записывать записанные данные только в течение примерно 60 секунд. Система журналов заранее выделяет для этой цели несколько пустых файлов, которые хранятся в каталоге /data/db/journal, а имена каталогов _j.0, _j.1 и т. д. После запуска MongoDB в течение длительного времени в каталоге журнала появятся файлы, похожие на _j.6217 и _j.6218.Это текущие файлы журнала, и значения в файлах будут увеличиваться по мере увеличения времени работы MongoDB. После нормального завершения работы базы данных файлы журнала очищаются (поскольку они больше не нужны после нормального завершения работы).
При записи данных в mongodb они сначала записываются в память, а затем сбрасываются каждые 60 с. Аналогично, журнал сначала записывается в соответствующий буфер, а затем файл журнала сбрасывается на диск каждые 50 мс. С помощью WiredTiger MongoDB может восстанавливаться с последней контрольной точки (контрольная точка может рассматриваться как зеркало) даже без функции журнала; однако для восстановления изменений, сделанных после последней контрольной точки, вам все равно нужно использовать журнал.
Если произойдет сбой системы или база данных будет принудительно закрыта с помощью команды kill -9, mongod воспроизведет файл журнала при запуске и одновременно отобразит большое количество проверочной информации.
Все вышеперечисленное относится к движку WiredTiger.Для движка MMAPv1 он немного отличается.Во-первых, он обновляет диск каждые 100 мс.Во-вторых, он записывает файл журнала через приватное представление и записывает файл данных через общее представление. Я не буду здесь слишком много объяснять, потому что MongoDB 4.0 не рекомендует использовать этот механизм хранения. WiredTiger — это механизм хранения по умолчанию, рекомендованный MongoDB, начиная с версии 3.2 MongoDB.
Следует отметить, что если скорость записи клиента превышает скорость сброса журнала, mongod ограничит операцию записи до тех пор, пока журнал не завершит запись на диск. Это единственный случай, когда mongod будет ограничивать запись.
Ограниченная коллекция
Прежде чем говорить о следующих двух видах журналов, давайте познакомимся с закрытой коллекцией.
Обычные коллекции в MongoDB создаются динамически и могут автоматически увеличиваться для размещения большего количества данных. В MongoDB есть еще один тип коллекции, который называется фиксированной коллекцией. Фиксированную коллекцию нужно создать заранее, и ее размер фиксирован. Фиксированные коллекции ведут себя так же, как циклические очереди. Если места нет, самый старый документ будет удален, чтобы освободить место, а вновь вставленный документ займет это место.
Создайте фиксированную коллекцию:
db.createCollection("collectionName",{"capped":true, "size":100000, "max":100})
Создается коллекция фиксированного размера размером 100 000 байт, а количество документов равно 100. Независимо от того, какое ограничение будет достигнуто первым, новые документы, вставленные позже, вытеснят самый старый документ из коллекции:Количество документов в фиксированной коллекции не может превышать ограничение на количество документов или размер.
Фиксированные коллекции нельзя изменить после их создания, а фиксированные коллекции нельзя преобразовать в нефиксированные коллекции, но обычные коллекции можно преобразовать в фиксированные коллекции.
db.runCommand({"convertToCapped": "test", "size" : 10000});
Фиксированные коллекции можно сортировать особым образом, называемым естественной сортировкой. Порядок, в котором документы в результирующем наборе возвращаются при естественной сортировке, является порядком документов на диске. Естественный порядок — это порядок вставки документов, поэтому документы, полученные естественным порядком, располагаются от самого старого к самому новому. Конечно, вы также можете следовать от нового к старому:
db.my_capped_collection.find().sort({"$natural": -1});
oplog ведущий-ведомый журнал
Наборы реплик используются для резервного копирования данных между несколькими серверами. Функция репликации MongoDB реализована с использованием oplog журнала операций, который содержит каждую операцию записи главного узла. Oplog — это фиксированная коллекция в локальной базе данных главного узла. Узел резервного копирования может узнать операции, которые необходимо реплицировать, запросив эту коллекцию.
Все базы данных в инстансе mongod используют один и тот же оплог, то есть логи операций (вставка, удаление, модификация) всех баз будут записываться в оплог
Каждый резервный узел ведет свой оплог, который записывает каждую операцию копирования данных с основного узла. Таким образом, каждый участник может использоваться в качестве источника синхронизации для других участников. Как показано на рисунке, резервный узел получает операции, которые необходимо выполнить, из используемого в данный момент источника синхронизации, затем выполняет эти операции над своим собственным набором данных и, наконец, записывает эти операции в свой оплог. что может произойти только в том случае, если данные источника синхронизации повреждены или несовместимы с данными основного узла), то резервный узел прекратит репликацию данных из текущего источника синхронизации.
Оплог хранит все выполненные операции записи по порядку.Каждый член наборов реплик поддерживает свой собственный оплог, и оплог каждого члена должен быть точно таким же, как оплог мастер-узла (может быть некоторая задержка)
Если резервный узел по какой-то причине зависает, но перезапускается, он автоматически начнет синхронизацию с последней операции в оплоге. Поскольку процесс операции копирования заключается в копировании данных и записи их в oplog, узел резервного копирования может снова выполнить операцию копирования для данных, которые были синхронизированы. MongoDB был разработан с учетом этого: выполнение одной и той же операции в оплоге несколько раз имеет тот же эффект, что и однократное выполнение.
Поскольку размер оплога фиксирован, он может содержать только определенное количество оплогов. Как правило, использование oplog растет примерно с той же скоростью, с которой система обрабатывает запросы на запись: если 1 КБ запросов на запись обрабатывается в минуту на основном узле, то oplog, вероятно, также будет записывать 1 КБ oplog за одну минуту.
Однако есть некоторые исключения: если один запрос может повлиять на несколько документов (например, удалить несколько документов или обновить несколько документов), в оплоге появится несколько журналов операций. Если одна операция влияет на несколько документов, то каждый затронутый документ будет иметь журнал в оплоге. Следовательно, если db.student.remove() выполняется для удаления 10w документов, то в оплоге будет 10w логов операций, и каждый лог соответствует удаленному документу. Если вы выполняете много массовых операций, оплог может быстро заполниться.
журнал медленных запросов
Системный профилировщик используется в MongoDB для поиска операций, которые занимают слишком много времени. Системный профилировщик записывает операции в фиксированную коллекцию system.profile и предоставляет много информации об операциях, которые занимают слишком много времени, но общая производительность соответствующего монгода также будет снижена. Поэтому мы обычно периодически открываем профайлер для получения информации.
По умолчанию системный анализатор выключен и журналирование не ведется. можно запустить в оболочкеdb.setProfilingLevel()открыть анализатор
db.setProfilingLevel(level,<slowms>) 0=off 1=slow 2=all
Первый параметр — это указанный уровень. Разные уровни имеют разные значения: 0 означает закрыто, 1 означает, что операция записи по умолчанию занимает более 100 миллисекунд, а 2 означает, что все операции записываются. Второй параметр — настроить стандарт «слишком долго», например запись всех операций, которые занимают 500 мс.
db.setProfilingLevel(1,500);
Если профилировщик включен, а коллекция system.profile не существует, MongoDB создает для нее ограниченную коллекцию размером в несколько МБ. Если вы хотите, чтобы профилировщик работал дольше, вам может потребоваться больше места для регистрации большего количества операций. На этом этапе вы можете закрыть профилировщик, удалить и заново создать новую фиксированную коллекцию с именем system.profile и привести ее емкость в соответствие с требованиями. Затем снова включите анализатор в базе данных.
Максимальную емкость коллекции можно просмотреть с помощью db.system.profile.stats().
Если понравится, можете обратить внимание на паблик WeChat: рано или поздно программисты Программист, который настаивает на написании оригинальных статей, здесь один человек также может испытать карнавал группы людей, и теперь он фокусируется на обмене технологиями, такими как распределенные, Spring, MongoDB, Kafka, HBase, исходный код JDK и взаимное обучение. .