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

Question

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

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

2. Вопрос относительно предложенного подхода резервного копирования MongoDB:

   [backup-host]# mongodump --host mongodb-host --port 27017 --db mongodevdb --username mongouser --password mongopwd
   

   • Эта команда предпочитает способ делать горячие резервные копии?
   • Какой порт я должен использовать при выполнении этой команды?
   • Это хороший подход, чтобы использовать эту команду cron и запускать ее каждый день?
   • Есть ли подводные камни в этой команде?

Answer 1

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

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

Варианты резервного копирования для TokuMX:

1. Корпоративное горячее резервирование.
2. Снимок уровня файловой системы (LVM, EBS, xfs_freeze) для копирования всего в dbpath и logDir.
3. Использование mongodump.

Обратите внимание, что fsyncLock не работает, поскольку фоновые потоки по-прежнему будут записывать в файловую систему, даже если клиентские потоки ничего не делают. Использование только fsyncLock может дать вам поврежденную резервную копию.

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

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

Для простого использования 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 может содержать эффекты некоторых записей в одной коллекции и не содержать эффектов более ранних записей в другой коллекции.

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