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

Question

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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

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

Answer 3

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

Answer 4

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

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

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

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 на хост-хостеле.