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

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

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

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

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

34
administration backup couchdb database

5 ответов

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

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

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

EDIT: вы можете просто вырезать файлы из-под работающей базы данных, пока вы можете примите удар I/O.

31

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

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

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

37

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

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

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

7

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

6

репликация CouchDB ужасна. Я вообще делаю деготь что гораздо лучше.

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