incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randall Leeds <randall.le...@gmail.com>
Subject Re: Several newbie CouchDB questions.
Date Wed, 24 Feb 2010 21:49:05 GMT
Hey,

Glad to see more conversation like this popping up.

I've been working with Markus as well as a couple other people in the
community who have approached me individually with Lounge questions or
problems.

Markus is right: oversharding [M shards, N nodes | M > N] allows you to grow
and shrink the cluster fairly easily. Theoretically it would be fairly
straightforward to create a tree of Lounges if you need to grow beyond M
nodes. Supporting replication into/out of the Lounge would get us 90% of the
way toward making this easy. I think this concept is even discussed briefly
in the O'Reilly book.

In environments that receive regular writes an update-notifier script is all
that is needed to periodically refresh nodes that have missed updates (due
to downtime, etc). Lounge relies on this for consistency since it is
currently designed to write to any replica of a shard.

I'm fine to continue discussing Lounge here, but if consensus is that we
should have a separate list please recommend a solution.

I don't believe that the CouchDB wiki is the right place for documentation,
but there should be a clustering faq or something which links to any
available projects (currently only Lounge is public, I believe).

I would absolutely love to get the documentation sorted out and clean up
what's left of the googlecode -> github migration. I'll try to do that this
weekend.

I'm always happy to see community interest. Get in touch if you'd like to
help with anything and let me know if I can answer your questions.

Randall

On Feb 24, 2010 12:11 PM, "Markus Jelsma" <markus@buyways.nl> wrote:

Actually, on some level it does deal with node failure and cluster changes.

Failures are being handled gracefully. Once you have decent sharded
cluster installed, you can actually shut nodes down (as if it's a failure)
and keep it running. I have a test setup with 4 virtual machines, each
running dumb- and smartproxy. It has been sharded on a level that allows
me to shut half the cluster down while pulling data from it using Siege or
ApacheBench; everthing just goes a bit slower. The only thing you need to
keep in mind is that the node you use for access (in my case all 4 grant
access) isn't down; but that can be remedied.

The only thing that can fail during reads is a view that needs to
aggregate data from the nodes. The total resultset can be smaller then
anticipated is a node fails during that process. The final resultset won't
be corrupted though.

Pushing data to the cluster while, for instance, one node is down is a bit
more complicated because you really need to replicate the changes made to
the sharded databases back to the dead node. This must be done manually
before it joins the cluster again. Anyway, it would be a nice feature if
the cluster can repopulate a dead node automatically if it goes up again.

Dealing with cluster changes is a challenge. Adding more nodes to the
cluster is quite easy but reducing is very complicated because it was
already sharded. At this moment, you would need to pull the data from the
cluster, reconfigure the shardmap to fit a reduced cluster, and populate
it again. But beware, growing the cluster will be a tough job if you
haven't given it enough thought up front. By oversharding the cluster,
growth can be accomodated easily - it's just a matter of pointing shards
to another node and copying those sharded databases to the new node. Well,
it isn't that easy but shouldn't give you a headache.

Although we aren't using it in production, we will someday. Perhaps the
lounge developers and production users can say something about their
experience and feature requests.



Time Less said:
>
> I've looked over what little there is, and it appears to me Lounge
> doesn't d...

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