mongodump a db на archlinux

Похоже, это ошибка в инструменте mongodump. Подробнее см. в этом JIRA билете. Вы должны иметь возможность использовать mongodump, если вы явно указываете IP-адрес:

mongo --host 127.0.0.1 --port 27017

«Правильно» — очень субъективный термин в данном контексте. Чтобы произвести впечатление:

mongodump и mongorestore не очень быстрые. В сегментированных средах они могут занимать днис (обратите внимание на множественное число!) для баз данных разумного размера. Что, в свою очередь, означает, что в худшем случае вы можете потерять данные за несколько дней. Кроме того, во время резервного копирования данные могут немного измениться, поэтому состояние вашей резервной копии может быть несогласованным. В этом аспекте лучше думать о mongodump как о «mongodumb». Ваше приложение должно быть в состоянии изящно справляться с отсутствием согласованности, что может быть довольно сложной задачей для разработки. Кроме того, длительное время восстановления стоит денег и (иногда даже важнее) репутации.

Я лично использую mongodump только в двух сценариях: для резервного копирования метаданных шардированных кластеров (размер которых составляет всего пару МБ) и для (относительно) дешевых данных, которые легко повторно получить другими способами.

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

1. Облачное резервное копирование MongoDB Inc,
2. Операционный менеджер MongoDB
3. Снимки файловой системы

Облачное резервное копирование

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

Диспетчер операций MongoDB

Будучи локальной версией облачного резервного копирования (у него есть и другие функции, выходящие за рамки этого ответа), он предлагает те же преимущества. Он больше подходит для средних и больших баз данных верхнего масштаба или для баз данных с непропорционально высокой волатильностью (на что указывает высокое значение «OplogGb/h» по сравнению с размером данных).

Снимки файловой системы

Ну как-то дёшево. Просто сделайте снимок, смонтируйте его, скопируйте в резервную копию, размонтируйте и уничтожьте снимок, при необходимости сожмите скопированные данные, и все готово. Однако есть некоторые предостережения.

Синхронизация

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

Обратите внимание, что для простого набора реплик синхронизация не требуется, и резервное копирование работает безупречно.

Избыток ресурсов

Моментальные снимки файловой системы работают с так называемым «копированием при записи» (CoW). Немного упрощенно: когда вы делаете снимок и изменяете файл, вместо этого он копируется, и изменения применяются к вновь скопированному файлу. Однако снимок указывает на старый файл. Очевидно, что для того, чтобы иметь возможность сделать снимок в соответствии с CoW, вам нужно дополнительное место на диске, чтобы MongoDB могла работать, пока вы работаете со снимком. Давайте предположим наихудший сценарий, в котором все данные изменены — вам нужно будет выделить свой раздел для MongoDB как минимум на 100% от вашего размера данных или, говоря другими словами, ваше критическое использование диска будет 50 % минус некоторое пороговое значение времени, необходимого для масштабирования. Конечно, это немного преувеличено, но картину вы поняли.

Вывод

ИМХО, правильные бэкапы надо делать так:

• mongorestore для дешевых данных и небольшой заботы о согласованности
• Моментальные снимки файловой системы для наборов реплик
• Облачное резервное копирование для сегментированных баз данных малого и среднего размера с низкой или средней волатильностью
• Резервные копии Ops Manager для больших баз данных или баз данных малого и среднего размера с непропорционально высокой волатильностью.

Как сказано: «правильно» — очень субъективный термин, когда речь идет о резервных копиях. ;)