couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kocoloski <kocol...@apache.org>
Subject Re: Changing a CouchDB view
Date Tue, 12 Jan 2010 17:08:38 GMT
On Jan 12, 2010, at 12:00 PM, Luke Sneeringer wrote:

> Good morning, CouchDB peoples! :-)
> 
> In a few days, I am going to embark on a bit of CouchDB system adminstritivia, and I
would appreciate it if a couple folks would be willing to read over my evil plans and tell
me if I'm making any mistakes. But, pay no attention to the large red button conspicuously
labelled "SELF-DESTRUCT", of course.
> 
> On to business:
> I have a CouchDB database. Everyone say, "Hi, database!". It's decently large (about
1 GB of textual data across maybe 120,000-ish updates). I also have a design document with
two views that I use in order to pull back these documents based on their contents. Anyway,
if this view were ever to substantively change, CouchDB must rebuild the view, which is a
lengthy process (20 minutes or so?), and the view can't be queried until it's done.
> 
> My goal is to change this view and minimize downtime.
> 
> So, here's how I plan to do it:
> 1. Replicate the original database to a copy on the same machine: "Hi, copy!" Give the
copy the new and improved views, and let them build. This way, the original keeps going with
the original views while the copy is building. Of course, the original view is receiving new
updates. This means the bulk of the view rebuild time is happening now, and my project is
still in a working date.
> 
> 2. Put site in maintenance mode, stop CouchDB.
> 
> 3. Rename the databases (flip flop them).
> 
> 4. Bring CouchDB up.
> 
> 5. Replicate the old, outgoing database to the new one again -- this would get the new
updates that came in during the view rebuild process, and the new views would only have to
build that small delta (almost instantaneous).
> 
> 6. Bring site out of maintenance mode.
> 
> So, my question:
> - Is this process a good one? Is there a better one I am not seeing?
> - Any pitfalls or snags I should know about?
> 
> Thanks!
> Luke Sneeringer

Hi Luke, there's an easier way.  View indices are stored according to the hash of the functions
in them, so you could add a "staging" design doc with the new version of your views, trigger
a build, and then copy the contents of that design doc to the production design doc.  Your
production app should switch over to the newly built indices with zero downtime.  In fact
if you like you can use HTTP COPY from staging to production to ensure there are no typos
when you deploy :)  Best,

Adam


Mime
View raw message