Re: replication hooks

On 5/29/08, Andrew Sullivan <ajs(at)commandprompt(dot)com> wrote:
> On Thu, May 29, 2008 at 11:05:09PM +0300, Marko Kreen wrote:
> > There is this tiny matter of replicating schema changes asynchronously,
> > but I suspect nobody actually cares.
>
> I know that Slony's users call this their number one irritant, so I
> have my doubts nobody cares. But maybe nobody cares enough.

Oh, users of course like their lives to be as easy as possible
and all tools be "do as i wish"-complete.

I meant no developer is interested after looking at the task complexity
and resulting payoff.

> > - The task cannot even be clearly defined (on technical level - how
> > the events should be represented).
>
> Really? I've been in discussions where different people had clear
> (but, alas, different) ideas of how to represent them.

Yeah. The main problem is that unless you do WAL based replication,
you cannot achieve transparency. So you need to pick few use cases
and tailor you solution for them, which gets uninteresting very fast
- user _will_ stumble upon spacial cases, and if they expect everything
"just work" the resulting conversation wont be funny.

> > - Any schema changes need to be carefully prepared anyway. Whether
> > to apply them to one or more servers does not make much difference.
>
> One problem that designers of replication systems have is that they're
> already thinking in the Serious Database Application world. But I
> have recently had the pleasure of being reminded how many users of
> database systems neither know nor care to know any of the details of
> the underlying system. They already know how to make schema changes:
> log into database, and start typing "ALTER TABLE. . ." You or I
> agreeing that more careful preparation than that is important will not
> change their mind. This is part of the reason MySQL looks so good:
> you can "just do" these things. If it doesn't work out later, well,
> you don't know that when your ALTER TABLE "just works".

Simple - use WAL-based replication.

Although - not so simple, as currently we don't provide it. The existing
PITR hooks expect users to write their own replication, which is not
a user-friendly approach...

Hopefully this will be fixed in 8.4.

> > - People _do_ care about exact schema on single place - failover servers.
>
> Yeah, but not only there. One of the things I was hoping to have
> nailed down in the "hooks" discussion was, in fact, the use cases.
> Half the time, people have such a clear idea of what _they_ want from
> their replication that they come to believe "replication" means that.

The main problem with replica-hooks-discuss list was lack of focus.

There are various replication methods - single-master, multi-master,
asynchronous, synchronous, WAL-based, trigger-based, changeset-based.

Any combination wants different hooks, putting them all together
makes people not care.

Eg - setting the topic to schema change logging for async trigger-based
replication would be better, but even there are various usage scenarios
that may not be compatible, so it people don't see a chance of common
hooks they don't bother. Actually I suspect this task is solvable,
main problem is that it's pretty low on anyones priority list.

> Another thing I like about the current proposal is that it is very
> clear about what it is (and isn't) aiming for.

Yes. And we can skip the "common hooks" discussion. ;)

--
marko