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

Question

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

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

Answer 3

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

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

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

Answer 4

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

Answer 5

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

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 на хосте назначения.