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,
