Re: PostgreSQL + Replicator developer meeting 10/28

Hannu Krosing wrote:
> On Tue, 2008-10-28 at 15:18 -0700, Joshua Drake wrote:

> > The two obvious problems with the existing MCP architecture is:
> >
> > 1. Single point of failure
>
> For async replication there is always SPoF, at least the master until
> first slave has aquired log is a SPoF, or do you plan that both Master
> and "MCP|Slave" to keep the log and be able to step in for each other if
> the other fails?

Yeah, with the new architecture there is still going to be a bit of a
SPoF in the master->MCP but it's a lot smaller than the current setup,
in which if you lose the MCP you basically lose everything.

> > 2. Portability
>
> Portability to where ? Other DBMS's ? Other PG versions ?

Other operating systems mainly. The trouble is we never got around to
porting the MCP to any OS beyond Linux; I think it should work on
Solaris and BSDs, but surely not Windows. We want to just get rid of
what I consider a (crappy) reimplementation of postmaster; instead we
should just let postmaster do the job.

Additionally we would get rid of the ugly way we "import" backend code
into the MCP server.

> for me there was also two more problems:
>
> 3. separate "replication log", which at least seems to be able to get
> out of sync with main DB.
>
> Why don't you just use a DB table, WAL-logged and all

The whole replication log thing is a topic of dissent in the team ;-)

> 4. Also, again from reading Replicator FAQ, it seems that there is a
> window of corruption/data loss when rotating the Replicators transaction
> log. I think that doing it with copy/truncate either needs locking the
> logfile (== bad performance, during copy/truncate) or is just a
> data-eating failure waiting to happen.

Hmm, what Replicator FAQ? We used to have this copy/truncate problem,
and we rearchitected the log to avoid this (we use a rotating setup
now)

> > Master->MCP|Slave ->Slave1
> > ->Slave2
> > ->Slave3
> >
> > The process being, Master sends data to MCP|Slave, MCP|Slave writes it
> > to disk (optionally restores it)
>
> Will this first send be sync or async ? Or have you planned to have it
> be configurable among several robustness vs. performance levels, similar
> to the planned integrated WAL-shipping.

It is async, and we haven't talked about sync.

> if async, will it also use MVCC for keeping log on Master (l.ike Slony
> and pgQ do), just to be at least as reliable as postgreSQL core itself
> and not require a full resync at server crash.

You mean WAL? We don't currently.

> > Alvaro or Alexey can speak more technically about implementation than I
> > can.
>
> Alvaro - I guess you already have discussed most of it, but basically
> you need to solve all the same problems that WAL-shipping based Hot
> Standby is solving and Slony/pgQ/Londiste have solved.

If you mean that we're duplicating the effort that's already going
elsewhere, my opinion is yes, we are.

> Hopefully you get it more robust than Slony when making changes under
> high load :)

Hmm, I don't know about lack of robustness in Slony, so I don't know.

> Will there be an helper application for setting up and configuring
> changes in replication. or will it all be done using added SQL
> commands ?

Well, the interface I work on is all SQL commands :-)

> How will DDL be handled ( i understood that you don't yet have DDL
> replication) ?

We don't have it yet. However, since we can just add any code in any
place we like, and that we have a protocol to transmit changes, it is
relatively easy to add calls to collect the needed information and
replay it on the slave.

> Will Slave tables be kind-of-read-only like Slony slaves ? Or even
> _really_ read only like Simon's Hot Standby ?

Heh -- they are read only, and they turn into read-write when the slave
promotes. I'm not sure what kind does that make it :-)

> > > > * DDL Replication
> > >
> > > Is it there alread, or is it just a planned feature ?
> >
> > Planned feature.
>
> Did the plans got any clearer during this meeting ?

Not really; we didn't talk about that.

> > Hmm I am not sure. We are pretty deep into the core and only use
> > triggers for GRANT/REVOKE/CREATE ROLE .
>
> By the way, why did you choose "pretty deep into the core" approach
> instead of triggers ?

Speed maybe? I don't know.

> I mean, you probably end up duplicating (or missing) lots of
> postgreSQL-s internal goodness instead of just using what is already
> available ?

Yeah.

> I hope something useful will come out of this too, though I hoped that
> it already had some advantages over trigger-based replication, like
> ability to replicate DDL .

I fear that our approach to replication is so ad-hoc that there's not
much to be gained from elsewhere. Replicator is pretty much a fork
that's not likely to yield anything useful to upstream.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.