Copias de seguridad de CouchDB y clonación de la base de datos

Otra cosa a tener en cuenta es que puede copiar archivos desde una base de datos en vivo. Dado que es posible que tenga una base de datos posiblemente grande, puede copiarla OOB de su máquina de prueba/producción a otra máquina.

Dependiendo de la carga de escritura de las máquinas, puede ser aconsejable activar una replicación después de la copia para recopilar las escrituras que estaban en progreso cuando se copió el archivo. Pero la replicación de unos pocos registros aún sería más rápida que la replicación de todo el base.

Para referencia ver: http://wiki.apache.org/couchdb/FilesystemBackups

CouchDB también funciona muy bien con instantáneas de sistemas de archivos ofrecidas por sistemas de archivos modernos como ZFS. Dado que el archivo de base de datos siempre está en un estado consistente, puede tomar la instantánea del archivo en cualquier momento sin debilitar las garantías de integridad proporcionadas por CouchDB.

Esto resulta en casi ninguna sobrecarga de E/S. En caso de que, por ejemplo, haya borrado accidentalmente un documento de la base de datos, puede mover la instantánea a otra máquina y extraer los datos que faltan allí. Usted podría incluso ser capaz de replicar de nuevo a la base de datos de producción, pero nunca he intentado eso.

Pero siempre asegúrese de usar exactamente las mismas revisiones de couchdb cuando se mueve alrededor de archivos de base de datos. El formato en disco sigue evolucionando de manera incompatible.

Me gustaría secundar la sugerencia de Paul: Solo cp sus archivos de base de datos desde debajo del servidor en vivo si puede tomar el golpe de carga de E/S. Si ejecuta una copia replicada de todos modos, también puede copiarla de forma segura, sin afectar el rendimiento de su maestro.

La replicación de CouchDB es horrible. Generalmente hago tar que es mucho mejor.

1. Detener el servicio CouchDB en el host de origen
2. tar.gz los archivos de datos.
3. En mis servidores Ubuntu esto es típicamente en /var/lib/couchdb (a veces en un subdirectorio basado en la versión Couch). Si no está seguro de dónde están estos archivos, puede encontrar la ruta en sus archivos de configuración de CouchDB, o a menudo haciendo un ps-A w para ver el comando completo que inició CouchDB. Asegúrese de que obtenga los subdirectorios que comienzan con . cuando archive los archivos.
4. Reinicie el servicio couchdb en el host de origen.
5. scp el tie.archivo gz al host de destino y descomprimirlos en una ubicación temporal allí.
6. chown los archivos al usuario y grupo que posee los archivos que ya están en el directorio de la base de datos en el destino. Esto es probablemente couchdb: couchdb. Esto es importante, ya que estropear los permisos de archivo es la única forma en que he logrado estropear esto proceso hasta ahora.
7. Detener CouchDB en el host de destino.
8. cp los archivos en el directorio de destino. De nuevo en mis anfitriones esto ha sido / var/lib / couchdb.
9. Revise los permisos de archivo en su nuevo hogar.
10. Reinicie CouchDB en el host de destino.