Re:

Поиск
Список
Период
Сортировка
От Payal Singh
Тема Re:
Дата
Msg-id 20140425180005.GA6284@payal-ThinkPad-T520
обсуждение исходный текст
Ответ на Re:  (Henry Korszun <henryk302@yahoo.com>)
Список pgsql-admin
Once a trigger file is touched on slave, it makes the slave standalone, but doesn't stop the old primary server
automatically.You have to handle that, by either stopping the old primary altogether or pointing a virtual ip to the
newslave.  
On Fri, Apr 25, 2014 at 10:57:16AM -0700, Henry Korszun wrote:
> There IS a trigger file, which does appear to have been "touch"ed.  But the problem is that a fail-over hasn't really
occurredsince the original read/write primary continues to be a fully functioning read/write machine. But it's no
longerreplicating to the erstwhile standby, which has become read/write.  Bottom line, I now have 2 read/write
machines,but with no replication between them. 
>
> On Friday, April 25, 2014 1:43 PM, Scott Whitney <scott@journyx.com> wrote:
>
> Sounds like you might have a "trigger_file" set in your recovery.conf. Do you? That or someone is issuing a pg_ctl
promotecommand. 
>
> ________________________________
>
> I'm using PostgreSQL 9.2.4 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.1.2 20070115 (SUSE Linux), 64-bit.
> >
> >I set up streaming replication for a read/write primary and a read/only
> standby.  The replication works fine for a while, and then out of the
> blue BOTH machines become read/write, but with no replication from the
> original primary to the newly read/write standby.
> >
> >The only log entry that seems relevant is as follows:
> FATAL,57P01,"terminating walreceiver process due to administrator
> command",,,,,,,,"ProcessWalRcvInterrupts, walreceiver.c:150",""
> >
> >Any help/guidance would be appreciated. Thanks in advance.
> >
> >


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

Предыдущее
От: Henry Korszun
Дата:
Сообщение: Re:
Следующее
От: Scott Whitney
Дата:
Сообщение: Re: