Re: Standbys which don't synch to disk?
От | Fujii Masao |
---|---|
Тема | Re: Standbys which don't synch to disk? |
Дата | |
Msg-id | BANLkTi=_zLWLbF8SLJ3bGY+aTogqt0gKmA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Standbys which don't synch to disk? (Josh Berkus <josh@agliodbs.com>) |
Список | pgsql-hackers |
On Thu, May 12, 2011 at 3:48 AM, Josh Berkus <josh@agliodbs.com> wrote: > Robert, > >> > That WAL has effectively disappeared from the >> > master, but is still present on the slave. Now the master comes up >> > and starts processing read-write transactions again, and generates a >> > new and different 1kB of WAL. Hilarity ensues, because the two >> > machines are now out of step with each other. > > Yeah, you'd need some kind of instant failover and STONITH. That is, > any interruption on the master would be a failover situation. While > that seems conceivable for crashes, consider that a planned restart of > the master might be an issue, and an OOM-kill would certainly be. > >> > You could possibly fix this by making provision for the master to >> > connect to the slave on start-up and stream WAL "backwards" from slave >> > to master. That'd be pretty spiffy. > > Ouch, now you're making my head hurt. I believe many people who use SR with a clusterware would do failover instead of restarting the master when it crashes. So I don't think it's bad idea to allow them to use the stream-WAL-from-buffers feature with self-responsibility. It's the same thing as we can specify fsync=off or full_page_writes=off. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: