Re: Re: Synch Rep: direct transfer of WAL file from the primary to the standby

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Re: Synch Rep: direct transfer of WAL file from the primary to the standby
Дата
Msg-id 7694.1246981777@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Re: Synch Rep: direct transfer of WAL file from the primary to the standby  (Fujii Masao <masao.fujii@gmail.com>)
Ответы Re: Synch Rep: direct transfer of WAL file from the primary to the standby  (Greg Stark <gsstark@mit.edu>)
Re: Re: Synch Rep: direct transfer of WAL file from the primary to the standby  (Fujii Masao <masao.fujii@gmail.com>)
Список pgsql-hackers
Fujii Masao <masao.fujii@gmail.com> writes:
> On Tue, Jul 7, 2009 at 12:16 AM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
>> I confess to not having paid much attention to this thread so far, but ...
>> what is the rationale for having such a capability at all?

> If the XLOG files which are required for recovery exist only in the
> primary server,
> the standby server has to read them in some way. For example, when the latest
> XLOG file of the primary server is 09 and the standby server has only 01, the
> missing files (02-08) has to be read for recovery by the standby server. In this
> case, the XLOG records in 09 or later are shipped to the standby server in real
> time by synchronous replication feature.

> The problem which I'd like to solve is how to make the standby server read the
> XLOG files (XLOG file, backup history file and timeline history) which
> exist only
> in the primary server. In the previous patch, we had to manually copy those
> missing files to the archive of the standby server or use the warm-standby
> mechanism. This would decrease the usability of synchronous replication. So,
> I proposed one of the solutions which makes the standby server read those
> missing files automatically: introducing new function pg_read_xlogfile() which
> reads the specified XLOG file.

> Is this solution in the right direction? Do you have another
> reasonable solution?

This design seems totally wrong to me.  It's confusing the master's
pg_xlog directory with the archive.  We should *not* use pg_xlog as
a long-term archive area; that's terrible from both a performance
and a reliability perspective.  Performance because pg_xlog has to be
fairly high-speed storage, which conflicts with it needing to hold
a lot of stuff; and reliability because the entire point of all this
is to survive a master server crash, and you're probably not going to
have its pg_xlog anymore after that.

If slaves need to be able to get at past WAL, they should be getting
it from a separate archive server that is independent of the master DB.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: *_collapse_limit, geqo_threshold
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: Re: [COMMITTERS] pgsql: Initialise perl library as documented in perl API.