Mongodb инкрементные резервные копии

26

Мне было дано задание настроить инкрементные резервные копии для репликационного набора MongoDB, поскольку в качестве начальной точки я, конечно, гуглил его и ничего не мог найти в документах MongoDB, однако я нашел этот вопрос о переполнении стека, что побудило разработать собственное решение так как не нашел Тайру очень активной.

Я прочитал oplogи понял, что было очень легко разработать что-то для воспроизведения журнала, но оказалось, что мне это не нужно, как это mongorestoreделает для меня.

Теперь у меня есть рабочее решение со скриптами bash, и это было довольно легко, поэтому я спрашиваю здесь, есть ли какая-то ошибка в моей логике, или, может быть, что-то, что укусит меня в будущем.

Ниже, как я это реализовал:

Полная процедура резервного копирования

  1. блокировка записи на вторичном элементе db.fsyncLock()
  2. Моментальный снимок
  3. Запишите последнюю позицию из оплога

    db.oplog.rs.find().sort({$natural:-1}).limit(1).next().ts
  4. Разблокировать пишет db.fsyncUnlock()

Процедура инкрементного резервного копирования

  1. блокировка записи на вторичном элементе
  2. Извлечь оплог из записанной позиции оплога при полном (или последнем инкрементном) резервном копировании:

    mongodump --host <secondary> -d local -c oplog.rs -o /mnt/mongo-test_backup/1 
        --query '{ "ts" : { $gt :  Timestamp(1437725201, 50) } }'
    
  3. Запишите последнюю позицию оплога (так же, как и для полных резервных копий)

  4. Разблокировать пишет

Процедура полного резервного копирования

  1. остановить все случаи mongod
  2. скопируйте снимок в каталог данных блока, который будет основным, но убедитесь, что исключили все, local*и mongod.lock этот метод восстановления называется перенастройкой путем разбивания зеркала
  3. Начальный начальный
  4. перенастроить репликацию
  5. Запустите вторичные серверы без каких-либо данных, дайте им выполнить первоначальную синхронизацию. Или скопируйте данные из нового первичного с новой localбазой данных

Восстановить инкрементное резервное копирование

Когда мы создали инкрементное резервное копирование, оно хранилось так:

/mnt/mongo-test_backup/1/local/oplog.rs.bson
/mnt/mongo-test_backup/1/local/oplog.rs.metadata.json

Мы добавлены, oplog.rs.bsonно нам придется переименовать его, так что вот шаги:

  1. изменить каталог на резервную копию: cd /mnt/mongo-test_backup/1/local
  2. удалить файл json rm *.json
  3. переименовать файл bson mv oplog.rs.bson oplog.bson
  4. восстановить это:

    mongorestore -h <primary> --port <port> --oplogReplay /mnt/mongo-test_backup/1/local

У меня все это написано в скрипте, я могу зафиксировать это на GitHub позже.

Вопрос в том, есть ли какой-либо недостаток в логике? Я немного подозрительна, так как процедура довольно проста, и все же я нигде не смог найти ее документированной.

Tiago
источник
2
Какую версию Mongo вы используете? Если вы используете wiredtiger, то первый элемент, на который вы ссылаетесь с помощью db.fsyncLock (), является проблемой. MongoDB Inc утверждает, что «с WiredTiger команда fsync с опцией блокировки не может гарантировать, что файлы данных не изменятся. В результате не используйте эти методы для обеспечения согласованности в целях создания резервных копий». ссылка
SDillon
1
@SDillon использует 3.0.4, но не использует WiredTiger, по крайней мере пока. Если мы решим использовать его, вместо того, чтобы блокировать запись, нам придется остановить mongod все вместе. Это справедливо, спасибо
Тиаго
Я нашел следующий инструмент для инкрементного резервного копирования github.com/EqualExperts/Tayra надеюсь, что это поможет
Ахмад Абухасна
1
«Изменено в версии 3.2: команда fsync с опцией блокировки может гарантировать, что файлы данных не изменятся для экземпляров MongoDB, использующих механизмы хранения MMAPv1 или WiredTiger, что обеспечивает согласованность в целях создания резервных копий».
безопасность
Нормальным (и абсолютно простым) способом создания инкрементных резервных копий является использование LVM и моментальных снимков. docs.mongodb.com/manual/tutorial/…
JJussi

Ответы:

3

Ответить на ваш вопрос. Нет! В вашей логике нет сбоев, и она должна работать без проблем. Однако, если можно использовать снимки LVM, это лучший способ сделать резервные копии.

JJussi
источник
Как вы делаете инкрементное резервное копирование снимка LVM? Благодарность!
TanisDLJ
Снимки LVM являются инкрементными по своей природе. Снимок - это моменты времени и записаны только изменения.
JJussi
Просто снимок сделан да, это постепенно. Но если вы архивируете снимок, то это полная резервная копия. Вы не можете архивировать различные инкрементные резервные копии, как, например, дублирование. И вы не можете просто начать создавать снимки каждые 30 минут для инкрементных резервных копий, так как это очень сильно ухудшит производительность.
TanisDLJ