On 06/24/2010 08:31 PM, Pete Zaitcev wrote:
I worked on fixing the metadata replication in tabled. There were some
difficulties in existing code, in particular the aliasing between the
hostname used to identify nodes and the hostname used in bind() for
listening was impossible to work around in repmgr. In the end I gave
up on repmgr and switched tabled to the "Base" API. So, the replication
works now... for some values of "works", which is still a progress.
We essentially have a tabled that can really be considered as replicated.
Before, it was only data replication, which was great and all but
useless against disk failues in the tabled's database. I think it's
a major treshold for tabled.
er, huh? In addition to data replication, we already have metadata
replication via db4 repmgr in tabled.git, which ensures metadata db
integrity in the case of disk or tabled node failure.
The core problem with current tabled.git is that S3 clients expect all
nodes to support PUT/DELETE as well as GET. Our current use w/ db4
slave mode does not fulfill this client requirement.
Your work here, moving to the base replication API, eliminates several
obstacles on the path to making all tabled nodes support PUT/DELETE.
But it is not true to say that metadata replication did not exist prior
to this patch.
With either repmgr or base API, we still need to make failover more
transparent to our S3 clients.
Unfortunately, the code is rather ugly. I tried to create a kind
of an optional replication layer, so that tdbadm could be built
without it. Although I succeeded, the result is a hideous mess of
methods and callbacks, functions with side effects, and a bunch
of poorly laid out state machines. In places I cannot wrap my own
head around what's going on without a help of pencil and paper.
So, while working, it's not ready for going in. Still, I'm going
to throw it here in case I get hit by a bus, or if anyone wants
an example of using db4 replication early.
Based on a quick read, it seems straightforward, and looks like
something I can try tomorrow...
Very excited to try this :)
Jeff
--
To unsubscribe from this list: send the line "unsubscribe hail-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
