|
From: Ben C. <ben...@gm...> - 2011-01-09 07:27:29
|
Well I plunged ahead and gave it a go.Hot standby is up and running but am
unable to log on on the standby server. This is the error in the postgres
logs - first of many once this is patched no doubt:
2011-01-09 18:07:08 ESTERROR: cannot execute SELECT FOR UPDATE in a
read-only transaction
2011-01-09 18:07:08 ESTSTATEMENT:
SELECT a_session FROM sessions WHERE id = $1 FOR
UPDATE
So far I've been unable to figure out what perl subroutine (?) is causing
this but my general impression is that it may be a bit of a minefield trying
to turn netdisco into a read-only server.
Can any of the devs confirm whether or not this is worth trying to do? If
netdisco fundamentally relies on session information being in the database
and this can't be easily changed, then I am thinking not.. On the other hard
the documentation seems to be point to session information being stored in a
perl hash m->session, so is the sessions table that important?
By the way the background for this is that our netdisco users can't access
the network that is allowed to 'snmp' the network, hence the separate
servers.
On Sat, Jan 8, 2011 at 5:55 PM, Ben Carbery <ben...@gm...> wrote:
> I am interested in turning my 'public' netdisco server - which receives
> full database dumps from the 'private' server - into a slave and enabling
> postgres 9.0's new hot standby feature. This feature forces slave databases
> into a read-only state.
>
> The only sticking points I can see is that the slave will attempt to write
> logon information from the web interface, as well as the batch job logs.
>
> Is there a (relatively easy) way to get netdisco on the slave to write to
> the master database but continue to read from itself?
> I also would be interested to hear if anyone has yet tried to get netdisco
> working in a hot standby setup.
>
> cheers,
>
> B
>
"Because it that the times revive as time is fresh somehow, and it to feel
wins why, and, as for it, all forget an old thing" - Japanese saying
|