Це дійсна стратегія резервного копіювання для MongoDB?

У мене є єдиний виділений сервер із базою даних MongoDB близько 10 Гб. Мені потрібно робити щоденні резервні копії, але я не можу простоювати з базою даних. Чи можливо використовувати репліку, встановлену на одному диску (з двома екземплярами mongod, що працює на різних портах), а також просто взяти вторинний автономний режим і створити резервну копію файлів даних у сторонній сховище, наприклад S3 (журнал увімкнено)? Або використання майстра / підлеглого краще, ніж набір реплік?

Чи це життєздатно, і якщо так, то які потенційні проблеми я міг би мати? Якщо ні, то як я концептуалізую це для роботи?

ReplicaSet буде працювати в цьому сценарії. Однак я не можу сказати, чи є два екземпляри MongoDB на одному сервері - це гарна ідея - це залежить від апаратного забезпечення / програмного забезпечення сервера та завантаження.

Для того, щоб переконатися , що ваш backupвузол MongoDB не стане майстром, встановіть його priorityпараметр в 0, наприклад ,

rs.add({_id: 1, host: "localhost:<port>", priority: 0})

ПРИМІТКА : якщо у вас не може бути простоїв, ВІДПОВІДИТЬ принаймні 2 первинних MongoDB-вузла в ReplicaSet, див. Статтю

Однією з стратегій, яку слід врахувати, є використання параметра «прихований» на вузлі резервного копіювання реплікату. З блогу MongoDB:

Приховані сервери не відображатимуться в результатах isMaster (). Це також означає, що вони не будуть використовуватися, якщо драйвер автоматично поширює зчитування на раби. Прихований сервер повинен мати пріоритет 0 (прихований основний не може бути). Щоб додати прихований член, запустіть:

rs.add ({"_ id": num, "host": ім'я хоста, "пріоритет": 0, "приховано": true})

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

Єдиною потенційною проблемою, яку я бачу, є те, що за певних обставин ваш вторинний може бути переведений на ваш основний, і вам потрібно буде: а) потрібно взяти резервну копію з нового вторинного, або b) зробити ваш скрипт резервного копіювання досить розумним, щоб повідомити про цей примірник MongoDB відступив.

Хороша новина полягає в тому, що це має бути досить тривіально

1. Запитайте джерело резервного копіювання, щоб дізнатися, який примірник є первинним, а який вторинним ( db.isMaster())
2. Переконайте копію резервного копіювання відступити за допомогою команд rs.freeze()та rs.stepDown()команд або знову підключитися до вторинного