Re: PostgreSQL + Replicator developer meeting 10/28

On Wed, 2008-10-29 at 19:15 +0200, Hannu Krosing wrote:
>
> > SLAVE 0 is defined by a GUC on the slave, replication_slave_no I think.
> > ( I would have to check the docs)
>
> And the only other GUC slave needs for replication is MCP/Slave connect
> info ?

https://projects.commandprompt.com/public/replicator/wiki/Documentation

>
> > > > 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.
>
> It may be slow-ish to set up initially, but in your (old) tips wikipage
> you say that replicating more than 1000 relations would be prohibitively
> slow.
>

Depends on the workload I would assume.

> > > 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.
>
> Why not ? Because you are actually doing it with triggers, just not
> standard postgreSQL table-level triggers, but your own ones patched into
> backend ?

Because it isn't productive. I am happy to answer all questions (that I
can) about usage, implementation etc... but hashing through decisions
that were made 6 years ago isn't helpful, imo.

> One more question about triggers - what happens to triggers, foreign
> keys and other constraints on slave ?

Alvaro?

>
> > One slave doesn't effect the load on the master any more than fifty.
>
> But have you measured, what is impact of replication when going from 0
> to 1 slaves ?

Not anytime recently no.

>
> You can't replicate a table on Replicator by just one command:

Actually you can. We provide stored procedures you can use if you like.

>
> ALTER TABLE public.accounts ENABLE REPLICATION;
> ALTER TABLE public.accounts ENABLE REPLICATION ON SLAVE 2;
>
> You first have to set things up by telling master and slave about
> themselves ("Thou Art the Master") and about each other.

Actually you have to tell the MCP but yes there is configuration to be
had. It takes about 15 minutes from start to finish for a current
master,mcp,two slave scenario.

> Is Replicator always replicating from one single master to one or more
> slaves ?

Yes.

>
> Or is it possible to set it up so, that some tables are replicated from
> one and some others from some other master.

We do not support cascading like that but we do support partial
replication. E.g;

ALTER TABLE foo ENABLE REPLICATION;
ALTER TABLE foo ENABLE REPLICATION ON SLAVE 1;
ALTER TABLE BAR ENABLE REPLICATION;
ALTER TABLE BAR ENABLE REPLICATION ON SLAVE 2;

>
> I don't mean real multi-master, just that the single master is not the
> same for all tables - A good example would be a sales system where each
> office has its own sales table for inserting/updating data, but has a
> read-only fresh copy of all other offices data via replication .
>

Yes this you could do. What you can't do is this:

MASTER->[SLAVE0|MASTER]->SLAVE1

Sincerely,

Joshua D. Drake

--