Re: draft RFC: concept for partial, wal-based replication

From: Andres Freund <andres(at)anarazel(dot)de>
To: Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>
Cc: pgsql-hackers(at)postgresql(dot)org, Itagaki Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, Boszormenyi Zoltan <zb(at)cybertec(dot)at>, hs(at)cybertec(dot)at
Subject: Re: draft RFC: concept for partial, wal-based replication
Date: 2009-11-30 09:37:43
Message-ID: 200911301037.43995.andres@anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Monday 30 November 2009 10:32:50 Stefan Kaltenbrunner wrote:
> Andres Freund wrote:
> > On Monday 30 November 2009 03:57:11 Itagaki Takahiro wrote:
> >> Boszormenyi Zoltan <zb(at)cybertec(dot)at> wrote:
> >>> we tried to discuss on a lower level what should be needed
> >>> for a partial replication based on streaming replication.
> >>
> >> We need to discuss a "partial recovery" before the partial replication.
> >
> > If you do the filtering on the sending side you dont actually need
> > partial recover in the sense that you filter in the rmgr or similar.
> >
> > Or do I miss something?
>
> the question is if filtering on the sending side is actually the "right
> thing" to do.
> It increases the overhead and the complexity on the master, especially
> if you think about different (partial) replication agreements for
> different slaves and it might also be hard to integrate with the planned
> sync/async modes.
> On the other hand if you filter on the master you might be able to avoid
> a lot of network traffic du to filtered wal records.
> I think for a first step it might make more sense to look into doing the
> filtering on the receiving side and look into actual integration with SR
> at a later stage.
I think filtering on the receiving side is harder by many degrees because you
don't have an up 2 date copy of the catalog. I cant think of a design that
does not impose severe constraints on catalog and especially replication
settings to implement on the receiving side.

Andres

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2009-11-30 10:08:37 Re: Hot Standby remaining issues
Previous Message Itagaki Takahiro 2009-11-30 09:36:05 Re: pg_read_file() and non-ascii input file