Re: Streaming replication on 9.1-beta2 after pg_restore is very slow

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: Streaming replication on 9.1-beta2 after pg_restore is very slow
Дата
Msg-id CA+U5nMJD4LS2=orsOOgU+sKapTmn3-_fmox_u5fjvnc7JjAUeA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Streaming replication on 9.1-beta2 after pg_restore is very slow  (David Hartveld <David.Hartveld@mendix.com>)
Список pgsql-general
On Thu, Jul 7, 2011 at 2:59 PM, David Hartveld
<David.Hartveld@mendix.com> wrote:

> I've been looking at my log files on master and slave a bit better, after having set log_min_messages = debug5. I can
seethat somehow the master and slave don't properly work together: the slave attempts to send some data ('sending
write/flush/apply')(I'm assuming this is the slaves current location in the WAL?) and then 'terminates process due to
administratorcommand', while the master is sending data ('write/flush/apply') (the next part of the WAL?), and then
'couldnot send data to the client: Connection reset by peer', after which the server process exits. I'm hoping this
providesyou with more information on what is going on. Do point me in the right direction if you need me to investigate
further.I have attached two pieces of the master and slave log files, which should correspond w.r.t. their interaction,
whereyou can see the above behavior. 

Ah, so synchronous_standby_names is set on the standby.

Please reset that so we are operating asynchronously, then rerun tests
to see if that avoids the error. You'll probably need to fully
re-generate the standby server before doing this.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

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

Предыдущее
От: salah jubeh
Дата:
Сообщение: Re: Oracle to Postgres migration open source tool
Следующее
От: Jeff Davis
Дата:
Сообщение: Re: Latency problems with simple queries