Re: Synchronous Log Shipping Replication

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Hannu Krosing <hannu(at)krosing(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us>, Markus Wanner <markus(at)bluegap(dot)ch>, ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Synchronous Log Shipping Replication
Date: 2008-09-11 15:17:57
Message-ID: 48C936A5.6000700@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Fujii Masao wrote:
> I think that this case would often happen. So, we should establish a certain
> solution or procedure to the case where TLI of the master doesn't match
> TLI of the slave. If we only allow the case where TLI of both servers is the
> same, the configuration after failover always needs to get the base backup
> on the new master. It's unacceptable for many users. But, I think that it's
> the role of admin or external tools to copy history files to the slave from
> the master.

Hmm. There's more problems than the TLI with that. For the original
master to catch up by replaying WAL from the new slave, without
restoring from a full backup, the original master must not write to disk
*any* WAL that hasn't made it to the slave yet. That is certainly not
true for asynchronous replication, but it also throws off the idea of
flushing the WAL concurrently to the local disk and to the slave in
synchronous mode.

I agree that having to get a new base backup to get the old master catch
up with the new master sucks, so I hope someone sees a way around that.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kenneth Marshall 2008-09-11 15:24:38 Re: hash index improving v3
Previous Message Fujii Masao 2008-09-11 15:03:55 Re: Synchronous Log Shipping Replication