CouchDB sauvegarde et clonage de la base de données

Question

Nous recherchons CouchdDB pour une application CMS-ish. Quels sont les modèles courants, les meilleures pratiques et les conseils de flux de travail concernant la sauvegarde de notre base de données de production?

Je suis particulièrement intéressé par le processus de clonage de la base de données à des fins de développement et de test.

Suffit-il de simplement copier les fichiers sur le disque à partir d’une instance active? Pouvez-vous cloner des données de base de données entre deux instances en cours d'exécution?

Les conseils et la description des techniques que vous utilisez seront grandement appréciés.

Answer 1

CouchDB prend en charge la réplication. Il vous suffit donc de répliquer sur une autre instance de CouchDB et de la sauvegarder à partir de là, en évitant de perturber l'emplacement où vous écrivez les modifications.

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

Vous envoyez littéralement une demande POST à ??votre instance CouchDB en lui indiquant où se répliquer et cela fonctionne (tm)

EDIT: vous pouvez simplement extraire les fichiers de la base de données en cours d'exécution tant que vous acceptez le hit d'E / S.

Answer 2

Une autre chose à prendre en compte est que vous pouvez copier des fichiers depuis une base de données active. Étant donné que votre base de données peut être volumineuse, vous pouvez simplement la copier hors bande de votre machine de test / production vers une autre machine.

En fonction de la charge d'écriture des machines, il peut être judicieux de déclencher une réplication après la copie pour regrouper les écritures en cours lors de la copie du fichier. Cependant, la réplication de quelques enregistrements serait toujours plus rapide que la réplication de la base de données entière.

Pour référence, voir: http://wiki.apache.org/couchdb/FilesystemBackups

Answer 3

CouchDB fonctionne également très bien avec les instantanés de système de fichiers proposés par les systèmes de fichiers modernes tels que ZFS . Comme le fichier de base de données est toujours dans un état cohérent, vous pouvez en prendre un instantané à tout moment sans affaiblir les garanties d’intégrité fournies par CouchDB.

Il en résulte quasiment aucune surcharge d'E / S. Si vous avez par exemple supprimé accidentellement un document de la base de données, vous pouvez déplacer l’instantané sur une autre machine et y extraire les données manquantes. Vous pourrez peut-être même répliquer dans la base de données de production, mais je n'ai jamais essayé.

Mais assurez-vous de toujours utiliser exactement les mêmes révisions Couchdb lorsque vous vous déplacez dans des fichiers de base de données. Le format sur disque évolue toujours de manière incompatible.

Answer 4

Je voudrais appuyer la suggestion de Paul: il suffit de cp vos fichiers de base de données sous le serveur actif si vous pouvez prendre le hit I / O-load. Si vous exécutez quand même une copie répliquée, vous pouvez également en faire une copie en toute sécurité, sans affecter les performances de votre maître.

Answer 5

La réplication de CouchDB est horrible. Je fais généralement de la tar une bien meilleure qualité.

1. Arrêtez le service CouchDB sur l'hôte source
2. tar.gz les fichiers de données.
3. Sur mes serveurs Ubuntu, cela se trouve généralement dans / var / lib / couchdb (parfois dans un sous-répertoire basé sur la version de Couch). Si vous ne savez pas exactement où se trouvent ces fichiers, vous pouvez trouver le chemin dans vos fichiers de configuration CouchDb, ou souvent en effectuant un ps -A w pour voir la commande complète qui a lancé CouchDb. Assurez-vous d’obtenir les sous-répertoires qui commencent par . lorsque vous archivez les fichiers.
4. Redémarrez le service couchdb sur l'hôte source.
5. scp le fichier tar.gz vers l'hôte de destination et décompressez-le dans un emplacement temporaire.
6. chown les fichiers destinés à l'utilisateur et au groupe possédant les fichiers déjà présents dans le répertoire de la base de données de la destination. C'est probablement couchdb: couchdb. C’est important, car gâcher les autorisations de fichiers est la seule façon pour moi de gâcher ce processus jusqu’à présent.
7. Arrêtez CouchDB sur l'hôte de destination.
8. cp les fichiers dans le répertoire de destination. Encore une fois sur mes hôtes cela a été / var / lib / couchdb.
9. Vérifiez les autorisations de fichiers dans leur nouvelle maison.
10. Redémarrez CouchDB sur l'hôte de destination.