Hi all,
(My system is CrunchBang waldorf, debian-based)
Currently I have one couchdb instance, and I want to setup a second
couchdb2 with very similar configuration.
Second instance requirements:
- it can be managed like the main one, just by doing /etc/init.d/couchdb2
start|stop|restart|status
On Tue, Mar 18, 2014 at 4:58 PM, Mark Hahn wrote:
> I copy live DBs all the time. Just make sure you don't copy anything along
> with the actual .db file. Let the views rebuild.
>
As you can see in my original email, the *main* point of this exercise is
to avoid view recreation, thus bringing
cool ^_^'
Radhika, what you did is absolutely legit and you won't run into any issues -
as long as the person currently maintaining this package screws up :-).
the OpenSuSE build service is a collaborative, community effort. the person who
built the package you're using had a need for CouchDB
For a while now I've wished couchdb had a fork feature to speed up initial
replication times like this.
curl -X POST -d '{"source":"db1","target":"db2"}'
http://localhost:5984/_fork
Basic process would be something like:
1. Do a simple file system copy to create the new db
2. Set the replication
awesome! It would be super cool if you add your findings into
https://wiki.apache.org/couchdb/Installation
or even better into
https://cwiki.apache.org/confluence/display/COUCHDB/Installing+CouchDB
Simply create a user account and here on the mailinglist to be added as a
contributor to the (c)w
I had to add this repo-
http://download.opensuse.org/repositories/home:ZaWertun:db/SLE_11_SP3/home:ZaWertun:db.repo
and then I could do a zypper install couchdb
I just want to make sure this is legit and I won't run into issues :)
Here is the version I installed-
Information for package couchd
On 18. März 2014 at 17:48:01, Riyad Kalla (rka...@gmail.com) wrote:
> Mark,
> You copy the live DB file to a secondary server, restart the secondary and
> it updates the views using the difference in new data no problem?
Yes; you’ll need to query it of course to trigger that.
> I think Daniel's
> ENOSYS is trying to use a function call that is not available on your
system.
>
> Could be something like you are running erlang with kernel polling
enabled, but your kernel
> doesn’t support that.
>
> try `erl +K true` and see what happens. If it fails, remove +K from your
`couchdb` script.
>
>
> ... calculated VIEWS
You can't calculate anything from more than one doc at once. If you could
then the db could become inconsistent.
If I was smart enough I think I could prove that a DB that can't be
inconsistent can be copied at will.
On Tue, Mar 18, 2014 at 9:47 AM, Riyad Kalla wrote:
Mark,
You copy the live DB file to a secondary server, restart the secondary and
it updates the views using the difference in new data no problem?
I think Daniel's point is the inconsistency that may exist between core DB
and calculated VIEWS unless he takes them all together at the same instant
i
Hi,
if you want the latest version, you may want to use the build service:
https://build.opensuse.org/package/show/server:database/couchdb
Here is a guide to get started with the build service:
http://en.opensuse.org/openSUSE:Build_Service_Enduser_Info
Of course it may not be applicable
Marcello,
cool :)
Cheers
Andy
On 18 March 2014 17:18, Marcello Barnaba wrote:
>
> Hi,
>
> if you want the latest version, you may want to use the build service:
>
> https://build.opensuse.org/package/show/server:database/couchdb
>
> Here is a guide to get started with the build service:
>
ok - so now you should check which version it is. I don't have a suse linux
box available. The actual CouchDB version is 1.5.0 but I don't think it
will be available in the package manager. Hopefully there is 1.2 which
would be ok ... then go and install it (zypper install couchdb). Be aware
that E
Here it is-
lglat253:/usr/bin # zypper search couchdb
Error building the cache:
[|] Valid metadata not found at specified URL(s)
Warning: Disabling repository 'emcjpp' because of the above error.
Loading repository data...
Reading installed packages...
S | Name | Summary
I copy live DBs all the time. Just make sure you don't copy anything along
with the actual .db file. Let the views rebuild.
On Tue, Mar 18, 2014 at 8:10 AM, Daniel Gonzalez wrote:
> On Tue, Mar 18, 2014 at 1:48 PM, Stefan Klein
> wrote:
>
> > Hi,
> >
> > from my understanding which might be w
On Tue, Mar 18, 2014 at 1:48 PM, Stefan Klein wrote:
> Hi,
>
> from my understanding which might be wrong
>
> 2014-03-18 13:31 GMT+01:00 Daniel Gonzalez :
>
> > Thanks Dave,
> >
> > Yes, I understand that I need to restart it. Actually, I assume that both
> > source and destination must be stoppe
On 18 March 2014 15:43, Ramanadham, Radhika wrote:
> Hi,
> I see that we have official releases of couch DB for windows, macOS and
> Ubuntu under http://couchdb.apache.org/
> I wanted to know if its supported on the below version or should I
> anticipate any issues?
>
>
> lglat253:~ # cat /etc/SuS
Hi,
I see that we have official releases of couch DB for windows, macOS and Ubuntu
under http://couchdb.apache.org/
I wanted to know if its supported on the below version or should I anticipate
any issues?
lglat253:~ # cat /etc/SuSE-release
SUSE Linux Enterprise Server 11 (x86_64)
VERSION = 1
I am pretty sure you can get away without stopping the source, so long as you
don’t compact.
Also, if the files are not changing much, you can try using rsync to “catch
up”, at the expense of more CPU on the source, but significantly less data to
transfer overall.
(ensure partial and in-place
Hi,
from my understanding which might be wrong
2014-03-18 13:31 GMT+01:00 Daniel Gonzalez :
> 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 c
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
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+
Da
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
che
23 matches
Mail list logo
