Я читал о различных настройках MongoDB для резервного копирования без простоя. Какая стратегия лучше или их можно сравнивать?
-
Включить ведение журнала и просто скопировать каталог
/data/db
- мне непонятно, если этого достаточно - на домашней странице MongoDB говорится, что вам нужно "сделать снимок", и он работает на SAN и LVM как примеры.Вопросы:
Что означает значение моментального снимка в этом контексте, будет ли команда копирования подсчитываться как моментальный снимок? Сохраняется ли копирование журнала данных MongoDB (2.0+) на сервере Windows с NTFS? Как вы гарантируете, что это безопасно для вашей собственной файловой системы и настройки?
-
Установите набор реплик с двумя серверами и арбитром. Затем используйте
rs.status()
иfsyncLock
/unlock, чтобы обеспечить чтение данных только на вторичном сервере при выполнении резервного копирования.> db.fsyncLock function () { return db.adminCommand({fsync:1, lock:true}); } > db.fsyncUnlock function () { return db.getSiblingDB("admin").$cmd.sys.unlock.findOne(); }
Вопросы:
Если вы используете блокировки в наборе реплик, кажется, что записи и чтения могут быть заблокированы для всего набора реплик и эта ошибка не была исправлена?
Что делать, если вторичное голосование считается основным, пока выполняется резервное копирование? Остановится ли процесс резервного копирования или будет ли набор реплик перестать отвечать на запросы на запись до тех пор, пока он не будет разблокирован?
Вопросы:
Теперь я хотел бы простое решение и просто скопировать каталог
data
/db
с файлами журнала и подождать с набором реплик. MongoDB работает на 64-битном сервере Windows (RackSpace Cloud).