You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Jason Huggins <ja...@jrandolph.com> on 2009/01/19 14:06:41 UTC

Is there a way to force a rebuild of an index?

Hi, all!

Quick Question:
Is there a way to *force* CouchDB to rebuild all indexes in some
stronger way than using the HTTP API?

Why I ask:
I'm running 0.8.0-incubating on Ubuntu (Hardy Heron). I'm trying to
move my couchdb files from an old server to a new server, using this
filesystem backup doc in the wiki as a guide. (
http://wiki.apache.org/couchdb/How_to_make_filesystem_backups )
(Ironically, I wrote that page in the wiki, but the page history
doesn't show it!) :-)

However, after the move, I noticed that several of my indexes (even
some "_all_docs" views are wrong and stale. (Thankfully, the actually
documents are still there, though.) I tried adding and updating new
docs, and I tried simply querying the views to trigger a rebuild of
the indexes. But so far, the indexes are still wrong. I even tried
deleting the ".<db_name>_design" directories on the filesytem. So far,
nothing has worked. Any ideas?

-j.

Re: Is there a way to force a rebuild of an index?

Posted by Paul Davis <pa...@gmail.com>.
Are both versions of couchdb 0.8.0?

Even if so, you might try a dump/load cycle to see if that makes
things better. couchdb-python has some nice utilities for that via
couchdb-dump and couchdb-load

HTH,
Paul Davis

On Mon, Jan 19, 2009 at 8:06 AM, Jason Huggins <ja...@jrandolph.com> wrote:
> Hi, all!
>
> Quick Question:
> Is there a way to *force* CouchDB to rebuild all indexes in some
> stronger way than using the HTTP API?
>
> Why I ask:
> I'm running 0.8.0-incubating on Ubuntu (Hardy Heron). I'm trying to
> move my couchdb files from an old server to a new server, using this
> filesystem backup doc in the wiki as a guide. (
> http://wiki.apache.org/couchdb/How_to_make_filesystem_backups )
> (Ironically, I wrote that page in the wiki, but the page history
> doesn't show it!) :-)
>
> However, after the move, I noticed that several of my indexes (even
> some "_all_docs" views are wrong and stale. (Thankfully, the actually
> documents are still there, though.) I tried adding and updating new
> docs, and I tried simply querying the views to trigger a rebuild of
> the indexes. But so far, the indexes are still wrong. I even tried
> deleting the ".<db_name>_design" directories on the filesytem. So far,
> nothing has worked. Any ideas?
>
> -j.
>

Re: Is there a way to force a rebuild of an index?

Posted by Jason Huggins <ja...@jrandolph.com>.
On Mon, Jan 19, 2009 at 7:50 AM, Paul Davis <pa...@gmail.com> wrote:
> Dude. Trunk.
>
> Also, 0.9 should be out soon if you're looking for a stable release.

:-) Thanks for the nudge.

I just ran another test migration... It appears to be okay now and
does not have a stale index issue. I changed two things: First, before
I copied the files to the *new* server, I stopped the running CouchDB
server. (Sounded like a good idea.) Second, when I copied the files
over, I did not preserve modification times from the source db files.
It would take more testing to further find the source, but I think I'm
good to go for now.

Thanks!

-j.

Re: Is there a way to force a rebuild of an index?

Posted by Paul Davis <pa...@gmail.com>.
On Mon, Jan 19, 2009 at 8:47 AM, Jason Huggins <ja...@jrandolph.com> wrote:
> On Mon, Jan 19, 2009 at 7:16 AM, Jan Lehnardt <ja...@apache.org> wrote:
>> Is the new server running 0.8.0 as well?
>
> Yes. they are both running CouchDB 0.8.0.
>
>> Is there a endian-difference
>> or a 32bit to 64bit upgrade?
>
> No. They are both 32-bit. More context: I'm moving between EC2
> instances. Both are based on 32-bit AMIs from Alestic (This one:
> http://developer.amazonwebservices.com/connect/entry.jspa?externalID=1427&categoryID=101
> )
>
>> I'm not sure the last two things affect us,
>> but that could cause problems). Also: Could "stale" be due to some
>> HTTP proxy or browser cache?
>
> I thought the same thing at first. Though I did try ruling out browser
> cache by trying multiple times on multiple browsers (and clearing the
> cache!). Also I am running everything through an HTTP proxy... but
> also viewing the "raw metal" at port 5984 didn't help either.
>
>> Updating indexes can usually be triggered by changing the design doc
>> they are defined in and deleting the files should work as well.
>>
>> It might also be worth upgrading, since a bit of work went into that
>> area since 0.8.0.
>
> That's what I was suspecting. Should I try 0.8.1 or go all the way to trunk?
>

Dude. Trunk.

Also, 0.9 should be out soon if you're looking for a stable release.

> Thanks,
>   -j
>

Re: Is there a way to force a rebuild of an index?

Posted by Jason Huggins <ja...@jrandolph.com>.
On Mon, Jan 19, 2009 at 7:16 AM, Jan Lehnardt <ja...@apache.org> wrote:
> Is the new server running 0.8.0 as well?

Yes. they are both running CouchDB 0.8.0.

> Is there a endian-difference
> or a 32bit to 64bit upgrade?

No. They are both 32-bit. More context: I'm moving between EC2
instances. Both are based on 32-bit AMIs from Alestic (This one:
http://developer.amazonwebservices.com/connect/entry.jspa?externalID=1427&categoryID=101
)

> I'm not sure the last two things affect us,
> but that could cause problems). Also: Could "stale" be due to some
> HTTP proxy or browser cache?

I thought the same thing at first. Though I did try ruling out browser
cache by trying multiple times on multiple browsers (and clearing the
cache!). Also I am running everything through an HTTP proxy... but
also viewing the "raw metal" at port 5984 didn't help either.

> Updating indexes can usually be triggered by changing the design doc
> they are defined in and deleting the files should work as well.
>
> It might also be worth upgrading, since a bit of work went into that
> area since 0.8.0.

That's what I was suspecting. Should I try 0.8.1 or go all the way to trunk?

Thanks,
   -j

Re: Is there a way to force a rebuild of an index?

Posted by Jan Lehnardt <ja...@apache.org>.
On 19 Jan 2009, at 14:06, Jason Huggins wrote:

> Hi, all!
>
> Quick Question:
> Is there a way to *force* CouchDB to rebuild all indexes in some
> stronger way than using the HTTP API?
>
> Why I ask:
> I'm running 0.8.0-incubating on Ubuntu (Hardy Heron). I'm trying to
> move my couchdb files from an old server to a new server, using this
> filesystem backup doc in the wiki as a guide. (
> http://wiki.apache.org/couchdb/How_to_make_filesystem_backups )
> (Ironically, I wrote that page in the wiki, but the page history
> doesn't show it!) :-)
>
> However, after the move, I noticed that several of my indexes (even
> some "_all_docs" views are wrong and stale. (Thankfully, the actually
> documents are still there, though.) I tried adding and updating new
> docs, and I tried simply querying the views to trigger a rebuild of
> the indexes. But so far, the indexes are still wrong. I even tried
> deleting the ".<db_name>_design" directories on the filesytem. So far,
> nothing has worked. Any ideas?

Is the new server running 0.8.0 as well? Is there a endian-difference
or a 32bit to 64bit upgrade? I'm not sure the last two things affect us,
but that could cause problems). Also: Could "stale" be due to some
HTTP proxy or browser cache?

Updating indexes can usually be triggered by changing the design doc
they are defined in and deleting the files should work as well.

It might also be worth upgrading, since a bit of work went into that
area since 0.8.0.

Cheers
Jan
--