Покрокові резервні копії Mongodb


26

Мені було дано завдання встановити додаткові резервні копії для реплікації MongoDB, як початкову точку, звичайно, я погуглив її і нічого не міг знайти в документах MongoDB, проте я знайшов це питання в Stack Overflow, що спонукало розробити власне рішення як не знайшов Тайру дуже активною.

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

Зараз у мене є робоче рішення зі скриптами bash, і це було досить просто, тому я питаю тут, чи є якийсь недолік у моїй логіці чи, можливо, щось, що мене вкусить у майбутньому.

Нижче, як я це реалізував:

Повна процедура резервного копіювання

  1. Блокування записується на другорядний член db.fsyncLock()
  2. Зробіть знімок
  3. Записати останню позицію з oplog

    db.oplog.rs.find().sort({$natural:-1}).limit(1).next().ts
  4. Unlock пише db.fsyncUnlock()

Поступова процедура резервного копіювання

  1. Блокування записується на другорядний член
  2. Дамп-опил із записаного положення oplog на повній (або останній додатковій) резервній копії:

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

  4. Unlock пише

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

  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 пізніше.

Питання в тому, чи є якась вада в логіці? Я трохи підозрілий, оскільки процедура є досить прямою, і я все одно не міг знайти її документально ніде.


2
Яку версію Монго ви використовуєте? Якщо ви використовуєте 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 можна використовувати, краще зробити резервні копії.


Як ви робите додаткові резервні копії знімка LVM? Спасибі!
TanisDLJ

Знімки LVM за природою збільшуються. Знімок - це моменти часу, зафіксовані лише зміни.
JJussi

Тільки знімок, зроблений так, є поступовим. Але якщо ви архівуєте знімок, то це повна резервна копія. Ви не можете архівувати різні додаткові резервні копії, наприклад, копіювання. І ви не можете просто почати створювати знімки кожні 30 хв для покрокових резервних копій, оскільки це призведе до поганої продуктивності.
TanisDLJ
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.