Обсуждение: clustering with shared storage
Hello.
Sorry if this is redundant, but I can't find any 'cookbook' for getting this setup.
The best I've found is here:
but, it doesn't go into setup details.
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?
1) If I leave it as secondary (non-active), it can't see the shared drive. Is this correct/OK ?
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 ?!?
Thanks.
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, -- Devrim GÜNDÜZ Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz
Вложения
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,
On Tue, 2012-03-20 at 13:33 -0700, amador alvarez wrote: > I wonder why are you considering this solution * Automatic failover detection * No replication overhead, in case you don't need it. RHCS+PostgreSQL can also be used when you shard your data to multiple databases, and use each server as "active" server, like I told in the 25th slide of the presentation that I just in the previous email. So, RHCS and SR/HS are not competitive to each other. We have installed them in parallel several times, like to 3 servers. Regards, -- Devrim GÜNDÜZ Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz
Вложения
On Tue, Mar 20, 2012 at 1:33 PM, amador alvarez <aalvarez@d2.com> wrote: > 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. That's a risk, to be sure. That's why you also keep backups (such as a PITR slave). If you're doing HA without also doing backups, you're Doing It Wrong. The benefit of Shared Storage clustering is immediate availability if your "primary" node goes down for some reason. You simply fence off the downed node, mount the shared volume, and bring up the db on the secondary node. I've used commercial solutions that manage all this, and reliably have the DB back in service in tens of seconds, at the outside. rls -- :wq