Re: Replication

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Markus Schiltknecht <markus(at)bluegap(dot)ch>
Cc: Hannu Krosing <hannu(at)skype(dot)net>, Fujii Masao <fujii(dot)masao(at)oss(dot)ntt(dot)co(dot)jp>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Replication
Date: 2006-08-23 16:29:41
Message-ID: 1156350581.15743.133.camel@dogma.v10.wvs
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 2006-08-23 at 13:36 +0200, Markus Schiltknecht wrote:
> Hannu Krosing wrote:
> > But if you have very few writes, then there seems no reason to do sync
> > anyway.
>
> I think there is one: high-availability. A standby-server which can
> continue if your primary fails. Of course sync is only needed if you
> absolutely cannot effort loosing any committed transaction.
>

I disagree about high-availability. In fact, I would say that sync
replication is trading availability and performance for synchronization
(which is a valid tradeoff, but costly).

If you have an async system, all nodes must go down for the system to go
down.

If you have a sync system, if any node goes down the system goes down.
If you plan on doing failover, consider this: what if it's not obvious
which system is still up? What if the network route between the two
systems goes down (or just becomes too slow to replicate over), but
clients can still connect to both servers? Then you have two systems
that both think that the other system went down, and both start
accepting transactions. Now you no longer have replication at all.

Regards,
Jeff Davis

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-08-23 16:34:46 Re: Tricky bugs in concurrent index build
Previous Message Gregory Stark 2006-08-23 16:28:23 Re: Tricky bugs in concurrent index build