Я новичок в MongoDB. У меня есть набор реплик с 3 участниками (1 основной и 2 второстепенных) на CentOS 6 и Mongo 2.6.8.
Одна из вторичных систем вышла из строя из-за высокого потребления памяти, и мне не удалось перезапустить ее должным образом (из-за некоторого повреждения данных), поэтому я удалил все содержимое datadir, чтобы выполнить полную повторную синхронизацию.
Через 4 часа вторичный сервер был синхронизирован и вернулся к набору реплик. Однако он сгенерировал 25 «локальных» файлов (local.0 ... local.24), в то время как раньше было только 2 (как и другие члены), занимая на диске более 60 ГБ только из-за этих файлов.
Более того, изменился размер oplog (раньше он был 990 МБ, а теперь 47 ГБ):
rs: SECONDARY> rs.printReplicationInfo (); настроенный размер журнала операций: 47774.441162109375 МБ длина журнала от начала до конца: 579127 секунд (160,87 часов) время первого события журнала операций: Вт 23 июня 2015 г. 16:53:13 GMT + 0100 (IST) время журнала последнего события: Вт 30 июня 2015 г. 09:45: 20 GMT + 0100 (IST) сейчас: Вт 30 июн 2015 09:45:20 GMT + 0100 (IST)
С тех пор, как это произошло, сервер потреблял около 130 ГБ виртуальной памяти и показывал очень низкую производительность.
Мне пришлось выполнить полную синхронизацию и на другом вторичном сервере (из-за аналогичных проблем), и ничего не изменилось (было создано 2 «локальных» файла, а размер журнала операций по-прежнему составлял 990 МБ).
Мне любопытно:
В чем причина такого поведения "локальной" базы данных?
Почему такое поведение влияет на производительность, если «локальная» база данных не реплицируется?
Есть ли способ вернуть этот вторичный узел таким, каким он был (только 2 локальных файла и меньший oplog)? Я знаю, что можно изменить размер журнала операций, но мне интересно, могу ли я просто остановить службу, удалить «локальные» файлы, чтобы они снова синхронизировались.
Любые другие предложения более чем приветствуются (: