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

Поиск
Список
Период
Сортировка
От Kevin Grittner
Тема Re: Re: Synch Rep: direct transfer of WAL file from theprimary to the standby
Дата
Msg-id 4A5471CA0200002500028565@gw.wicourts.gov
обсуждение исходный текст
Ответ на Re: Re: Synch Rep: direct transfer of WAL file from the primary to the standby  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Список pgsql-hackers
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> wrote: 
> But more importantly, it can happen by accident. Someone trips on
> the power plug of the slave on Friday, and it goes unnoticed until
> Monday when DBA comes to work.
We've had people unplug things by accident exactly that way.  :-/
We've also had replication across part of our WAN go down for the
better part of a day because a beaver chewed through a fiber optic
cable where it ran through a marsh.  Our (application framework based)
replication just picks up where it left off, without any intervention,
when connectivity is restored.  I think it would be a mistake to
design something less robust than that.
By the way, we don't use any state transitions for this, other than
keeping track of when we seem to have a working connection.  The
client side knows what it last got, and when its reconnection attempts
eventually succeed it makes a request of the server side to provide a
stream of transactions from that point on.  The response to that
request continues indefinitely, as long as the connection is up, which
can be months at a time.
-Kevin
"Everything should be made as simple as possible, but no simpler." - Albert Einstein


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

Предыдущее
От: Noah Misch
Дата:
Сообщение: Re: *_collapse_limit, geqo_threshold
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: multi-threaded pgbench