Резервное копирование CouchDB и клонирование базы данных

Question

Мы рассматриваем CouchdDB в качестве приложения в стиле CMS.Каковы некоторые общие шаблоны, лучшие практики и рекомендации по рабочему процессу резервного копирования нашей производственной базы данных?

Меня особенно интересует процесс клонирования базы данных для использования в разработке и тестировании.

Достаточно ли просто скопировать файлы на диск из работающего экземпляра?Можете ли вы клонировать данные базы данных между двумя работающими экземплярами?

Будем очень признательны за советы и описание техник, которые вы используете.

Answer 1

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

http://wiki.apache.org/couchdb/FrequlyAskedQuestions#how_replication

Вы буквально отправляете POST-запрос на свой экземпляр CouchDB, сообщая ему, куда реплицировать, и это работает (тм).

РЕДАКТИРОВАТЬ:Вы можете просто извлечь файлы из работающей базы данных, если можете принять попадание ввода-вывода.

Answer 2

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

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

Для справки см.: http://wiki.apache.org/couchdb/FilesystemBackups

Answer 3

CouchDB также очень хорошо работает со снимками файловых систем, предлагаемыми современными файловыми системами, такими как ZFS.Поскольку файл базы данных всегда находится в согласованном состоянии, вы можете сделать снимок файла в любое время, не ослабляя гарантии целостности, предоставляемые CouchDB.

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

Но всегда убедитесь, что вы используете одни и те же версии Couchdb при перемещении файлов базы данных.Дисковый формат все еще развивается несовместимым образом.

Answer 4

Я хотел бы поддержать предложение Павла:Только cp файлы вашей базы данных из-под работающего сервера, если вы можете выдержать нагрузку ввода-вывода.Если вы все равно запустите реплицированную копию, вы также можете безопасно скопировать ее, не влияя на производительность вашего мастера.

Answer 5

Репликация CouchDB ужасна.Я обычно делаю смола что намного лучше.

1. Остановите службу CouchDB на исходном хосте.
2. tar.gz — файлы данных.
3. На моих серверах Ubuntu это обычно находится в /var/lib/couchdb (иногда в подкаталоге, основанном на версии Couch).Если вы не уверены, где находятся эти файлы, вы можете найти путь в файлах конфигурации CouchDb или часто введя команду ps -A w, чтобы просмотреть полную команду, запустившую CouchDb.Убедитесь, что у вас есть подкаталоги, начинающиеся с . когда вы архивируете файлы.
4. Перезапустите службу Couchdb на исходном хосте.
5. scp файл tar.gz на целевой хост и распакуйте его во временное место.
6. chown файлы пользователю и группе, которой принадлежат файлы, уже находящиеся в каталоге базы данных в месте назначения.Скорее всего, это Couchdb:couchdb.Это важно, поскольку испортить права доступа к файлам — единственный способ испортить этот процесс.
7. Остановите CouchDB на целевом хосте.
8. cp файлы в каталог назначения.Опять же, на моих хостах это было /var/lib/couchdb.
9. Дважды проверьте права доступа к файлам в их новом доме.
10. Перезапустите CouchDB на целевом хосте.