2008-09-23 23 views
32

Estamos buscando en CouchdDB una aplicación CMS-ish. ¿Cuáles son algunos de los patrones comunes, mejores prácticas y consejos de flujo de trabajo que rodean el respaldo de nuestra base de datos de producción?Copias de seguridad de CouchDB y clonación de la base de datos

Estoy particularmente interesado en el proceso de clonación de la base de datos para su uso en desarrollo y pruebas.

¿Es suficiente simplemente copiar los archivos en el disco desde una instancia en ejecución en vivo? ¿Se pueden clonar los datos de la base de datos entre dos instancias en ejecución?

El asesoramiento y la descripción de las técnicas que utiliza serán muy apreciadas.

Respuesta

30

CouchDB es compatible con la replicación, por lo que simplemente realice la réplica en otra instancia de CouchDB y haga una copia de seguridad desde allí, evitando alterar el lugar donde escribe los cambios.

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

Usted, literalmente, envía una solicitud POST a la instancia CouchDB diciendo donde replicar a, y funciona (tm)

EDIT: Usted puede simplemente cp a cabo los archivos de debajo de la base de datos se ejecuta siempre que puedas aceptar el golpe de E/S.

37

Otra cosa a tener en cuenta es que puede copiar archivos desde una base de datos en vivo. Dado que puede tener una base de datos posiblemente grande, puede simplemente copiarla OOB desde 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 algunos registros aún sería más rápida que la replicación de toda la base de datos.

Para referencia, véase: http://wiki.apache.org/couchdb/FilesystemBackups

+1

"puede copiar archivos desde una base de datos en vivo" - Este es un excelente consejo, estaba buscando duplicar una base de datos y encontré que puedo duplicar y cambiar el nombre de un archivo .couch en Finder para lograrlo. – DigitalDesignDj

6

me gustaría segunda sugerencia de Pablo: A sólo cp sus bases de datos desde el servidor en vivo bajo si usted puede tomar la I/O-hit carga. Si ejecuta una copia replicada de todos modos, también puede copiar de manera segura, sin afectar el rendimiento de su maestro.

7

CouchDB también funciona muy bien con las instantáneas del sistema de archivos que ofrecen los sistemas de archivos modernos, como ZFS. Como el archivo de la 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 da como resultado casi sin sobrecarga de E/S. En caso de que tenga, por ejemplo, borró accidentalmente un documento de la base de datos, puede mover la instantánea a otra máquina y extraer allí los datos faltantes. Incluso es posible que pueda replicar a la base de datos de producción, pero nunca lo he intentado.

Pero siempre asegúrese de utilizar exactamente las mismas revisiones de couchdb cuando se mueva alrededor de los archivos de la base de datos. El formato en disco aún está evolucionando de maneras incompatibles.

1

La duplicació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 se encuentra típicamente en/var/lib/couchdb (a veces en un subdirectorio basado en la versión de 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 obtener los subdirectorios que comienzan con . al archivar los archivos.
  4. Reinicia el servicio couchdb en el host de origen.
  5. scp el archivo tar.gz al host de destino y descomprímalo en una ubicación temporal allí.
  6. chown los archivos para el usuario y el 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 los archivos es la única forma en que logré desordenar este proceso hasta el momento.
  7. Detenga 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. Comprueba dos veces los permisos de archivo en su nuevo hogar.
  10. Reinicie CouchDB en el host de destino.
+4

La replicación es casi lo único en lo que CouchDB es realmente bueno: ese era el objetivo de su diseño de documento basado en revisión. Me preguntaría seriamente por qué lo estás usando si no estás replicando. Además, no necesita detener CouchDB para copiar los archivos (ref: http://wiki.apache.org/couchdb/FilesystemBackups) – slang

+0

¿De verdad? La replicación se bloquea en bases de datos grandes, si el tamaño es más de 20 GB. No estoy hablando de bases de datos en miniatura. O eres un desarrollador de couchdb ... es por eso que respalda este diseño de replicación. Francamente, el producto apesta en la replicación ... ¡el proceso falla muchas veces para DB de gran tamaño! – coffeequant

+1

Jaja, no, no soy un desarrollador de CouchDB, solo lo uso en algunos sistemas de análisis interno en VICE. Y 20 GB no deberían ser un problema. Si tuvieras un fallo, lo reportaría a Apache como un error. – slang

Cuestiones relacionadas