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

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

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

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

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

Ответы

Ответ 1

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

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

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

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

Ответ 2

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

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

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

Ответ 3

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

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

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

Ответ 4

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

Ответ 5

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

  • Остановить службу CouchDB на исходном хосте
  • tar.gz файлы данных.
  • На моих серверах Ubuntu это обычно находится в /var/lib/couchdb (иногда в подкаталоге на основе версии Couch). Если вы уверены, где эти файлы, вы можете найти путь в своих конфигурационных файлах CouchDb или часто, выполняя ps -A w, чтобы увидеть полную команду, которая запустила CouchDb. Убедитесь, что вы запустили подкаталоги, начинающиеся с . при архивации файлов.
  • Перезапустите службу couchdb на исходном узле.
  • scp файл tar.gz на целевой хост и распакуйте их во временном месте.
  • chown файлы для пользователя и группы, которым принадлежат файлы, уже находящиеся в каталоге базы данных в пункте назначения. Вероятно, это couchdb: couchdb. Это важно, так как испорченность прав доступа к файлам - единственный способ, которым Ive удалось испортить этот процесс.
  • Остановить CouchDB на целевом узле.
  • cp файлы в каталог назначения. Снова на моих хостах это было /var/lib/couchdb.
  • Дважды проверьте права доступа к файлам в их новом доме.
  • Перезапустите CouchDB на целевом узле.