Skip site navigation (1) Skip section navigation (2)

Re: Future In-Core Replication

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Tatsuo Ishii <ishii(at)postgresql(dot)org>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Future In-Core Replication
Date: 2012-05-01 07:38:11
Message-ID: CA+U5nMJDCXKMJuOEyqipbLOLmQ87ZtKB_NCH8O-0f2koA+c_gg@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Tue, May 1, 2012 at 1:10 AM, Tatsuo Ishii <ishii(at)postgresql(dot)org> wrote:
>> Those are the basic requirements that I am trying to address. There
>> are a great many important details, but the core of this is probably
>> what I would call "logical replication", that is shipping changes to
>> other nodes in a way that does not tie us to the same physical
>> representation that recovery/streaming replication does now. Of
>> course, non-physical replication can take many forms.
>
> Guessing from "shipping changes to other nodes", you seem to
> implicitly aim at asynchronous replication? If so, I am afraid it will
> force users to pay some cost to migrate from existig applications.

The main plan is to use the existing streaming mechanism. That allows
changes/LCRs to be shipped synchronously to some nodes and
asynchronously to others.

We need a mechanism that works across continents, so eager replication
is not the most likely candidate. So the focus would be on shipping
changes after they have been made using lazy replication.

It sounds a bit strange but we can have synchronous lazy replication,
if you wish it.

None of the above presumes anything about the content or role of the
LCRs being shipped.

-- 
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

In response to

pgsql-hackers by date

Next:From: Hannu KrosingDate: 2012-05-01 12:02:40
Subject: JSON in 9.2 - Could we have just one to_json() function instead of two separate versions ?
Previous:From: Josh BerkusDate: 2012-05-01 00:20:04
Subject: Call for Lightning Talks for pgCon

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group