Re: Synchronous replication, reading WAL for sending
От | Fujii Masao |
---|---|
Тема | Re: Synchronous replication, reading WAL for sending |
Дата | |
Msg-id | 3f0b79eb0812240131q75b0fc50s1c23c6f582d28b48@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Synchronous replication, reading WAL for sending ("Pavan Deolasee" <pavan.deolasee@gmail.com>) |
Ответы |
Re: Synchronous replication, reading WAL for sending
Re: Synchronous replication, reading WAL for sending |
Список | pgsql-hackers |
Hi, On Wed, Dec 24, 2008 at 5:48 PM, Pavan Deolasee <pavan.deolasee@gmail.com> wrote: > On Wed, Dec 24, 2008 at 1:50 PM, Fujii Masao <masao.fujii@gmail.com> wrote: >> >> >> And, I'm worried about the situation that the speed to generate xlog >> on the primary is higher than that to copy them to the standby. We >> might not be able to start xlog streaming forever. >> > > If that's the case, how do you expect the standby to keep pace with > the primary after initial sync up ? Good question. If streaming and copying are performed parallelly, such situation doesn't happen because the speed to generate xlog also depends on streaming. This is a price to pay. I think that the serial operations would need a "pace maker". And, I don't know better pace maker than concurrent streaming. > Frankly, I myself have every doubt > that on a relatively high load setup, the standby will not be able > keep pace with the primary for two reasons: > > - Lack of read ahead of data blocks (Suzuki-san's work may help this) > - Single threaded recovery > > But then these are general problems which may impact any log-based replication. Right. Completely high load setup is probably impossible. There is certainly a price to pay. But, in order to reduce a price as much as possible, I think that we should not focus two or more operations on single process (walsender) just like single threaded recovery. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: