Re: [HACKERS] Proposal for a cascaded master-slave replication system

Jan Wieck <janwieck@yahoo.com>

From: Jan Wieck <JanWieck@Yahoo.com>
To: Jordan Henderson <jordan_henders@Yahoo.com>
Cc: Hans-Jürgen Schönig <hs@cybertec.at>, PostgreSQL General <pgsql-general@postgresql.org>, PostgreSQL Development <pgsql-hackers@postgresql.org>
Date: 2003-11-12T20:30:00Z
Lists: pgsql-hackers, 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 #