MongoDb Hot backup - копировать данные /db VS replicaset с помощью fsyncLock

Я читал о различных настройках 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).

Ответы

Ответ 1

Лучше всего сделать fsync + lock на вторичном, затем снимок тома на уровне диска или уровня громкости (например, используя lvm2, hyper-v, btrfs), разблокировать базу данных, а затем скопировать файлы с моментальными снимками. Это минимизирует время простоя вторичного и легко восстанавливается.

" Snapshotting" в этом контексте относится к моментальным снимкам, которые предлагаются некоторыми менеджерами томов, файловыми системами и гипервизорами. По сути, это функция "copy-on-write" для блочных устройств: вместо того, чтобы перезаписывать данные, когда OS требует этого, она будет записывать новые данные в другом месте и сохранять как старую версию, так и новую версию. Snapshotting обычно занимает почти нет времени, но в некоторых системах неплохо хранить много снимков одних и тех же файлов, потому что это может значительно замедлить запись в будущем.

Почему я считаю, что это лучшая стратегия для полных резервных копий:

  • Использование mongodump не будет хранить данные индекса. Индексы будут восстановлены, но восстановление индексов для восстановления может занять несколько часов - последнее, что вам нужно, когда все кричат ​​на вас, - это операция, которая занимает несколько часов и может " t ускоряться.

  • Fsync + lock блокирует авторов и может блокировать читателей, поэтому лучше всего сделать это на (пассивном) вторичном, а не на основном.

  • Завершение вторичного заполнения заполнит затвор, поэтому вы должны сократить время блокировки как можно короче. Вместо копирования всех файлов данных (которые могут занимать часы) во время блокировки, просто выполнение моментального снимка должно занимать всего пару секунд. Следовательно, ограничения oplog не являются проблемой.

  • Все возвращается в нормальное состояние, пока фактическая копия работает, что дает вам душевное спокойствие. Единственная разница будет более высокой нагрузкой на вторичную часть во время резервного копирования, что не должно быть серьезной проблемой.

Решение ваших вопросов:

  • относительно блокировок в наборах реплик: Сократите время блокировки и используйте пассивную вторичную (которая не может быть выбрана мастером), поэтому очередь писателя не может остановиться.

  • "Что делать, если вторичное голосование включено как первичное, пока выполняется резервное копирование" не может произойти, если ваша система резервного копирования является пассивной.

Теперь я хотел бы простое решение и просто скопировать dir dir с файлами журнала и подождать с набором реплик. MongoDB работает на 64-битном сервере Windows (RackSpace Cloud).

Вы можете это сделать. Съемка с томом, вероятно, по-прежнему остается лучшим способом, предоставляя вам только секунды простоя. Если ваши данные малы, простой mongodump может быть еще проще, но убедитесь, что время восстановления приемлемо (зависит от ваших индексов).