Re: PostgreSQL + Replicator developer meeting 10/28

From: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
To: Hannu Krosing <hannu(at)2ndQuadrant(dot)com>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, pgsql-hackers(at)postgresql(dot)org, Marko Kreen <markokr(at)gmail(dot)com>
Subject: Re: PostgreSQL + Replicator developer meeting 10/28
Date: 2008-10-29 16:01:22
Message-ID: 1225296082.22067.18.camel@jd-laptop.pragmaticzealot.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 2008-10-29 at 12:02 +0200, Hannu Krosing wrote:
> On Tue, 2008-10-28 at 22:16 -0700, Joshua D. Drake wrote:
> > Alvaro Herrera wrote:
> > Case in point. To replicate a table currently you do this:
> >
> > ALTER TABLE foo ENABLE REPLICATION;
> > ALTER TABLE foo ENABLE REPLICATION ON SLAVE 0;
>
> How do you define SLAVE 0 ?

SLAVE 0 is defined by a GUC on the slave, replication_slave_no I think.
( I would have to check the docs)

> > Well actually that was my decision years ago and it was made for two
> > reasons:
> >
> > 1. Speed
>
> Is this some MySQL kind of speed, achieved by compromising on ACID ?
>

No this is the kind that realizes that throwing triggers on 300
relations is a slow way to go about replication.

> Actually I see trigger based replication as a power tool. You can make it (almost)
> as fast as any source level hack, even if the latter compromises on on ACID, plus
> you can be much more flexible on what/when/how you replicate.
>

Like I said, really not interested in the trigger versus not discussion.

> One of the core requirements of the original replicator which can still
> > be seen today AND is a requirement of 1.9 as well is:
> >
> > Though shall not cause grief to thy master even if thy replicates many
> > children.
>
> IOW, one slave and many slaves cause similar load on master.

One slave doesn't effect the load on the master any more than fifty.

>
> And you do it by initially replicating to a single "distributor" slave ?
>

Essentially.

> > That is where the original idea of the MCP came from. They theory was,
> > we could have 50 slaves and the master wouldn't care.
>
> A good goal. But why would anybody _need_ 50 slaves ?
>
> Perhaps some application with small data amount (meaning it fits on one server)
> and massively (100:1) skewed towards reading, like dynamically generated
> mostly-static-content web pages ?

Well it was just a number. It could be any number but yes your example
would fit.

> Why not just make a new kind of wal-logged heap, which stores your version of trx log ?
>

That would be a question for Alvaro or Alexey not I :)

> > and our user
> > experience is far more friendly than anything else.
>
> Do you mean that you have a friendly UI for beginners ?
>

Not just beginners. People don't like complicated software. Generally
speaking, if you go to a DBA of other systems, someone with 10 years
experience and you show them Slony and they look at you like your nuts.
It doesn't matter that Slony works great. It doesn't matter that it is
proven in the field.

> Or is it proved to be robust in continued use, with changes going smoothly
> in and automatic recovery from network outages and random reboots on live
> systems in 24/7 environment ?
>

Well we have had plenty of people use it although I admit over the last
year we have been weening them off in preparation for 1.8. 1.8 is a big
step up from previous releases and yes it has some issues all software
does but we are working on them.

Sincerely,

Joshua D. Drake

--

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joshua D. Drake 2008-10-29 16:02:50 Re: PostgreSQL + Replicator developer meeting 10/28
Previous Message Tom Lane 2008-10-29 15:58:19 Re: WIP patch: convert SQL-language functions to return tuplestores