Re: [HACKERS] Proposal for a cascaded master-slave replication system - Mailing list pgsql-general

From Jan Wieck
Subject Re: [HACKERS] Proposal for a cascaded master-slave replication system
Date
Msg-id 3FB29848.3080405@Yahoo.com
Whole thread Raw
In response to Re: [HACKERS] Proposal for a cascaded master-slave replication system  (Jordan Henderson <jordan_henders@yahoo.com>)
List pgsql-general
Jordan Henderson wrote:

> Jan,
>
> I am wondering if you are familar with the work covered in 'Recovery in
> Parallel Database Systems' by Svein-Olaf Hvasshovd (Vieweg) ? The book is an
> excellent detailed description covering high availablility DB
> implementations.

No, but it sounds like something I allways wanted to have.

>
> I think your right on by not thinking smaller!!

Thanks

Jan

>
> Jordan Henderson
> On Wednesday 12 November 2003 10:45, Jan Wieck wrote:
>> Hans-Jürgen Schönig wrote:
>> > Jan,
>> >
>> > First of all we really appreciate that this is going to be an Open
>> > Source project.
>> > There is something I wanted to add from a marketing point of view: I
>> > have done many public talks in the 2 years or so. There is one question
>> > people keep asking me: "How about the pgreplication project?". In every
>> > training course, at any conference people keep asking for synchronous
>> > replication. We have offered this people some async solutions which are
>> > already out there but nobody seems to be interested in having it (my
>> > person impression). People keep asking for a sync approach via email but
>> > nobody seems to care about an async approach. This does not mean that
>> > async is bad but we can see a strong demand for synchronous replication.
>> >
>> > Meanwhile we seem to be in a situation where PostgreSQL is rather
>> > competing against Oracle than against MySQL. In our case there are more
>> > people asking for Oracle -> Pg migration than for MySQL -> Pg. MySQL
>> > does not seem to be the great enemy because most people know that it is
>> > an inferior product anyway. What I want to point out is that some people
>> > want an alternative Oracle's Real Application Cluster. They want load
>> > balancing and hot failover. Even data centers asking for replication did
>> > not want to have an async approach in the past.
>>
>> Hans-Jürgen,
>>
>> we are well aware of the high demand for multi-master replication
>> addressing load balancing and clustering. We have that need ourself as
>> well and I plan to work on a follow-up project as soon as Slony-I is
>> released. But as of now, we see a higher priority for a reliable master
>> slave system that includes the cascading and backup features described
>> in my concept. There are a couple of different similar product out
>> there, I know. But show me one of them where you can failover without
>> becoming the single point of failure? We've just recently seen ... or
>> better "where not able to see anything any more" how failures tend to
>> ripple through systems - half of the US East Coast was dark. So where is
>> the replication system where a slave becomes the "master", and not a
>> standalone server. Show me one that has a clear concept of failback, one
>> that has hot-join as a primary design goal. These are the features that
>> I expect if something is labeled "Enterprise Level".
>>
>> As far as my ideas for multi-master go, it will be a synchronous
>> solution using group communication. My idea is "group commit" instead of
>> 2-Phase ... and an early stage test hack has replicated some update 3
>> weeks ago. The big challange will be to integrate the two systems so
>> that a node can start as an asynchronous Slony-I slave, catch up ... and
>> switch over to synchronous multimaster without stopping the cluster. I
>> have no clue yet how to do that, but I refuse to think smaller.
>>
>>
>> Jan
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 7: don't forget to increase your free space map settings


--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #


pgsql-general by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: pl/perl function life and variable scope - concurrency problem?
Next
From: Doug McNaught
Date:
Subject: Re: SQL-question: returning the id of an insert querry