| From: | Mark Mielke <mark(at)mark(dot)mielke(dot)cc> |
|---|---|
| To: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> |
| Cc: | Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Greg Stark <gsstark(at)mit(dot)edu>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Re: Synch Rep: direct transfer of WAL file from the primary to the standby |
| Date: | 2009-07-08 14:46:57 |
| Message-ID: | 4A54B161.2000301@mark.mielke.cc |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 07/08/2009 09:59 AM, Kevin Grittner wrote:
> Dimitri Fontaine<dfontaine(at)hi-media(dot)com> wrote:
>
>
>> 4. sync: slave is no more lagging, it's applying the stream as it
>> gets it, either as part of the master transaction or not
>> depending on the GUC settings
>>
>
> I think the interesting bit is when you're at this point and the
> connection between the master and slave goes down for a couple days.
> How do you handle that?
Been following with great interest...
If the updates are not performed at a regular enough interval, the slave
is not truly a functioning standby. I think it's a different problem
domain, probably best served by the existing pg_standby support? If the
slave can be out of touch with the master for an extended period of
time, near real time logs provide no additional benefit over just
shipping the archived WAL logs and running the standby in continuous
recovery mode?
Cheers,
mark
--
Mark Mielke<mark(at)mielke(dot)cc>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2009-07-08 14:59:47 | Re: Re: Synch Rep: direct transfer of WAL file from the primary to the standby |
| Previous Message | Dimitri Fontaine | 2009-07-08 14:37:08 | Re: Re: Synch Rep: direct transfer of WAL file from the primary to the standby |