Який рекомендований спосіб резервного копіювання великих наборів даних у MongoDB? Скажімо, у нас розмір даних порядку 10 ТБ - як би ви це створили?

Ми розглядаємо прихований, можливо затриманий, вузол набору реплік. Затримка захистить нас від випадкових падінь всієї бази даних. Це життєздатне рішення, і які інші варіанти ви рекомендуєте дослідити?

Спасибі!

З необхідністю резервного копіювання 10TB це стає трохи складніше.

Репліки не є заміною для правильних резервних копій

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

Рекомендації

Це сильно залежить від того, як виглядає ваша установка.

Знімки SAN

З 10 ТБ, я припускаю, що у вас є доданий SAN. Найпростіший спосіб резервного копіювання MongoDB у цих середовищах - це переконатися, що у вас активовано ведення журналу як у файловій системі, так і в MongoDB і просто зробити знімок обсягу SAN одного з другорядних видань, можливо, прихованого, щоб переконатися, що ваші операції не виконуються не перебиваюсь. Зазвичай це займає декілька секунд, але будь ласка, переконайтесь, що вікно оплогів реплікації достатньо. В іншому випадку може знадобитися повторна синхронізація вторинного.

Не використовуйте mongodump

Я не погоджуюся з RolandoMySQLDBA щодо використання mongodump. Перш за все, це накладає блокування на сервер. Хоча вони знімаються відносно швидко, кількість замків може зменшуватись і заважати вашим операціям, якщо тільки не працювати на прихованому вузлі або коли немає переваги читання, що впливає на вторинні. Плюс це не зовсім швидко. Я б очікував, що він працюватиме годинами, принаймні, швидше за все, це займе більше часу, ніж ваше резервне вікно. Бічна примітка: Завжди запускайте mongodump з --oplogопцією. Також пам’ятайте, що mongodump не резервне копіювання індексів, а операції зі створення індексів. Ці показники повинні бути відтворені під час відновлення, що може значно збільшити час, необхідний для цього. З мого досвіду, якщо вам доведеться відновити базу даних, ви хочете мати її якомога швидше. Ще один момент, чому mongodump не підходить для резервного копіювання 10 ТБ.

Примітки до знімків LVM

Ви можете зробити знімок LVM на запущеному екземплярі mongod за умови, що у вас ввімкнено ведення журналу в mongod (і, з мого досвіду, це не завадить, якщо його також було включено на рівні FS). Однак знімки LVM мають деякі наслідки. По-перше, вам очевидно потрібно мати достатньо місця на диску, який може прийняти зміни під час операцій із резервного копіювання. Дозвольте мені уточнити це.

Припустимо, у вас є почасова зміна 500 Гб. І що ви хочете, щоб ваша резервна копія була зімкнена, перш ніж вона буде завантажена в якийсь сховище Навіть при використанні паралельного bzip2 для стиснення 10 ТБ знадобиться кілька годин, щоб закінчити, просто тому, що той факт, що ви, швидше за все, масову пропускну здатність, став вашим обмежуючим фактором. Припустимо, що для стиснення даних до 2 ТБ знадобиться 2 години. Таким чином, на сьогоднішній день нам знадобиться близько 2 ТБ + 2 * 500 ГБ вільного місця на диску, а для знімка LVM потрібно 1 ТБ. Це створить необхідність принаймні забезпечити вашу файлову систему хоча б30%. Якщо ви хочете мати належний запас міцності, це може легко збільшитися до 60-70% (20% для коефіцієнта використання 0,8 для оригінальної файлової системи, такий самий для розміру знімка плюс місця, необхідного для самої резервної копії. ). У більшості виробничих середовищ це буде неприйнятно, оскільки надмірне забезпечення буде статичним (Ви б не хотіли, щоб резервний сценарій динамічно маніпулював вашим LVM, чи не так?).

Резервне копіювання MMS

Незважаючи на те, що резервне копіювання MMS має деякі дивовижні функції (безперервне резервне копіювання, легке відновлення часу), воно має серйозний недолік: його ціна на великі розгортання легко може бути тисячами. З передбачуваною годинною швидкістю зміни 500 ГБ на ці 10 ТБ, це було б середньою шестизначною сумою для хмарних резервних копій . Щомісяця

Я можу запропонувати йому взяти корпоративну підписку на ваші сервери на те, щоб вони мали право мати попередній MMS-екземпляр, включаючи резервне копіювання.

Підсумок

Ось варіанти, які я б прийняв у порядку зменшення.

1. Знімки SAN: прості у виконанні, порівняно дешеві
2. Підписка на підприємство: Найкращі функції. Встановіть його, налаштуйте, забудьте, він є там, коли вам це потрібно
3. Знімки LVM: прості у здійсненні, але витрати на необхідне надбавлення можуть з часом підсумовуватися.

Є два варіанти

ФІЗИЧНА РЕКЛАМА

Якщо ви не проти простоїв, це найпростіше зробити

service mongod stop

Зробіть знімок LVM або грубу силу cpпапки даних Mongo на інший диск

service mongod start

Звичайно, ви не хочете простоїв, якщо 10 ТБ даних знаходиться на автономній машині.

ЗАСТОСУВАННЯ РЕПЛІКА

Якщо у вас є набір реплік з трьома вузлами, використовуйте один із вузлів для резервного копіювання

{
        "_id" : "myreplica",
        "version" : 1,
        "members" : [
                {
                        "_id" : 1,
                        "host" : "10.20.30.40:27017",
                        "priority" : 2
                },
                {
                        "_id" : 2,
                        "host" : "10.20.30.41:27017"
                },
                {
                        "_id" : 3,
                        "host" : "10.20.30.42:27017",
                        "priority" : 0,
                        "slaveDelay" : 3600
                }
        ]
}

Використовуйте вузол з "_id' : 3усіма своїми фізичними резервними копіями. Тому простоїв немає. Щоб отримати знімок у півночі, ви можете запустити резервне копіювання о 1:00 ранку, оскільки прихований вузол відстає на 1 годину.

Звичайно, недоліком є ​​наявність ще двох серверів з 10 ТБ на кожному та небезпека розумної сисдаміна.

МОНГОДУМП

Ви можете використовувати mongodump проти автономної машини, але ви повинні очікувати зниження продуктивності, оскільки mongodump є клієнтською програмою, що використовує з'єднання, як і будь-яке інше з'єднання.

Якщо ви хочете створити резервну копію за часом, вам слід скористатися

mongodump --oplog 

Логічна резервна копія BSON буде меншою (особливо gzipped або bzipped), ніж фізична резервна копія.

Використання mongodump --oplogнайкраще проводити проти прихованого вузла. Таким чином, у Майстра немає хіта на продуктивність.

ВІДХОДЖЕННЯ

Я відносно новий в MongoDB (випадковий / випадковий MongoDBA). Я сподіваюся, що моя відповідь допомагає.