Лучший способ сделать горячую резервную копию экземпляра базы данных MongoDB(TokuMX)

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

  1. Как лучше всего сделать горячее резервное копирование запущенного сервера TokuMX (кроме TokuMX Hot Backup в версии enterprise).

  2. Вопрос о предлагаемом резервном подходе MongoDB: 

    [backup-host]# mongodump --host mongodb-host --port 27017 --db mongodevdb --username mongouser --password mongopwd
    • является ли эта команда предпочтительным способом сделать горячий резервные копии?
    • какой порт следует использовать при выполнении этой команды?
    • Хорошо ли использовать эту команду cron и запускать ее каждый день?
      • Есть ли какие-либо подводные камни в этой команде?
1 2
database-backups

1 ответ:

Отказ от ответственности: я работаю в Tokutek, я инженер, работающий на TokuMX.

Нет" лучшего " способа сделать резервную копию TokuMX, каждое приложение отличается, и лучше всего понять все варианты и принять собственное решение.

Параметры резервного копирования для TokuMX следующие:

  1. горячее резервное копирование предприятия.
  2. моментальный снимок на уровне файловой системы (LVM, EBS, xfs_freeze) для копирования всего, что находится в dbpath и logDir.
  3. использование mongodump.
Обратите внимание, что fsyncLock делает не работу, так как фоновые потоки все равно будут писать в файловую систему, даже если клиентские потоки ничего не делают. Использование fsyncLock только может дать вам поврежденную резервную копию. Моментальные снимки файловой системы и горячее резервное копирование enterprise имеют то преимущество, что вы копируете сериализованные сжатые данные, поэтому вы избегаете затрат на запрос всех коллекций и передачу несжатых данных BSON по проводу. Вдобавок, эти опции не уничтожат информацию в кэшируемом файле о том, какие данные наиболее важны, в то время как mongodump вызовет все, что будет выгружено, возможно, исключив данные, которые полезны для вашего приложения.

Корпоративное горячее резервное копирование имеет дополнительные преимущества перед моментальными снимками на уровне файловой системы, которые заключаются в том, что оно менее затратно (вам не нужно резервировать дополнительное пространство, как для моментального снимка), его можно регулировать для удовлетворения квот ввода-вывода, а результирующее состояние резервной копии - это состояние на уровне время завершения резервного копирования, а не его начала. Таким образом, если копирование данных для резервного копирования занимает 12 часов, резервная копия с привязкой на уровне файловой системы будет на 12 часов отставать от аналогичной резервной копии, выполненной с помощью плагина hot backup.

Для простого использования mongodump может быть лучшим вариантом, если вы не обеспокоены производительностью, недействительностью кэша, пропускной способностью сети или недавностью. Это также единственный вариант, который поддерживает резервное копирование одной базы данных или коллекции.

Для mongodump, его использование такое же, как и для MongoDB. Вы должны использовать хост и порт, на котором работает ваш сервер, по умолчанию 27017. Если это значение по умолчанию, вам не нужно указывать какой-либо параметр --port.

Вы определенно можете запускать его каждый день с cron, я предлагаю что-то вроде этого: 

SHELL=/bin/bash
0 0 * * * /usr/bin/mongodump --host <host> -o "/var/lib/backup/tokumx-backup-$(date +%Y%m%d)"
Основные подводные камни mongodump заключаются как раз в том, что он дороже и уничтожает информацию в кэш-таблице, которая говорит, какие данные важны. Он также не получит идеально последовательный моментальный снимок в нескольких коллекциях, таких как горячее резервное копирование и резервные копии моментальных снимков на уровне файловой системы. Mongodump может содержать эффекты некоторых записей в одной коллекции и не содержать эффекты предыдущих записей в другой коллекции.

Вы также захотите определить схему для устаревших резервных копий, я полагаю.

2