[ClusterLabs] 4 node, 2 cluster setup with separated applications
Wynand Jansen van Vuuren
esawyja at gmail.com
Thu Mar 19 09:31:59 UTC 2015
Hi all,
I have a different question please, let say I have the following
4 - nodes, 2 clusters, 2 nodes per cluster, so I have in the west of the
country Cluster 1 with cl1_lb1 and cl1_lb2 as the nodes, in the east of the
country I have Cluster 2 with cl2_lb1 and cl2_lb2 as the nodes
I have 3 different applications, Postgres, App1 and App2, App1 uses a VIP
to write to Postgres, App2 uses Apache2
Can I do the following
cl1_lb1, runs Postgres streaming with App1 VIP in Master/Slave
configuration to cl2_lb1
cl1_lb1, cl1_lb2, cl2_lb1 and cl2_lb2 all runs App2 and the VIP round robin
for the Apache page
So my question is actually this, in this configuration, in the
corosync.conf file, what would the expected_votes setting be, 2 or 4? and
can you separate the resources per node? I thought the node_list,
rep_mode="sync" node_list="cl1_lb1 cl2_lb1" in the pgsql primitive would
isolate the pgsql to run on cl1_lb1 and cl2_lb1 only, but it does not seem
to be the case, as soon as I add the other nodes to the corosync
configuration, I get this below
cl1_lb1:/opt/temp # crm_mon -1 -Af
Last updated: Thu Mar 19 11:29:16 2015
Last change: Thu Mar 19 11:10:17 2015 by hacluster via crmd on cl1_lb1
Stack: classic openais (with plugin)
Current DC: cl1_lb1 - partition with quorum
Version: 1.1.9-2db99f1
4 Nodes configured, 4 expected votes
6 Resources configured.
Online: [ cl1_lb1 cl1_lb2 cl2_lb1 cl2_lb2 ]
Node Attributes:
* Node cl1_lb1:
+ master-pgsql : -INFINITY
+ pgsql-data-status : LATEST
+ pgsql-status : STOP
* Node cl1_lb2:
+ pgsql-status : UNKNOWN
* Node cl2_lb1:
+ master-pgsql : -INFINITY
+ pgsql-data-status : LATEST
+ pgsql-status : STOP
* Node cl2_lb2:
+ pgsql-status : UNKNOWN
Migration summary:
* Node cl2_lb1:
pgsql:0: migration-threshold=1 fail-count=1000000 last-failure='Thu Mar
19 11:10:18 2015'
* Node cl1_lb1:
pgsql:0: migration-threshold=1 fail-count=1000000 last-failure='Thu Mar
19 11:10:18 2015'
* Node cl2_lb2:
* Node cl1_lb2:
Failed actions:
pgsql_start_0 (node=cl2_lb1, call=561, rc=1, status=complete): unknown
error
pgsql_start_0 (node=cl1_lb1, call=292, rc=1, status=complete): unknown
error
pgsql_start_0 (node=cl2_lb2, call=115, rc=5, status=complete): not
installed
pgsql_start_0 (node=cl1_lb2, call=73, rc=5, status=complete): not
installed
cl1_lb1:/opt/temp #
Any suggestions on how I can achieve this please ?
Regards
On Wed, Mar 18, 2015 at 7:32 AM, Wynand Jansen van Vuuren <esawyja at gmail.com
> wrote:
> Hi
> Yes the problem was solved, it was the Linux Kernel that started Postgres
> when the failed server came up again, I disabled the automatic start with
> chkconfig and that solved the problem, I will take out 172.16.0.5 from the
> conf file,
> THANKS SO MUCH for all the help, I will do a blog post on how this is done
> on SLES 11 SP3 and Postgres 9.3 and will post the URL for the group, in
> case it will help someone out there, thanks again for all the help!
> Regards
>
> On Wed, Mar 18, 2015 at 3:58 AM, NAKAHIRA Kazutomo <
> nakahira_kazutomo_b1 at lab.ntt.co.jp> wrote:
>
>> Hi,
>>
>> As Brestan pointed out, old master can not come up as a slave is expected
>> feature.
>>
>> BTW, this action is different from the original problem.
>> It seems from logs, promote action succeeded in the cl2_lb1 after power
>> off cl1_lb1.
>> Was the original problem resolved?
>>
>> And cl2_lb1's postgresql.conf has the following problem.
>>
>> 2015-03-17 07:34:28 SAST DETAIL: The failed archive command was: cp
>> pg_xlog/0000001D00000008000000C2 172.16.0.5:/pgtablespace/archive/
>> 0000001D00000008000000C2
>>
>> "172.16.0.5" must be eliminated from the archive_command directive in the
>> postgresql.conf.
>>
>> Best regards,
>> Kazutomo NAKAHIRA
>>
>> On 2015/03/18 5:00, Rainer Brestan wrote:
>>
>>> Yes, thats the expected behaviour.
>>> Takatoshi Matsuo describes in his papers, why a former master cant come
>>> up as
>>> slave without possible data corruption.
>>> And you do not get an indication from Postgres that the data on disk is
>>> corrupted.
>>> Therefore, he created the lock file mechanism to prevent a former master
>>> to
>>> start up.
>>> Making the base backup from Master discards any possibly wrong data from
>>> the
>>> slave and the removed lock files indicates this for the resource agent.
>>> To shorten the discussion about "how this can be automated within the
>>> resource
>>> agent", there is no clean way of handling this with very large
>>> databases, for
>>> which this can take hours.
>>> And what you should do is making the base backup in a temporary
>>> directory and
>>> then renaming this to the name Postgres instance requires after base
>>> backup
>>> finish successful (yes, this requires twice of harddisk space).
>>> Otherwise you
>>> might loose everything, when your master brakes during base backup.
>>> Rainer
>>> *Gesendet:* Dienstag, 17. März 2015 um 12:16 Uhr
>>> *Von:* "Wynand Jansen van Vuuren" <esawyja at gmail.com>
>>> *An:* "Cluster Labs - All topics related to open-source clustering
>>> welcomed"
>>> <users at clusterlabs.org>
>>> *Betreff:* Re: [ClusterLabs] Postgres streaming VIP-REP not coming up on
>>> slave
>>>
>>> Hi
>>> Ok I found this particular problem, when the failed node comes up again,
>>> the
>>> kernel start Postgres, I have disabled this and now the VIPs and
>>> Postgres remain
>>> on the new MASTER, but the failed node does not come up as a slave, IE
>>> there is
>>> no sync between the new master and slave, is this the expected behavior?
>>> The
>>> only way I can get it back into slave mode is to follow the procedure in
>>> the wiki
>>>
>>> # su - postgres
>>> $ rm -rf /var/lib/pgsql/data/
>>> $ pg_basebackup -h 192.168.2.3 -U postgres -D /var/lib/pgsql/data -X
>>> stream -P
>>> $ rm /var/lib/pgsql/tmp/PGSQL.lock
>>> $ exit
>>> # pcs resource cleanup msPostgresql
>>>
>>> Looking forward to your reply please
>>> Regards
>>> On Tue, Mar 17, 2015 at 7:55 AM, Wynand Jansen van Vuuren <
>>> esawyja at gmail.com>
>>> wrote:
>>>
>>> Hi Nakahira,
>>> I finally got around testing this, below is the initial state
>>>
>>> cl1_lb1:~ # crm_mon -1 -Af
>>> Last updated: Tue Mar 17 07:31:58 2015
>>> Last change: Tue Mar 17 07:31:12 2015 by root via crm_attribute on
>>> cl1_lb1
>>> Stack: classic openais (with plugin)
>>> Current DC: cl1_lb1 - partition with quorum
>>> Version: 1.1.9-2db99f1
>>> 2 Nodes configured, 2 expected votes
>>> 6 Resources configured.
>>>
>>>
>>> Online: [ cl1_lb1 cl2_lb1 ]
>>>
>>> Resource Group: master-group
>>> vip-master (ocf::heartbeat:IPaddr2): Started cl1_lb1
>>> vip-rep (ocf::heartbeat:IPaddr2): Started cl1_lb1
>>> CBC_instance (ocf::heartbeat:cbc): Started cl1_lb1
>>> failover_MailTo (ocf::heartbeat:MailTo): Started cl1_lb1
>>> Master/Slave Set: msPostgresql [pgsql]
>>> Masters: [ cl1_lb1 ]
>>> Slaves: [ cl2_lb1 ]
>>>
>>> Node Attributes:
>>> * Node cl1_lb1:
>>> + master-pgsql : 1000
>>> + pgsql-data-status : LATEST
>>> + pgsql-master-baseline : 00000008BE000000
>>> + pgsql-status : PRI
>>> * Node cl2_lb1:
>>> + master-pgsql : 100
>>> + pgsql-data-status : STREAMING|SYNC
>>> + pgsql-status : HS:sync
>>>
>>> Migration summary:
>>> * Node cl2_lb1:
>>> * Node cl1_lb1:
>>> cl1_lb1:~ #
>>> ###### - I then did a init 0 on the master node, cl1_lb1
>>>
>>> cl1_lb1:~ # init 0
>>> cl1_lb1:~ #
>>> Connection closed by foreign host.
>>>
>>> Disconnected from remote host(cl1_lb1) at 07:36:18.
>>>
>>> Type `help' to learn how to use Xshell prompt.
>>> [c:\~]$
>>> ###### - This was ok as the slave took over, became master
>>>
>>> cl2_lb1:~ # crm_mon -1 -Af
>>> Last updated: Tue Mar 17 07:35:04 2015
>>> Last change: Tue Mar 17 07:34:29 2015 by root via crm_attribute on
>>> cl2_lb1
>>> Stack: classic openais (with plugin)
>>> Current DC: cl2_lb1 - partition WITHOUT quorum
>>> Version: 1.1.9-2db99f1
>>> 2 Nodes configured, 2 expected votes
>>> 6 Resources configured.
>>>
>>>
>>> Online: [ cl2_lb1 ]
>>> OFFLINE: [ cl1_lb1 ]
>>>
>>> Resource Group: master-group
>>> vip-master (ocf::heartbeat:IPaddr2): Started cl2_lb1
>>> vip-rep (ocf::heartbeat:IPaddr2): Started cl2_lb1
>>> CBC_instance (ocf::heartbeat:cbc): Started cl2_lb1
>>> failover_MailTo (ocf::heartbeat:MailTo): Started cl2_lb1
>>> Master/Slave Set: msPostgresql [pgsql]
>>> Masters: [ cl2_lb1 ]
>>> Stopped: [ pgsql:1 ]
>>>
>>> Node Attributes:
>>> * Node cl2_lb1:
>>> + master-pgsql : 1000
>>> + pgsql-data-status : LATEST
>>> + pgsql-master-baseline : 00000008C2000090
>>> + pgsql-status : PRI
>>>
>>> Migration summary:
>>> * Node cl2_lb1:
>>> cl2_lb1:~ #
>>> And the logs from Postgres and Corosync are attached
>>> ###### - I then restarted the original Master cl1_lb1 and started
>>> Corosync
>>> manually
>>> Once the original Master cl1_lb1 was up and Corosync running, the
>>> status
>>> below happened, notice no VIPs and Postgres
>>> ###### - Still working below
>>>
>>> cl2_lb1:~ # crm_mon -1 -Af
>>> Last updated: Tue Mar 17 07:36:55 2015
>>> Last change: Tue Mar 17 07:34:29 2015 by root via crm_attribute on
>>> cl2_lb1
>>> Stack: classic openais (with plugin)
>>> Current DC: cl2_lb1 - partition WITHOUT quorum
>>> Version: 1.1.9-2db99f1
>>> 2 Nodes configured, 2 expected votes
>>> 6 Resources configured.
>>>
>>>
>>> Online: [ cl2_lb1 ]
>>> OFFLINE: [ cl1_lb1 ]
>>>
>>> Resource Group: master-group
>>> vip-master (ocf::heartbeat:IPaddr2): Started cl2_lb1
>>> vip-rep (ocf::heartbeat:IPaddr2): Started cl2_lb1
>>> CBC_instance (ocf::heartbeat:cbc): Started cl2_lb1
>>> failover_MailTo (ocf::heartbeat:MailTo): Started cl2_lb1
>>> Master/Slave Set: msPostgresql [pgsql]
>>> Masters: [ cl2_lb1 ]
>>> Stopped: [ pgsql:1 ]
>>>
>>> Node Attributes:
>>> * Node cl2_lb1:
>>> + master-pgsql : 1000
>>> + pgsql-data-status : LATEST
>>> + pgsql-master-baseline : 00000008C2000090
>>> + pgsql-status : PRI
>>>
>>> Migration summary:
>>> * Node cl2_lb1:
>>>
>>> ###### - After original master is up and Corosync running on cl1_lb1
>>>
>>> cl2_lb1:~ # crm_mon -1 -Af
>>> Last updated: Tue Mar 17 07:37:47 2015
>>> Last change: Tue Mar 17 07:37:21 2015 by root via crm_attribute on
>>> cl1_lb1
>>> Stack: classic openais (with plugin)
>>> Current DC: cl2_lb1 - partition with quorum
>>> Version: 1.1.9-2db99f1
>>> 2 Nodes configured, 2 expected votes
>>> 6 Resources configured.
>>>
>>>
>>> Online: [ cl1_lb1 cl2_lb1 ]
>>>
>>>
>>> Node Attributes:
>>> * Node cl1_lb1:
>>> + master-pgsql : -INFINITY
>>> + pgsql-data-status : LATEST
>>> + pgsql-status : STOP
>>> * Node cl2_lb1:
>>> + master-pgsql : -INFINITY
>>> + pgsql-data-status : DISCONNECT
>>> + pgsql-status : STOP
>>>
>>> Migration summary:
>>> * Node cl2_lb1:
>>> pgsql:0: migration-threshold=1 fail-count=2 last-failure='Tue
>>> Mar 17
>>> 07:37:26 2015'
>>> * Node cl1_lb1:
>>> pgsql:0: migration-threshold=1 fail-count=2 last-failure='Tue
>>> Mar 17
>>> 07:37:26 2015'
>>>
>>> Failed actions:
>>> pgsql_monitor_4000 (node=cl2_lb1, call=735, rc=7,
>>> status=complete): not
>>> running
>>> pgsql_monitor_4000 (node=cl1_lb1, call=42, rc=7,
>>> status=complete): not
>>> running
>>> cl2_lb1:~ #
>>> ##### - No VIPs up
>>>
>>> cl2_lb1:~ # ping 172.28.200.159
>>> PING 172.28.200.159 (172.28.200.159) 56(84) bytes of data.
>>> >From 172.28.200.168 <http://172.28.200.168>: icmp_seq=1
>>> Destination Host
>>> Unreachable
>>> >From 172.28.200.168 icmp_seq=1 Destination Host Unreachable
>>> >From 172.28.200.168 icmp_seq=2 Destination Host Unreachable
>>> >From 172.28.200.168 icmp_seq=3 Destination Host Unreachable
>>> ^C
>>> --- 172.28.200.159 ping statistics ---
>>> 5 packets transmitted, 0 received, +4 errors, 100% packet loss,
>>> time 4024ms
>>> , pipe 3
>>> cl2_lb1:~ # ping 172.16.0.5
>>> PING 172.16.0.5 (172.16.0.5) 56(84) bytes of data.
>>> >From 172.16.0.3 <http://172.16.0.3>: icmp_seq=1 Destination Host
>>> Unreachable
>>>
>>> >From 172.16.0.3 icmp_seq=1 Destination Host Unreachable
>>> >From 172.16.0.3 icmp_seq=2 Destination Host Unreachable
>>> >From 172.16.0.3 icmp_seq=3 Destination Host Unreachable
>>> >From 172.16.0.3 icmp_seq=5 Destination Host Unreachable
>>> >From 172.16.0.3 icmp_seq=6 Destination Host Unreachable
>>> >From 172.16.0.3 icmp_seq=7 Destination Host Unreachable
>>> ^C
>>> --- 172.16.0.5 ping statistics ---
>>> 8 packets transmitted, 0 received, +7 errors, 100% packet loss,
>>> time 7015ms
>>> , pipe 3
>>> cl2_lb1:~ #
>>>
>>> Any ideas please, or it it a case of recovering the original master
>>> manually
>>> before starting Corosync etc?
>>> All logs are attached
>>> Regards
>>> On Mon, Mar 16, 2015 at 11:01 AM, Wynand Jansen van Vuuren
>>> <esawyja at gmail.com> wrote:
>>>
>>> Thanks for the advice, I have a demo on this now, so I don't
>>> want to
>>> test this now, I will do so tomorrow and forwards the logs,
>>> many thanks!!
>>> On Mon, Mar 16, 2015 at 10:54 AM, NAKAHIRA Kazutomo
>>> <nakahira_kazutomo_b1 at lab.ntt.co.jp> wrote:
>>>
>>> Hi,
>>>
>>> > do you suggest that I take it out? or should I look at
>>> the problem where
>>> > cl2_lb1 is not being promoted?
>>>
>>> You should look at the problem where cl2_lb1 is not being
>>> promoted.
>>> And I look it if you send me a ha-log and PostgreSQL's log.
>>>
>>> Best regards,
>>> Kazutomo NAKAHIRA
>>>
>>>
>>> On 2015/03/16 17:18, Wynand Jansen van Vuuren wrote:
>>>
>>> Hi Nakahira,
>>> Thanks so much for the info, this setting was as the
>>> wiki page
>>> suggested,
>>> do you suggest that I take it out? or should I look at
>>> the
>>> problem where
>>> cl2_lb1 is not being promoted?
>>> Regards
>>>
>>> On Mon, Mar 16, 2015 at 10:15 AM, NAKAHIRA Kazutomo <
>>> nakahira_kazutomo_b1 at lab.ntt.co.jp> wrote:
>>>
>>> Hi,
>>>
>>> Notice there is no VIPs, looks like the VIPs
>>> depends on
>>> some other
>>>
>>> resource
>>>
>>> to start 1st?
>>>
>>>
>>> The following constraints means that "master-group"
>>> can not
>>> start
>>> without master of msPostgresql resource.
>>>
>>> colocation rsc_colocation-1 inf: master-group
>>> msPostgresql:Master
>>>
>>> After you power off cl1_lb1, msPostgresql on the
>>> cl2_lb1 is
>>> not promoted
>>> and master is not exist in your cluster.
>>>
>>> It means that "master-group" can not run anyware.
>>>
>>> Best regards,
>>> Kazutomo NAKAHIRA
>>>
>>>
>>> On 2015/03/16 16:48, Wynand Jansen van Vuuren wrote:
>>>
>>> Hi
>>> When I start out cl1_lb1 (Cluster 1 load
>>> balancer 1) is
>>> the master as
>>> below
>>> cl1_lb1:~ # crm_mon -1 -Af
>>> Last updated: Mon Mar 16 09:44:44 2015
>>> Last change: Mon Mar 16 08:06:26 2015 by root
>>> via
>>> crm_attribute on cl1_lb1
>>> Stack: classic openais (with plugin)
>>> Current DC: cl2_lb1 - partition with quorum
>>> Version: 1.1.9-2db99f1
>>> 2 Nodes configured, 2 expected votes
>>> 6 Resources configured.
>>>
>>>
>>> Online: [ cl1_lb1 cl2_lb1 ]
>>>
>>> Resource Group: master-group
>>> vip-master (ocf::heartbeat:IPaddr2):
>>> Started cl1_lb1
>>> vip-rep (ocf::heartbeat:IPaddr2):
>>> Started
>>> cl1_lb1
>>> CBC_instance (ocf::heartbeat:cbc):
>>> Started
>>> cl1_lb1
>>> failover_MailTo
>>> (ocf::heartbeat:MailTo):
>>> Started cl1_lb1
>>> Master/Slave Set: msPostgresql [pgsql]
>>> Masters: [ cl1_lb1 ]
>>> Slaves: [ cl2_lb1 ]
>>>
>>> Node Attributes:
>>> * Node cl1_lb1:
>>> + master-pgsql :
>>> 1000
>>> + pgsql-data-status :
>>> LATEST
>>> + pgsql-master-baseline :
>>> 00000008B90061F0
>>> + pgsql-status :
>>> PRI
>>> * Node cl2_lb1:
>>> + master-pgsql :
>>> 100
>>> + pgsql-data-status :
>>> STREAMING|SYNC
>>> + pgsql-status :
>>> HS:sync
>>>
>>> Migration summary:
>>> * Node cl2_lb1:
>>> * Node cl1_lb1:
>>> cl1_lb1:~ #
>>>
>>> If I then do a power off on cl1_lb1 (master),
>>> Postgres
>>> moves to cl2_lb1
>>> (Cluster 2 load balancer 1), but the VIP-MASTER
>>> and
>>> VIP-REP is not
>>> pingable
>>> from the NEW master (cl2_lb1), it stays line
>>> this below
>>> cl2_lb1:~ # crm_mon -1 -Af
>>> Last updated: Mon Mar 16 07:32:07 2015
>>> Last change: Mon Mar 16 07:28:53 2015 by root
>>> via
>>> crm_attribute on cl1_lb1
>>> Stack: classic openais (with plugin)
>>> Current DC: cl2_lb1 - partition WITHOUT quorum
>>> Version: 1.1.9-2db99f1
>>> 2 Nodes configured, 2 expected votes
>>> 6 Resources configured.
>>>
>>>
>>> Online: [ cl2_lb1 ]
>>> OFFLINE: [ cl1_lb1 ]
>>>
>>> Master/Slave Set: msPostgresql [pgsql]
>>> Slaves: [ cl2_lb1 ]
>>> Stopped: [ pgsql:1 ]
>>>
>>> Node Attributes:
>>> * Node cl2_lb1:
>>> + master-pgsql :
>>> -INFINITY
>>> + pgsql-data-status :
>>> DISCONNECT
>>> + pgsql-status :
>>> HS:alone
>>>
>>> Migration summary:
>>> * Node cl2_lb1:
>>> cl2_lb1:~ #
>>>
>>> Notice there is no VIPs, looks like the VIPs
>>> depends on
>>> some other
>>> resource
>>> to start 1st?
>>> Thanks for the reply!
>>>
>>>
>>> On Mon, Mar 16, 2015 at 9:42 AM, NAKAHIRA
>>> Kazutomo <
>>> nakahira_kazutomo_b1 at lab.ntt.co.jp> wrote:
>>>
>>> Hi,
>>>
>>>
>>> fine, cl2_lb1 takes over and acts as a
>>> slave, but
>>> the VIPs does not come
>>>
>>>
>>> cl2_lb1 acts as a slave? It is not a master?
>>> VIPs comes up with master msPostgresql
>>> resource.
>>>
>>> If promote action was failed in the
>>> cl2_lb1, then
>>> please send a ha-log and PostgreSQL's log.
>>>
>>> Best regards,
>>> Kazutomo NAKAHIRA
>>>
>>>
>>> On 2015/03/16 16:09, Wynand Jansen van
>>> Vuuren wrote:
>>>
>>> Hi all,
>>>
>>>
>>> I have 2 nodes, with 2 interfaces each,
>>> ETH0 is
>>> used for an application,
>>> CBC, that's writing to the Postgres DB
>>> on the
>>> VIP-MASTER 172.28.200.159,
>>> ETH1 is used for the Corosync
>>> configuration and
>>> VIP-REP, everything
>>> works,
>>> but if the master currently on cl1_lb1
>>> has a
>>> catastrophic failure, like
>>> power down, the VIPs does not start on
>>> the
>>> slave, the Postgres parts
>>> works
>>> fine, cl2_lb1 takes over and acts as a
>>> slave,
>>> but the VIPs does not come
>>> up. If I test it manually, IE kill the
>>> application 3 times on the
>>> master,
>>> the switchover is smooth, same if I kill
>>> Postgres on master, but when
>>> there
>>> is a power failure on the Master, the
>>> VIPs stay
>>> down. If I then delete
>>> the
>>> attributes pgsql-data-status="LATEST"
>>> and attributes
>>> pgsql-data-status="STREAMING|SYNC" on
>>> the slave
>>> after power off on the
>>> master and restart everything, then the
>>> VIPs
>>> come up on the slave, any
>>> ideas please?
>>> I'm using this setup
>>> http://clusterlabs.org/wiki/
>>> PgSQL_Replicated_Cluster
>>>
>>> With this configuration below
>>> node cl1_lb1 \
>>> attributes
>>> pgsql-data-status="LATEST"
>>> node cl2_lb1 \
>>> attributes
>>> pgsql-data-status="STREAMING|SYNC"
>>> primitive CBC_instance
>>> ocf:heartbeat:cbc \
>>> op monitor interval="60s"
>>> timeout="60s" on-fail="restart" \
>>> op start interval="0s"
>>> timeout="60s"
>>> on-fail="restart" \
>>> meta target-role="Started"
>>> migration-threshold="3"
>>> failure-timeout="60s"
>>> primitive failover_MailTo
>>> ocf:heartbeat:MailTo \
>>> params email="
>>> wynandj at rorotika.com"
>>> subject="Cluster Status
>>> change
>>> - " \
>>> op monitor interval="10"
>>> timeout="10" dept="0"
>>> primitive pgsql ocf:heartbeat:pgsql \
>>> params
>>> pgctl="/opt/app/PostgreSQL/9.
>>> 3/bin/pg_ctl"
>>> psql="/opt/app/PostgreSQL/9.3/bin/psql"
>>> config="/opt/app/pgdata/9.3/
>>> postgresql.conf"
>>> pgdba="postgres"
>>> pgdata="/opt/app/pgdata/9.3/"
>>> start_opt="-p
>>> 5432" rep_mode="sync"
>>> node_list="cl1_lb1 cl2_lb1"
>>> restore_command="cp
>>> /pgtablespace/archive/%f
>>> %p" primary_conninfo_opt="
>>> keepalives_idle=60
>>> keepalives_interval=5
>>> keepalives_count=5"
>>> master_ip="172.16.0.5"
>>> restart_on_promote="false"
>>> logfile="/var/log/OCF.log" \
>>> op start interval="0s"
>>> timeout="60s"
>>> on-fail="restart" \
>>> op monitor interval="4s"
>>> timeout="60s" on-fail="restart" \
>>> op monitor interval="3s"
>>> role="Master" timeout="60s"
>>> on-fail="restart" \
>>> op promote interval="0s"
>>> timeout="60s" on-fail="restart" \
>>> op demote interval="0s"
>>> timeout="60s" on-fail="stop" \
>>> op stop interval="0s"
>>> timeout="60s"
>>> on-fail="block" \
>>> op notify interval="0s"
>>> timeout="60s"
>>> primitive vip-master
>>> ocf:heartbeat:IPaddr2 \
>>> params ip="172.28.200.159"
>>> nic="eth0" iflabel="CBC_VIP"
>>> cidr_netmask="24" \
>>> op start interval="0s"
>>> timeout="60s"
>>> on-fail="restart" \
>>> op monitor interval="10s"
>>> timeout="60s" on-fail="restart" \
>>> op stop interval="0s"
>>> timeout="60s"
>>> on-fail="block" \
>>> meta target-role="Started"
>>> primitive vip-rep ocf:heartbeat:IPaddr2
>>> \
>>> params ip="172.16.0.5"
>>> nic="eth1"
>>> iflabel="REP_VIP"
>>> cidr_netmask="24" \
>>> meta migration-threshold="0"
>>> target-role="Started" \
>>> op start interval="0s"
>>> timeout="60s"
>>> on-fail="stop" \
>>> op monitor interval="10s"
>>> timeout="60s" on-fail="restart" \
>>> op stop interval="0s"
>>> timeout="60s"
>>> on-fail="restart"
>>> group master-group vip-master vip-rep
>>> CBC_instance failover_MailTo
>>> ms msPostgresql pgsql \
>>> meta master-max="1"
>>> master-node-max="1" clone-max="2"
>>> clone-node-max="1" notify="true"
>>> colocation rsc_colocation-1 inf:
>>> master-group
>>> msPostgresql:Master
>>> order rsc_order-1 0:
>>> msPostgresql:promote
>>> master-group:start
>>> symmetrical=false
>>> order rsc_order-2 0: msPostgresql:demote
>>> master-group:stop
>>> symmetrical=false
>>> property $id="cib-bootstrap-options" \
>>> dc-version="1.1.9-2db99f1" \
>>> cluster-infrastructure="
>>> classic
>>> openais (with plugin)" \
>>> expected-quorum-votes="2" \
>>> no-quorum-policy="ignore" \
>>> stonith-enabled="false" \
>>> cluster-recheck-interval="1min"
>>> \
>>> crmd-transition-delay="0s" \
>>>
>>> last-lrm-refresh="1426485983"
>>> rsc_defaults
>>> $id="rsc-options" \
>>>
>>> resource-stickiness="INFINITY" \
>>> migration-threshold="1"
>>> #vim:set syntax=pcmk
>>>
>>> Any ideas please, I'm lost......
>>>
>>>
>>>
>>> ______________________________
>>> _________________
>>> Users mailing list:
>>> Users at clusterlabs.org
>>> http://clusterlabs.org/
>>> mailman/listinfo/users
>>>
>>> Project Home:
>>> http://www.clusterlabs.org
>>> Getting started:
>>> http://www.clusterlabs.org/
>>> doc/Cluster_from_Scratch.pdf
>>> Bugs: http://bugs.clusterlabs.org
>>>
>>>
>>>
>>> ______________________________
>>> _________________
>>> Users mailing list: Users at clusterlabs.org
>>> http://clusterlabs.org/
>>> mailman/listinfo/users
>>>
>>> Project Home: http://www.clusterlabs.org
>>> Getting started:
>>> http://www.clusterlabs.org/
>>> doc/Cluster_from_Scratch.pdf
>>> Bugs: http://bugs.clusterlabs.org
>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing list: Users at clusterlabs.org
>>> http://clusterlabs.org/mailman/listinfo/users
>>>
>>> Project Home: http://www.clusterlabs.org
>>> Getting started:
>>> http://www.clusterlabs.org/
>>> doc/Cluster_from_Scratch.pdf
>>> Bugs: http://bugs.clusterlabs.org
>>>
>>>
>>> --
>>> NTT オープンソースソフトウェアセンタ
>>> 中平 和友
>>> TEL: 03-5860-5135 FAX: 03-5463-6490
>>> Mail: nakahira_kazutomo_b1 at lab.ntt.co.jp
>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing list: Users at clusterlabs.org
>>> http://clusterlabs.org/mailman/listinfo/users
>>>
>>> Project Home: http://www.clusterlabs.org
>>> Getting started:
>>> http://www.clusterlabs.org/
>>> doc/Cluster_from_Scratch.pdf
>>> Bugs: http://bugs.clusterlabs.org
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing list: Users at clusterlabs.org
>>> http://clusterlabs.org/mailman/listinfo/users
>>>
>>> Project Home: http://www.clusterlabs.org
>>> Getting started:
>>> http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
>>> Bugs: http://bugs.clusterlabs.org
>>>
>>>
>>>
>>> --
>>> NTT オープンソースソフトウェアセンタ
>>> 中平 和友
>>> TEL: 03-5860-5135 FAX: 03-5463-6490
>>> Mail: nakahira_kazutomo_b1 at lab.ntt.co.jp
>>>
>>>
>>> _______________________________________________
>>> Users mailing list: Users at clusterlabs.org
>>> http://clusterlabs.org/mailman/listinfo/users
>>>
>>> Project Home: http://www.clusterlabs.org
>>> Getting started: http://www.clusterlabs.org/
>>> doc/Cluster_from_Scratch.pdf
>>> Bugs: http://bugs.clusterlabs.org
>>>
>>> _______________________________________________ Users mailing list:
>>> Users at clusterlabs.org http://clusterlabs.org/mailman/listinfo/users
>>> Project
>>> Home: http://www.clusterlabs.org Getting started:
>>> http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs:
>>> http://bugs.clusterlabs.org
>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing list: Users at clusterlabs.org
>>> http://clusterlabs.org/mailman/listinfo/users
>>>
>>> Project Home: http://www.clusterlabs.org
>>> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
>>> Bugs: http://bugs.clusterlabs.org
>>>
>>>
>>
>>
>> _______________________________________________
>> Users mailing list: Users at clusterlabs.org
>> http://clusterlabs.org/mailman/listinfo/users
>>
>> Project Home: http://www.clusterlabs.org
>> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
>> Bugs: http://bugs.clusterlabs.org
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20150319/d48a1237/attachment-0003.html>
More information about the Users
mailing list