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 new slave. 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 occurred since the original read/write primary continues to be a fully functioning read/write machine. But it's no longer replicating 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@xxxxxxxxxxx> wrote: > > Sounds like you might have a "trigger_file" set in your recovery.conf. Do you? That or someone is issuing a pg_ctl promote command. > > ________________________________ > > 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. > > > > -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
