Мы используем mongodb версии 3 в среде AWS с AMI Linux.
Изначально mongo вел журнал всего документа. Затем мы снизили многословность в ямле. Похоже, из-за этого большинство (99%) документов не регистрировались. Однако мы по-прежнему обнаруживаем, что иногда запись все еще сохраняется. Кажется, что выполняется WRITE, а затем COMMAND, и оба содержат всю запись.
Есть ли способ гарантировать, что документ никогда не будет записан в журнал, при этом сохраняя полезное ведение журнала?
Спасибо
systemLog:
quiet: true
destination: file
path: /var/log/mongodb.log
logAppend: true
logRotate: rename
traceAllExceptions: false
timeStampFormat: iso8601-utc
verbosity: 1 # This will be inherited by any component with verbosity -1
component:
accessControl:
verbosity: -1 # NOTE: Negative one (-1) means "inherit"
command:
verbosity: 0 # MUST BE ZERO!!! Otherwise, inserted/updated records (all the data) will get logged.
control:
verbosity: -1
geo:
verbosity: 0
index:
verbosity: -1
network:
verbosity: -1
query:
verbosity: -1
replication:
verbosity: -1
sharding:
verbosity: 0
storage:
verbosity: -1
write:
verbosity: 0 # MUST BE ZERO!!! Otherwise, inserted/updated records (all the data) will get logged.
Версия и Журналы выглядят так. Обратите внимание, что я ввел данные, поэтому любые недопустимые json или опечатки связаны со мной, а не с mongo.
Версия 3.0.6
TIMESTAMP I WRITE [conn0001] insert project.collection query {<insert our json document here>}
ninserted:1
keyUpdates:0
writeConflicts:0
numYields:0
locks:{Global: {acquireCount: {r: 2, w: 2}}, MMAPV1Journal: {acquireCount: {w:2},aquireWaitCount: {w:2},
timeAquiringMicros: {w: 119326}}, Database: {acquireCount:w: 2}}, Collection" {acquireCount: {W:1}}, oplog: {acquireCount: {w: 1}}} 119ms
TIMESTAMP I COMMAND [conn0001] insert project.$cmd command: insert {<insert our json document here>}
ninserted:1
keyUpdates:0
writeConflicts:0
numYields:0
reslen: 80
locks:{Global: {acquireCount: {r: 2, w: 2}}, MMAPV1Journal: {acquireCount: {w:2},aquireWaitCount: {w:2},
timeAquiringMicros: {w: 119326}
timeAquiringMicros: {w: 119326}}, Database: {acquireCount:w: 2}}, Collection" {acquireCount: {W:1}}, oplog: {acquireCount: {w: 1}}} 119ms
Ваши запросы вставки регистрируются, потому что они считаются медленными запросами - занимают больше времени, чем по умолчанию operationProfiling.slowOpThresholdMs значение 100 мс. Как и в MongoDB 3.2, нет какой-либо конфигурации того, какие детали должны регистрироваться при медленных запросах, поскольку этот контекст полезен для понимания того, почему запрос медленный.
Вы можете избежать регистрации медленных вставок / команд, увеличив slowOpThresholdMs в твоем mongod Файл конфигурации. Например, установка более высокого slowOpThresholdMs 250 мс может быть достаточно, чтобы гарантировать, что большинство вставок не регистрируются (хотя действительно медленные все еще могут быть):
operationProfiling:
slowOpThresholdMs: 250
Если вы хотите, чтобы медленные операции никогда не регистрировались, вы можете установить гораздо более высокое значение, но это может скрыть детали, которые могут иметь отношение к производительности вашего развертывания.
Есть ли способ гарантировать, что документ никогда не будет записан в журнал, при этом сохраняя полезное ведение журнала?
Как правило, полезное ведение журнала для устранения неполадок включает в себя подробную информацию о медленных запросах, а также информацию о подключении / репликации / аутентификации (которую вы подавили с помощью quiet:true).
Без регистрации этих данных у вас могут возникнуть трудности с настройкой и поддержкой производственной среды.
Если вас беспокоит доступ к частной информации в mongod log файлы, я бы позаботился о том, чтобы вы правильно ограничили доступ к файлам журналов с помощью разрешений O / S и файловой системы и либо зашифруете свои резервные копии, либо исключите конфиденциальные файлы журнала. Доступ к просмотру mongod журналы сервера требуют большего разрешения, чем просто вход через mongo shell, и любой, у кого есть разрешение на просмотр журналов сервера, предположительно, также может иметь доступ для копирования файлов данных.
Поскольку ваше развертывание выполняется на AWS, вы можете рассмотреть Шифрование Amazon EBS который зашифрует данные, находящиеся внутри тома, данные, перемещаемые между томом и экземпляром, и все моментальные снимки, созданные из тома.
Другой вариант, который следует рассмотреть, - это шифрование конфиденциальных полей в вашем приложении, чтобы они никогда не передавались, не регистрировались или не сохранялись в открытом виде.
Для получения дополнительных сведений о безопасности развертывания см. Контрольный список безопасности MongoDB.