incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Cottlehuber <d...@muse.net.nz>
Subject Re: Installation
Date Wed, 25 Jul 2012 07:23:06 GMT
On 25 July 2012 05:13, Tarun Gupta <tarun.gupta@adi-mps.com> wrote:
> Thanks Nils. Actually I have to migrate the couchdb from one server to
> another. I think if I will copy all file directories it will work. Right?
>
> Tarun
>
>
> Best Regards
> TArun Gupta
> Project Manager| MPS Limited
> # 865 | Udyog Vihar Ph- V | Gurgaon | 122016 | India.
> Direct: +91 124 4760052 | Switchboard: +91 124 4760000
> Email: tarun.gupta@adi-mps.com
> www.adi-mps.com
> Upcoming MPS holiday: 15th Aug
>
>
> -----Original Message-----
> From: Nils Breunese [mailto:N.Breunese@vpro.nl]
> Sent: Tuesday, July 24, 2012 8:29 PM
> To: user@couchdb.apache.org
> Subject: Re: Installation
>
> TArun Mps wrote:
>
>> Please suggest where I can find rhel5 installer for couchdb -0.9.1-1.el5.
>
> Are you sure you want to install such an ancient version of CouchDB? Version
> 0.9.1 was released 3 years ago. At one time the EPEL 5 repository [0] may
> have distributed RPM packages for 0.9.1, but doesn't seem to have this file
> available any more [1] and I can't find it anywhere via Google either. You
> could download the source from http://archive.apache.org/dist/couchdb/0.9.1/
> and either install from source or build your own RPM if you really need
> version 0.9.1.
>
> Nils.
>
> [0] http://fedoraproject.org/wiki/EPEL
> [1] http://dl.fedoraproject.org/pub/epel/5/
> ------------------------------------------------------------------------
>  VPRO   www.vpro.nl
> ------------------------------------------------------------------------
>
> This e-mail and/or attachments are confidential and may also be legally privileged. If
you are not the intended recipient, any disclosure, copying, distribution or action taken
relying on the contents is strictly prohibited and may be unlawful. If you have received this
communication in error, please notify the sender immediately by responding to this e-mail
and deleting the contents of the e-mail & related attachments from your system. Though
MPS Limited has taken reasonable steps to ensure no viruses are present in this e-mail, it
cannot accept responsibility for any loss or damage arising from the use of this e-mail or
attachments. No contracts may be concluded with MPS through e-mail communication. Please consider
the environment before printing this e-mail

Hi Tarun,

If you are sticking with 0.9.x then yes. However more likely you are
doing an upgrade, so no. TL;DR expect to do a fair bit of pre-work and
testing for this major upgrade.

You'll need to do a fair bit of testing & checking prior
http://wiki.apache.org/couchdb/Breaking_changes covers a lot of
ground. In addition you also need to be aware that your spidermonkey
version will likely also be different as a result of linking against
newer libraries. Caveat programmator!

In particular, the on-disk format changed at least 2x between 0.9 and
1.2.0, so a direct in place upgrade will definitely not work - the 0.9
migration code was removed before 1.2.0. So a minimum path here is
0.9.x -> 1.1.1 -> 1.2.0 for an in-place upgrade, unless one of the
other devs knows something I missed?

However given the wide version difference,  I think my approach would
be to try to replicate normal docs, using a pull replication initiated
from 1.2.0 end back to 0.9.x, and see if this works successfully,
working through any docs that fail to replicate, and finally, manually
merge in .ini file changes and updated design docs. The replicator
also has changed significantly so I'm not sure if this will work
perfectly either. Expect a few bumps in the road[1].

Both approaches have constraints, but at least with the replicator
approach, if you encounter difficulties they will be at the HTTP / doc
layer, and not in the storage or compaction engine layer.

A+
Dave

[1]:  https://github.com/mikeal/replicate is an external replicator,
node.js based, with a simpler approach that does not use
optimisations.

Mime
View raw message