Thread: Regarding the shared disk fail over cluster configuration
Dear All, I read the postgresql document for clustering. I am planning to go for the shared disk fail over clustering. But I am unable to understand propery how to achieve this. Below is my hardware setup - I have two server - Primary server and secondary server. Both the server RHEL 6 is installed. I have one storage. RHEL HA clustering is configured to have zero downtime. So if primary server is down then HeartBeat will bring secondary server online. Now i want to install the Postgres and do the shared disk failover clustering. I have couple of doubts 1. Do i need to install Postgres server in both Primary and Secondary Server? 2. According to the shared disk fail over concept the dbdata directory has to be shared. So is it like DB will be installed in both the server and dbdata directory will be in storage and both the database will be referring to the same data in storage? Any help will be appreciated? Thanks, Debasis -- View this message in context: http://postgresql.1045698.n5.nabble.com/Regarding-the-shared-disk-fail-over-cluster-configuration-tp4952316p4952316.html Sent from the PostgreSQL - general mailing list archive at Nabble.com.
Hi, On 31 October 2011 23:33, Debasis Mishra <debasis1982@gmail.com> wrote: > RHEL HA clustering is configured to have zero downtime. So if primary server > is down then HeartBeat will bring secondary server online. By "RHEL HA clustering" do you mean RedHat cluster suite? RHCS uses SIGTERM and then kill -9 after 30 sec(?) so it could be tricky to have zero downtime > 1. Do i need to install Postgres server in both Primary and Secondary > Server? We have Postgres installation on both and SAN volume is mounted to primary only (RHCS takes care about it). (I would use hot standby and two data volumes now instead of shared disk) > 2. According to the shared disk fail over concept the dbdata directory has > to be shared. So is it like DB will be installed in both the server and > dbdata directory will be in storage and both the database will be referring > to the same data in storage? yes, but you should mount $PGDATA (or RHCS) to active instance only. -- Ondrej Ivanic (ondrej.ivanic@gmail.com)
Thanks Ondrej Ivanic, Thanks a lot for your replay. I just wanna know whether it is required for me to run initdb or setting the PGDATA environment variable is enough? Thanks, Debasis -- View this message in context: http://postgresql.1045698.n5.nabble.com/Regarding-the-shared-disk-fail-over-cluster-configuration-tp4952316p4955421.html Sent from the PostgreSQL - general mailing list archive at Nabble.com.
Hi, On 2 November 2011 02:00, Debasis Mishra <debasis1982@gmail.com> wrote: > Thanks a lot for your replay. I just wanna know whether it is required for > me to run initdb or setting the PGDATA environment variable is enough? Master needs to be properly initialised & configured - install postgres - run initdb - install your application schema,... - point $PGDATA to SAN volume Secondary: - install Postgres - point $PGDATA to SAN volume (volume is mounted on primary!) During failover clustering software has to: - shutdown primary (usually: STONITH (Shoot The Other Node In The Head) aka fencing) - mount SAN volume on secondary - startup postgres on secondary -- Ondrej Ivanic (ondrej.ivanic@gmail.com)
Thanks a lot Ondrej Ivanic.I have few more doubts. 1)While installing the postgress it asks for the data directory,which i refer to SAN volume(Shared LUN)-(example - /dbdata/pgsqldata). After that i am exporting $PGDATA= SAN Volume(example - /dbdata/pgsqldata). Where /dbdata is the shared LUN . Then I am running initdb - but it is not running successfully. The Error is /dbdata/pgsqldata is not empty. Because I can understand while installation postgress creates files/directory in the data folder. While running initdb also it is trying to create some directory which is already present. So I am not sure how to go ahead with this scenario. 2) Regarding the shared disk failover clustering you mentioned that if primary fails , cluster should bring it down and start postgres in secondary node. My doubt is - Whether cluster should start the postgres service in secondary node during failover or postgress will be running always. My undersatnding was in both the node postgress will be running and pointing to shared dbdata. And if node1/primary fails then cluster software should bring node2/secondary up.once it will bring node2 online there postgress must be running already. Is this feasible? Thanks, Debasis -- View this message in context: http://postgresql.1045698.n5.nabble.com/Regarding-the-shared-disk-fail-over-cluster-configuration-tp4952316p4958449.html Sent from the PostgreSQL - general mailing list archive at Nabble.com.
On November 2, 2011 08:55:39 AM Debasis Mishra wrote: > My doubt is - Whether cluster should start the postgres service in > secondary node during failover or postgress will be running always. My > undersatnding was in both the node postgress will be running and pointing > to shared dbdata. And if node1/primary fails then cluster software should > bring node2/secondary up.once it will bring node2 online there postgress > must be running already. You definitely cannot have 2 postmasters running against the same shared disk. The cluster software will need to start PostgreSQL on the secondary node after taking over the IP address and shared disk resource.
On Wed, Nov 2, 2011 at 11:55 AM, Debasis Mishra <debasis1982@gmail.com> wrote:
Thanks a lot Ondrej Ivanic.I have few more doubts.
1)While installing the postgress it asks for the data directory,which i
refer to SAN volume(Shared LUN)-(example - /dbdata/pgsqldata).
After that i am exporting $PGDATA= SAN Volume(example - /dbdata/pgsqldata).
Where /dbdata is the shared LUN .
Then I am running initdb - but it is not running successfully. The Error is
/dbdata/pgsqldata is not empty.
Because I can understand while installation postgress creates
files/directory in the data folder. While running initdb also it is trying
to create some directory which is already present.
So I am not sure how to go ahead with this scenario.
It seems that your installer has already created the data for you. If you have files like:
postgresql.conf
base/
pg_xlog/
......
Then your postgres data directory is already initialized, no need for initdb.
2) Regarding the shared disk failover clustering you mentioned that if
primary fails , cluster should bring it down and start postgres in secondary
node.
My doubt is - Whether cluster should start the postgres service in secondary
node during failover or postgress will be running always. My undersatnding
was in both the node postgress will be running and pointing to shared
dbdata. And if node1/primary fails then cluster software should bring
node2/secondary up.once it will bring node2 online there postgress must be
running already.
Is this feasible?
Do not do this. At first glance, you can actually run in this configuration (i.e. you can start the postmasters) but it will cause data corruption. DO NOT under ANY circumstances try to run both primary and secondary on the same data directory simultaneously. You will corrupt your entire database. The only way to run postgres with shared disk clustering is in Active/Passive mode.
--
Scott Mead
OpenSCG http://www.openscg.com
Thanks,
Debasis
--
View this message in context: http://postgresql.1045698.n5.nabble.com/Regarding-the-shared-disk-fail-over-cluster-configuration-tp4952316p4958449.htmlSent from the PostgreSQL - general mailing list archive at Nabble.com.--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
I am also try to create PostgreSQL failover cluster server using RHEL6.1 OS. I am creating few things, but right now I am not configure 1. Resources and Service Groups. 2. Heartbit, 3. Automatic failover. Some body please help. I am waiting for your valuable reply. Thanks Gautam -- View this message in context: http://postgresql.1045698.n5.nabble.com/Regarding-the-shared-disk-fail-over-cluster-configuration-tp4952316p5733542.html Sent from the PostgreSQL - general mailing list archive at Nabble.com.