Re: Replication Ideas

From: Ron Johnson <ron(dot)l(dot)johnson(at)cox(dot)net>
To: PgSQL General ML <pgsql-general(at)postgresql(dot)org>
Subject: Re: Replication Ideas
Date: 2003-08-24 06:13:08
Message-ID: 1061705587.3733.452.camel@haggis
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers pgsql-performance

On Sat, 2003-08-23 at 23:27, Chris Travers wrote:
> Hi--
>
> I had been thinking of the issues of multimaster replication and how to
> do highly available, loadballanced clustering with PostgreSQL. Here is
> my outline, and I am looking for comments on the limitations of how this
> would work.
>
> Several PostgreSQL servers would share a virtual IP address, and would
> coordinate among themselves which will act as "Master" for the purposes
> of a single transaction (but connection could be easier). SELECT
> statements are handled exclusively by the transaction master while
> anything that writes to a database would be sent to all the the
> "Masters." At the end of each transaction the systems would poll
> eachother regarding whether they were all successful:
>
> 1: Any system which is successful in COMMITting the transaction must
> ignore any system which fails the transaction untill a recovery can be made.
>
> 2: Any system which fails in COMMITting the transaction must cease to
> be a master, provided that it recieves a signat from any other member of
> the cluster that indicates that that member succeeded in committing the
> transaction.
>
> 3: If all nodes fail to commit, then they all remain masters.
>
> Recovery would be done in several steps:
>
> 1: The database would be copied to the failed system using pg_dump.
> 2: A current recovery would be done from the transaction log.
> 3: This would be repeated in order to ensure that the database is up to
> date.
> 4: When two successive restores have been achieved with no new
> additions to the database, the "All Recovered" signal is sent to the
> cluster and the node is ready to start processing again. (need a better
> way of doing this).
>
> Note: Recovery is the problem, I know. my model is only a starting
> point for the purposes of discussion and trying to bring something to
> the conversation.

This is vaguely similar to Two Phase Commit, which is a sine qua
non of distributed transactions, which is the s.q.n. of multi-master
replication.

--
-----------------------------------------------------------------
Ron Johnson, Jr. ron(dot)l(dot)johnson(at)cox(dot)net
Jefferson, LA USA

"Eternal vigilance is the price of liberty: power is ever
stealing from the many to the few. The manna of popular liberty
must be gathered each day, or it is rotten... The hand entrusted
with power becomes, either from human depravity or esprit de
corps, the necessary enemy of the people. Only by continual
oversight can the democrat in office be prevented from hardening
into a despot: only by unintermitted agitation can a people be
kept sufficiently awake to principle not to let liberty be
smothered in material prosperity... Never look, for an age when
the people can be quiet and safe. At such times despotism, like
a shrouding mist, steals over the mirror of Freedom"
Wendell Phillips

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message pgman 2003-08-24 14:38:57 Your details
Previous Message Chris Travers 2003-08-24 04:27:41 Replication Ideas

Browse pgsql-hackers by date

  From Date Subject
Next Message Jenny - 2003-08-24 18:21:10 LOCK.tag(figuring out granularity of lock)
Previous Message Chris Travers 2003-08-24 04:27:41 Replication Ideas

Browse pgsql-performance by date

  From Date Subject
Next Message Rhaoni Chiu Pereira 2003-08-25 15:03:12 Query too slow
Previous Message Chris Travers 2003-08-24 04:27:41 Replication Ideas