MongoDb Горячее резервное копирование - скопируйте данные / репликацию базы данных VS с помощью fsyncLock - PullRequest
Новая
       16

MongoDb Горячее резервное копирование - скопируйте данные / репликацию базы данных VS с помощью fsyncLock

13 голосов
/ 29 февраля 2012

Я читал о различных настройках MongoDB для резервного копирования без простоев. Какая стратегия лучше или их можно даже сравнить?

  1. Включите ведение журнала и просто скопируйте каталог /data/db - мне неясно, достаточно ли этого - на домашней странице MongoDB указано, что вам нужно «сделать снимок», и он работает на SAN и LVM как примеры.

    Вопросы:

    Что означает снимок в этом контексте, будет ли команда копирования считаться снимком? Сохраняется ли копирование каталога данных MongoDB (2.0+) на сервере Windows с NTFS? Как вы гарантируете, что это безопасно сделать на вашей собственной файловой системе и настройке?

  2. Создание набора реплик с 2 серверами и арбитром. Затем используйте 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 Ответ

12 голосов
/ 29 февраля 2012

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

" Снимок " в этом контексте относится к функциям снимка, предлагаемым некоторыми менеджерами томов, файловыми системами и гипервизорами. По сути, это функция «копировать при записи» для блочных устройств: вместо перезаписи данных, когда этого требует ОС, она будет записывать новые данные в другое место и сохранять как старую, так и новую версию для чтения. Снимок обычно не занимает много времени, но в некоторых системах не рекомендуется хранить много снимков одних и тех же файлов, поскольку это может значительно замедлить запись в будущем.

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

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

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

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

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

На ваши вопросы:

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

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

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

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

...