Re: Replication
От | AgentM |
---|---|
Тема | Re: Replication |
Дата | |
Msg-id | 79B03E81-404C-44CE-9396-5222481ED05F@themactionfaction.com обсуждение исходный текст |
Ответ на | Re: Replication ("D'Arcy J.M. Cain" <darcy@druid.net>) |
Ответы |
Re: Replication
Re: Replication |
Список | 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@gmail.com> wrote: >> On 8/21/06, Alvaro Herrera <alvherre@commandprompt.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
В списке pgsql-hackers по дате отправления: