Hi there,
I wonder why are you considering this solution, as if something wrong
comes within the data (logical corruption, user error) it will be spread
on both locations, Would not be better a delayed standby database.
I am curious because I am setting this up right now and do not get all
the advantages of the shared disk solution,
Thanks in advance,
AA
On 03/20/2012 12:58 PM, Devrim GÜNDÜZ wrote:
Hi,
On Tue, 2012-03-20 at 15:26 -0400, Gary Webster wrote:
The best I've found is here:
http://wiki.postgresql.org/images/5/58/06.5_-_Devrim_Gunduz_-_PostgreSQLClusteringWithRedHatClusterSuite--LT.pdf
but, it doesn't go into setup details.
http://www.gunduz.org/download.php?dlid=190
has a newer version (still not that detailed, but much better)
I have a few questions/issues, but figure I will attack it piecemeal, in
chronological order.
RHCS is handling the fencing.
I have installed postgres on the local drive of the primary, with pgdata on
the shared drive.
I am generally using the EnterpriseDB install package for v9.1.3 .
So, first, just how to install postgres on the secondary?
Just install the binaries -- don't initdb, and then use the shared disk
as the $PGDATA. RHCS will mount the shared filesystem to only one
server, and that one will use the $PGDATa.
1) If I leave it as secondary (non-active), it can't see the shared drive.
Is this correct/OK ?
It *can* see, but it does not see (or it should not see) and it *cannot*
use.
If so, it will create its own pgdata locally, which is later ignored?
or
2) Do I make it primary, then point its pgdata to the already existing
data during install ?!?
See above.
Regards,
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
