From: | AgentM <agentm(at)themactionfaction(dot)com> |
---|---|
To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Replication |
Date: | 2006-08-21 19:14:10 |
Message-ID: | 79B03E81-404C-44CE-9396-5222481ED05F@themactionfaction.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Aug 21, 2006, at 15:00 , D'Arcy J.M. Cain wrote:
> On Mon, 21 Aug 2006 14:46:05 -0400
> "Gregory Maxwell" <gmaxwell(at)gmail(dot)com> wrote:
>> On 8/21/06, Alvaro Herrera <alvherre(at)commandprompt(dot)com> wrote:
>>> But the confirmation that needs to come is that the WAL changes have
>>> been applied (fsync'ed), so the performance will be terrible. So
>>> bad,
>>> that I don't think anyone will want to use such a replication
>>> system ...
>>
>> Okay. I give up... Why is waiting for fsync on a fast local network
>> which takes 15us to send a message (infiniband is cheap..) an
>> unimaginable delay when we tolerate a local 8ms fsync delay on
>> systems
>> without writeback cache?
>
> OK, that solves your problem. How about my problem where replication
> has to happen on servers in three countries on two continents and
> thousands of updates a second have to happen in less that 10ms?
> This is
> the critical issue with replication - one size does not fit all.
> Syncronous replication, in particular, fits almost no one.
>
> My experience is that any replication needs to be based on your
> business
> rules which will vary widely.
Sure- and more specifically, replication rules may differ on every
table according to those rules. The current solutions are on/off for
a list of tables. I wonder if the various pgsql replication engines
have any problems co-existing...
-M
From | Date | Subject | |
---|---|---|---|
Next Message | Markus Schiltknecht | 2006-08-21 19:17:08 | Re: Replication |
Previous Message | Markus Schiltknecht | 2006-08-21 19:05:21 | Re: Replication |