Re: Replication

What you describe sounds like a form of a two-stage commit protocol.

If the command worked on two of the replicated databases but failed on a
third then the executing server would have to be able to undo the command
on the replicated databases as well as itself.

The problems with two stage commit type approches to replication are
1) Speed as you mentioned. Write speed isn't a concern for some
applications but it is very important in others.

and
2) All of the databases must be able to communicate with each other at
all times in order for any edits to work. If the servers are
connected over some sort of WAN that periodically has short outages this
is a problem. Also if your using replication because you want to be able
to take down one of the databases for short periods of time without
bringing down the others your in trouble.

btw: I posted the alternative to Rserv that I mentioned the other day to
the pg-patches mailing list. If anyone is intreasted you should be able
to grab it off the archives.

On Thu, 7 Feb 2002, Gavin Sherry wrote:

>
> First of all, all machines in the cluster would have to be aware all the
> machines in the cluster. This would have to be stored in a new system
> table.
>
> The FE/BE protocol would need to be modified to accepted parsed node trees
> generated by pg_analyze_and_rewrite(). These could then be dispatched by
> the executing server, inside of pg_exec_query_string, to all other servers
> in the cluster (excluding itself). Naturally, this dispatch would need to
> be non-blocking.
>
> pg_exec_query_string() would need to check that nodetags to make sure
> selects and perhaps some commands are not dispatched.
>
> Before the executing server runs finish_xact_command(), it would check
> that the query was successfully executed on all machines otherwise
> abort. Such a system would need a few configuration options: whether or
> not you abort on failed replication to slaves, the ability to replicate
> only certain tables, etc.
>
> Naturally, this would slow down writes to the system (possibly a lot
> depending on the performance difference between the executing machine and
> the least powerful machine in the cluster), but most usages of postgresql
> are read intensive, not write.
>
> Any reason this model would not work?
>
> Gavin
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>

--
Steven Singer ssinger(at)navtechinc(dot)com
Aircraft Performance Systems Phone: 519-747-1170 ext 282
Navtech Systems Support Inc. AFTN: CYYZXNSX SITA: YYZNSCR
Waterloo, Ontario ARINC: YKFNSCR