Re: Synchronous replication
От | Heikki Linnakangas |
---|---|
Тема | Re: Synchronous replication |
Дата | |
Msg-id | 4C40A35E.1040502@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Synchronous replication (Dimitri Fontaine <dfontaine@hi-media.com>) |
Список | pgsql-hackers |
On 16/07/10 20:26, Dimitri Fontaine wrote: > Le 16 juil. 2010 à 12:43, Heikki Linnakangas<heikki.linnakangas@enterprisedb.com> a écrit : > >> On 16/07/10 10:40, Fujii Masao wrote: >>> So we should always prevent the standby from applying any WAL in pg_xlog >>> unless walreceiver is in progress. That is, if there is no WAL available >>> in the archive, the standby ignores pg_xlog and starts walreceiver >>> process to request for WAL streaming. >> >> That completely defeats the purpose of storing streamed WAL in pg_xlog in the first place. The reason it's written andfsync'd to pg_xlog is that if the standby subsequently crashes, you can use the WAL from pg_xlog to reapply the WAL upto minRecoveryPoint. Otherwise you can't start up the standby anymore. > > I guess we know for sure that this point has been fsync()ed on the Master, or that we could arrange it so that we knowthat? At the moment we only stream WAL that's already been fsync()ed on the master, so we don't have this problem, but Fujii is proposing to change that. I think that's a premature optimization, and we should not try to change that. There is no evidence from field (granted, streaming replication is a new feature) or from performance tests that it is a problem in practice, or that sending WAL earlier would help. Let's concentrate on the bare minimum required to make synchronous replication work. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: