incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Gonzalez <gonva...@gonvaled.com>
Subject Re: Faster one-time replication doing file-system copy?
Date Tue, 18 Mar 2014 12:31:10 GMT
Thanks Dave,

Yes, I understand that I need to restart it. Actually, I assume that both
source and destination must be stopped while copying:
- source to avoid data changes while copying, which can lead to
inconsistent data being copied
- destination to avoid that two processes (cp and couchdb) are stepping on
each writing on the same files.

But that is fine with me.

Using zfs / btrfs is overkill for my use case, because I have no experience
with that and I would anyway need to re-install my system, or move couchdb
databases to another partition, which I do not have. Nice idea to keep in
mind for the future though.

BR,
Daniel


On Tue, Mar 18, 2014 at 12:17 PM, Dave Cottlehuber <dch@jsonified.com>wrote:

> Hey Daniel,
>
> copying is fine. But you *will* need to restart couchdb if you pull
> the rug out from under its feet, aka change the file it may have
> cached data from.
>
> If you can I strongly recommend using something like zfs or btrfs to
> make switching back to snapshots super easy. It's a blast!
>
> A+
> Dave
>
> On 18 March 2014 12:13, Daniel Gonzalez <gonvaled@gonvaled.com> wrote:
> > Hi,
> >
> > I have two local couchdbs instances (running on different ports): one
> > master-instance and one testing-instance. Master is a local-copy of my
> real
> > data in the production servers, arriving via replication, but otherwise I
> > do not use it for anything: it is just a local copy that I am using as
> > check-point to recreate the local testing databases.
> >
> > Both have the  same data, but I am doing testing on the testing-instance,
> > so sometimes I want to "reset" the testing-instance to the state of the
> > master-instance (which, as said, is a copy of the real production data)
> >
> > BTW, I am using this intermediate master instance because this way I have
> > always a copy of the production data available; this means that even
> when I
> > have no network available, I can reset the testing instance: only the
> most
> > recent changes to the production data which could not be replicated
> because
> > of the non-existing network connection are missing, and I can live with
> > that.
> >
> > I can recreate the testing instance by replicating master -> testing, but
> > since some of the databases are very big, view recalculation takes
> hours. I
> > am trying to implement a faster method by doing:
> >
> > 1. Stop master and testing instances
> > 2. Copy all databases / design documents / views from master to instance
> > 3. Restart master and instance
> >
> > My question is simply: what are the consequences of recreating databases
> by
> > doing a filesystem copy? Is this going to be accepted by couchdb, or is
> it
> > mandatory to enter the data via replication / REST?
> >
> > Thanks and regards,
> > Daniel Gonzalez
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message