Безопасно ли удалять oplog local.* файлы из снимка MongoDB? Есть ли fsyncLock() фиксировать записи журнала операций в файлах БД?
В настоящее время я занимаюсь fsyncLock() + LVM-снимок данных Mongo. Затем я монтирую снимок и удаляю oplog local.* файлы перед архивированием файлов на S3 или FTP (с Duplicity). Я делаю это, чтобы уменьшить размер архивов для переноса на S3.
Когда я восстанавливаю узел в пустом наборе реплик, файлы oplog воссоздаются, а другие узлы полностью повторно синхронизируются с этим новым основным. Но я не уверен, могут ли быть отсутствующие данные при восстановлении из-за того, что они находятся в ранее удаленном журнале операций и не записаны в файлах БД.
Использование функции моментального снимка для резервного копирования репликации mongo не является хорошей идеей, пока вы ее запускаете. Прежде всего вам необходимо получить снимок «первичной» в вашем наборе реплик. но проблема в том, что ваши клиенты могут подключиться к неправильной политике защиты от записи. например, не просить об этом или нет для большинства, которое оставляет незафиксированные данные в журнале операций основного пользователя. даже если вы храните журнал операций или все файлы в локальной базе данных, у вас могут возникнуть проблемы при восстановлении (получил это однажды, мой основной искал откат без причины).
Мое предложение (я полагаю, вы не можете остановить mongod) использует mongodump, да, это звучит глупо, когда у вас есть снимок. но реальный смысл использования резервных копий заключается в их восстановлении.
если вы не можете использовать mongodump или не хотите. Пытаться MMS функция облачного резервного копирования. который может легко восстановить весь набор реплик.
Редактировать: Другой вариант - запуск отложенного члена реплики. вот документация. который покрывает большую часть потребностей в резервном копировании. просто определите время задержки. таким образом вы не съедите io вашего сервера запущенными инструментами резервного копирования / архивирования.