[Linux-HA] Double node configuration with mixed ressource
Dejan Muhamedagic
dejanmm at fastmail.fm
Tue Dec 11 05:22:04 MST 2007
Hi,
On Tue, Dec 11, 2007 at 11:03:00AM +0100, Franck Ganachaud wrote:
> Thanks for your time, Dejan.
>
> MySQL is running on both server_a and server_b, both DBs are replicated
> from a third server and used for fast local read purposes.
Is that third server then a SPOF?
> If MySQL fails on server_a and group_1 is on server_a too, heartbeat must
> move group_1 to server_b.
Right. Andrew set the things straight on the clones/colocation
issue.
Thanks,
Dejan
> Franck.
>
> Dejan Muhamedagic a ?crit :
>> Hi,
>>
>> On Tue, Dec 11, 2007 at 09:16:32AM +0000, Franck Ganachaud wrote:
>>
>>> I include the log from the point where I stop mysql
>>> By the way, the cib.xml I included previously is an extreact of the
>>> output of the cibadmin -Q (I removed the status part)
>>>
>>> Looks like the colocation constraint isn't good :
>>> Dec 11 09:59:57 server_a pengine: [2763]: ERROR: unpack_rsc_colocation:
>>> No resource (con=web_if_mysql, rsc=mysql_orb1)
>>>
>>> In my case I don't know then what resource to link the colocation to:
>>> mysql_orb1:0 or mysql_orb1:1? or maybe the clone_max value shoudn't be 2.
>>> It's not clear.
>>>
>>
>> It is probably not useful to have a colocation/location on the
>> cloned resource. At least not in this case. You should regroup
>> and rethink the strategy. First, why do you have the mysql as a
>> cloned resource? How does it operate?
>>
>> Thanks,
>>
>> Dejan
>>
>>
>>
>>> --------- log start ----------------
>>> Dec 11 09:59:25 server_a mysql_orb[4559]: [4564]: INFO: database is OK
>>> Dec 11 09:59:29 server_a apache[4591]: [4681]: INFO: 09:59:29
>>> URL:http://192.168.87.100:80/server-status [1,626/1,626] -> "-" [1]
>>> Dec 11 09:59:42 server_a lsb_log_message: succeeded
>>> Dec 11 09:59:55 server_a mysql_orb[4768]: [4773]: INFO: database is KO
>>> Dec 11 09:59:55 server_a crmd: [2754]: info: process_lrm_event: LRM
>>> operation mysql_orb1:1_monitor_30000 (call=27, rc=7) complete
>>> Dec 11 09:59:55 server_a cib: [2750]: info: cib_diff_notify: Update
>>> (client: 2754, call:66): 0.300.3715 -> 0.300.3716 (ok)
>>> Dec 11 09:59:55 server_a crmd: [2754]: info: do_state_transition:
>>> server_a: State transition S_IDLE -> S_POLICY_ENGINE [ input=I_PE_CALC
>>> cause=C_IPC_MESSAGE origin=route_message ]
>>> Dec 11 09:59:55 server_a tengine: [2762]: info: te_update_diff:
>>> Processing diff (cib_update): 0.300.3715 -> 0.300.3716
>>> Dec 11 09:59:55 server_a crmd: [2754]: info: do_state_transition: All 2
>>> cluster nodes are eligable to run resources.
>>> Dec 11 09:59:55 server_a tengine: [2762]: info: process_graph_event:
>>> Action mysql_orb1:1_monitor_30000 arrived after a completed transition
>>> Dec 11 09:59:55 server_a tengine: [2762]: info: update_abort_priority:
>>> Abort priority upgraded to 1000000
>>> Dec 11 09:59:55 server_a tengine: [2762]: WARN: update_failcount:
>>> Updating failcount for mysql_orb1:1 on
>>> 352f29b5-f0ed-4866-a839-71dbdbfd491d after failed monitor: rc=7
>>> Dec 11 09:59:55 server_a cib: [2750]: info: cib_diff_notify: Update
>>> (client: 2762, call:3): 0.300.3716 -> 0.300.3717 (ok)
>>> Dec 11 09:59:55 server_a tengine: [2762]: info: te_update_diff:
>>> Processing diff (cib_modify): 0.300.3716 -> 0.300.3717
>>> Dec 11 09:59:55 server_a tengine: [2762]: info: extract_event: Aborting
>>> on transient_attributes changes for 352f29b5-f0ed-4866-a839-71dbdbfd491d
>>> Dec 11 09:59:55 server_a pengine: [2763]: info: log_data_element:
>>> process_pe_message: [generation] <cib admin_epoch="0"
>>> cib-last-written="Tue Dec 11 09:54:05 2007" cib_feature_revision="1.3"
>>> epoch="300" generated="true" have_quorum="true" ignore_dtd="false"
>>> num_peers="2" num_updates="3716" ccm_transition="2"
>>> dc_uuid="352f29b5-f0ed-4866-a839-71dbdbfd491d"/>
>>> Dec 11 09:59:55 server_a pengine: [2763]: notice: cluster_option: Using
>>> default value 'stop' for cluster option 'no-quorum-policy'
>>> Dec 11 09:59:55 server_a pengine: [2763]: notice: cluster_option: Using
>>> default value '60s' for cluster option 'cluster-delay'
>>> Dec 11 09:59:55 server_a pengine: [2763]: notice: cluster_option: Using
>>> default value '-1' for cluster option 'pe-error-series-max'
>>> Dec 11 09:59:55 server_a pengine: [2763]: notice: cluster_option: Using
>>> default value '-1' for cluster option 'pe-warn-series-max'
>>> Dec 11 09:59:55 server_a pengine: [2763]: notice: cluster_option: Using
>>> default value '-1' for cluster option 'pe-input-series-max'
>>> Dec 11 09:59:55 server_a pengine: [2763]: notice: cluster_option: Using
>>> default value 'true' for cluster option 'startup-fencing'
>>> Dec 11 09:59:55 server_a pengine: [2763]: info: determine_online_status:
>>> Node server_a is online
>>> Dec 11 09:59:55 server_a pengine: [2763]: info: determine_online_status:
>>> Node server_b is online
>>> Dec 11 09:59:56 server_a pengine: [2763]: ERROR: unpack_rsc_colocation:
>>> No resource (con=web_if_mysql, rsc=mysql_orb1)
>>> Dec 11 09:59:56 server_a pengine: [2763]: info: clone_print: Clone Set:
>>> MySQL_ORB
>>> Dec 11 09:59:56 server_a pengine: [2763]: info: native_print:
>>> mysql_orb1:0 (heartbeat::ocf:mysql_orb): Started server_b
>>> Dec 11 09:59:56 server_a pengine: [2763]: info: native_print:
>>> mysql_orb1:1 (heartbeat::ocf:mysql_orb): Started server_a
>>> Dec 11 09:59:56 server_a pengine: [2763]: info: group_print: Resource
>>> Group: group_1
>>> Dec 11 09:59:56 server_a pengine: [2763]: info: native_print:
>>> IPaddr_Cluster (heartbeat::ocf:IPaddr): Started server_a
>>> Dec 11 09:59:56 server_a pengine: [2763]: info: native_print:
>>> apache_2 (heartbeat::ocf:apache): Started server_a
>>> Dec 11 09:59:56 server_a pengine: [2763]: notice: NoRoleChange: Leave
>>> resource mysql_orb1:0 (server_b)
>>> Dec 11 09:59:56 server_a pengine: [2763]: notice: NoRoleChange: Leave
>>> resource mysql_orb1:1 (server_a)
>>> Dec 11 09:59:56 server_a pengine: [2763]: info: native_color: Combine
>>> scores from apache_2 and IPaddr_Cluster
>>> Dec 11 09:59:56 server_a pengine: [2763]: info: native_assign_node: 2
>>> nodes with equal score (100) for running the listed resources (chose
>>> server_a):
>>> Dec 11 09:59:56 server_a pengine: [2763]: notice: NoRoleChange: Leave
>>> resource IPaddr_Cluster (server_a)
>>> Dec 11 09:59:56 server_a pengine: [2763]: notice: NoRoleChange: Leave
>>> resource apache_2 (server_a)
>>> Dec 11 09:59:56 server_a cib: [4774]: info: write_cib_contents: Wrote
>>> version 0.300.3717 of the CIB to disk (digest:
>>> 484665951aeff3f81f4653ed838910cd)
>>> Dec 11 09:59:56 server_a pengine: [2763]: info: process_pe_message:
>>> Transition 6: PEngine Input stored in:
>>> /var/lib/heartbeat/pengine/pe-input-10.bz2
>>> Dec 11 09:59:57 server_a pengine: [2763]: info: process_pe_message:
>>> Configuration ERRORs found during PE processing. Please run "crm_verify
>>> -L" to identify issues.
>>> Dec 11 09:59:57 server_a pengine: [2763]: info: log_data_element:
>>> process_pe_message: [generation] <cib admin_epoch="0"
>>> cib-last-written="Tue Dec 11 09:54:05 2007" cib_feature_revision="1.3"
>>> epoch="300" generated="true" have_quorum="true" ignore_dtd="false"
>>> num_peers="2" num_updates="3717" ccm_transition="2"
>>> dc_uuid="352f29b5-f0ed-4866-a839-71dbdbfd491d"/>
>>> Dec 11 09:59:57 server_a pengine: [2763]: notice: cluster_option: Using
>>> default value 'stop' for cluster option 'no-quorum-policy'
>>> Dec 11 09:59:57 server_a pengine: [2763]: notice: cluster_option: Using
>>> default value '60s' for cluster option 'cluster-delay'
>>> Dec 11 09:59:57 server_a pengine: [2763]: notice: cluster_option: Using
>>> default value '-1' for cluster option 'pe-error-series-max'
>>> Dec 11 09:59:57 server_a pengine: [2763]: notice: cluster_option: Using
>>> default value '-1' for cluster option 'pe-warn-series-max'
>>> Dec 11 09:59:57 server_a pengine: [2763]: notice: cluster_option: Using
>>> default value '-1' for cluster option 'pe-input-series-max'
>>> Dec 11 09:59:57 server_a pengine: [2763]: notice: cluster_option: Using
>>> default value 'true' for cluster option 'startup-fencing'
>>> Dec 11 09:59:57 server_a pengine: [2763]: info: determine_online_status:
>>> Node server_a is online
>>> Dec 11 09:59:57 server_a pengine: [2763]: info: determine_online_status:
>>> Node server_b is online
>>> Dec 11 09:59:57 server_a pengine: [2763]: ERROR: unpack_rsc_colocation:
>>> No resource (con=web_if_mysql, rsc=mysql_orb1)
>>> Dec 11 09:59:57 server_a pengine: [2763]: info: clone_print: Clone Set:
>>> MySQL_ORB
>>> Dec 11 09:59:57 server_a pengine: [2763]: info: native_print:
>>> mysql_orb1:0 (heartbeat::ocf:mysql_orb): Started server_b
>>> Dec 11 09:59:57 server_a pengine: [2763]: info: native_print:
>>> mysql_orb1:1 (heartbeat::ocf:mysql_orb): Started server_a
>>> Dec 11 09:59:57 server_a pengine: [2763]: info: group_print: Resource
>>> Group: group_1
>>> Dec 11 09:59:57 server_a pengine: [2763]: info: native_print:
>>> IPaddr_Cluster (heartbeat::ocf:IPaddr): Started server_a
>>> Dec 11 09:59:57 server_a pengine: [2763]: info: native_print:
>>> apache_2 (heartbeat::ocf:apache): Started server_a
>>> Dec 11 09:59:58 server_a pengine: [2763]: notice: NoRoleChange: Leave
>>> resource mysql_orb1:0 (server_b)
>>> Dec 11 09:59:58 server_a pengine: [2763]: notice: NoRoleChange: Leave
>>> resource mysql_orb1:1 (server_a)
>>> Dec 11 09:59:58 server_a pengine: [2763]: info: native_color: Combine
>>> scores from apache_2 and IPaddr_Cluster
>>> Dec 11 09:59:58 server_a pengine: [2763]: info: native_assign_node: 2
>>> nodes with equal score (100) for running the listed resources (chose
>>> server_a):
>>> Dec 11 09:59:58 server_a pengine: [2763]: notice: NoRoleChange: Leave
>>> resource IPaddr_Cluster (server_a)
>>> Dec 11 09:59:58 server_a crmd: [2754]: info: do_state_transition:
>>> server_a: State transition S_POLICY_ENGINE -> S_TRANSITION_ENGINE [
>>> input=I_PE_SUCCESS cause=C_IPC_MESSAGE origin=route_message ]
>>> Dec 11 09:59:58 server_a pengine: [2763]: notice: NoRoleChange: Leave
>>> resource apache_2 (server_a)
>>> Dec 11 09:59:58 server_a tengine: [2762]: info: unpack_graph: Unpacked
>>> transition 7: 0 actions in 0 synapses
>>> Dec 11 09:59:58 server_a tengine: [2762]: info: run_graph: Transition 7:
>>> (Complete=0, Pending=0, Fired=0, Skipped=0, Incomplete=0)
>>> Dec 11 09:59:58 server_a tengine: [2762]: info: notify_crmd: Transition 7
>>> status: te_complete - <null>
>>> Dec 11 09:59:58 server_a crmd: [2754]: info: do_state_transition:
>>> server_a: State transition S_TRANSITION_ENGINE -> S_IDLE [
>>> input=I_TE_SUCCESS cause=C_IPC_MESSAGE origin=route_message ]
>>> Dec 11 09:59:58 server_a pengine: [2763]: info: process_pe_message:
>>> Transition 7: PEngine Input stored in:
>>> /var/lib/heartbeat/pengine/pe-input-11.bz2
>>> Dec 11 09:59:58 server_a pengine: [2763]: info: process_pe_message:
>>> Configuration ERRORs found during PE processing. Please run "crm_verify
>>> -L" to identify issues.
>>> Dec 11 09:59:59 server_a apache[4801]: [4890]: INFO: 09:59:59
>>> URL:http://192.168.87.100:80/server-status [1,628/1,628] -> "-" [1]
>>> Dec 11 10:00:25 server_a mysql_orb[4940]: [4946]: INFO: MATISsE database
>>> is KO
>>> Dec 11 10:00:29 server_a apache[4978]: [5068]: INFO: 10:00:29
>>> URL:http://192.168.87.100:80/server-status [1,626/1,626] -> "-" [1]
>>> Dec 11 10:00:55 server_a mysql_orb[5112]: [5117]: INFO: MATISsE database
>>> is KO
>>> --------- log stop ----------------
>>>
>>> Dejan Muhamedagic a ?crit :
>>>
>>>> Hi,
>>>>
>>>> On Mon, Dec 10, 2007 at 04:27:37PM +0100, Franck Ganachaud wrote:
>>>>
>>>>> Ok, here is where I am now.
>>>>>
>>>>> I built a clone set and colocated the group1 with the clone.
>>>>> But when I stop mysql, the clone monitor operation (mysql_orb) return
>>>>> that DB is down but group1 isn't relocated to serveur B.
>>>>>
>>>>> Anyone has a clue?
>>>>>
>>>> Can you post logs? If you have hb_report you can use that.
>>>>
>>>>
>>>>> I copy the cib :
>>>>>
>>>>> <configuration>
>>>>> <crm_config>
>>>>> <cluster_property_set id="cib-bootstrap-options">
>>>>> <attributes>
>>>>> <nvpair id="cib-bootstrap-options-symmetric-cluster"
>>>>> name="symmetric-cluster" value="true"/>
>>>>> <nvpair id="cib-bootstrap-options-no_quorum-policy"
>>>>> name="no_quorum-policy" value="stop"/>
>>>>> <nvpair id="cib-bootstrap-options-default-resource-stickiness"
>>>>> name="default-resource-stickiness" value="0"/>
>>>>> <nvpair
>>>>> id="cib-bootstrap-options-default-resource-failure-stickiness"
>>>>> name="default-resource-failure-stickiness" value="0"/>
>>>>> <nvpair id="cib-bootstrap-options-stonith-enabled"
>>>>> name="stonith-enabled" value="false"/>
>>>>> <nvpair id="cib-bootstrap-options-stonith-action"
>>>>> name="stonith-action" value="reboot"/>
>>>>> <nvpair id="cib-bootstrap-options-stop-orphan-resources"
>>>>> name="stop-orphan-resources" value="true"/>
>>>>> <nvpair id="cib-bootstrap-options-stop-orphan-actions"
>>>>> name="stop-orphan-actions" value="true"/>
>>>>> <nvpair id="cib-bootstrap-options-remove-after-stop"
>>>>> name="remove-after-stop" value="false"/>
>>>>> <nvpair id="cib-bootstrap-options-short-resource-names"
>>>>> name="short-resource-names" value="true"/>
>>>>> <nvpair id="cib-bootstrap-options-transition-idle-timeout"
>>>>> name="transition-idle-timeout" value="5min"/>
>>>>> <nvpair id="cib-bootstrap-options-default-action-timeout"
>>>>> name="default-action-timeout" value="5s"/>
>>>>> <nvpair id="cib-bootstrap-options-is-managed-default"
>>>>> name="is-managed-default" value="true"/>
>>>>> </attributes>
>>>>> </cluster_property_set>
>>>>> </crm_config>
>>>>> <nodes>
>>>>> <node id="0e8b2fa4-983b-4e56-a4a5-72dbb2aeaeec" type="normal"
>>>>> uname="server_a">
>>>>> <instance_attributes
>>>>> id="nodes-0e8b2fa4-983b-4e56-a4a5-72dbb2aeaeec">
>>>>> <attributes>
>>>>> <nvpair id="standby-0e8b2fa4-983b-4e56-a4a5-72dbb2aeaeec"
>>>>> name="standby" value="off"/>
>>>>> </attributes>
>>>>> </instance_attributes>
>>>>> </node>
>>>>> <node id="5cdd04e8-035a-44cf-ab60-3065840109db" type="normal"
>>>>> uname="server_b">
>>>>> <instance_attributes
>>>>> id="nodes-5cdd04e8-035a-44cf-ab60-3065840109db">
>>>>> <attributes>
>>>>> <nvpair id="standby-5cdd04e8-035a-44cf-ab60-3065840109db"
>>>>> name="standby" value="off"/>
>>>>> </attributes>
>>>>> </instance_attributes>
>>>>> </node>
>>>>> <node id="9e05d57a-ae9c-430d-a210-d03b9f37739e" type="normal"
>>>>> uname="server_b"/>
>>>>> <node id="352f29b5-f0ed-4866-a839-71dbdbfd491d" type="normal"
>>>>> uname="server_a"/>
>>>>> </nodes>
>>>>>
>>>> Nodes are listed twice.
>>>>
>>>>
>>>>> <resources>
>>>>> <clone id="MySQL_ORB" interleave="false" is_managed="true"
>>>>> notify="false" ordered="false">
>>>>> <instance_attributes id="MySQL_ORB_inst_attr">
>>>>> <attributes>
>>>>> <nvpair id="MySQL_ORB_attr_0" name="clone_max" value="2"/>
>>>>> <nvpair id="MySQL_ORB_attr_1" name="clone_node_max"
>>>>> value="1"/>
>>>>> </attributes>
>>>>> </instance_attributes>
>>>>> <primitive class="ocf" id="mysql_orb1" is_managed="false"
>>>>> provider="heartbeat" type="mysql_orb">
>>>>> <operations>
>>>>> <op id="mysql_orb_mon" interval="30s" name="monitor"
>>>>> on_fail="stop" timeout="30s"/>
>>>>> </operations>
>>>>> </primitive>
>>>>> </clone>
>>>>> <group id="group_1" restart_type="restart">
>>>>> <primitive class="ocf" id="IPaddr_Cluster" provider="heartbeat"
>>>>> type="IPaddr">
>>>>> <operations>
>>>>> <op id="IPaddr_Cluster_mon" interval="5s" name="monitor"
>>>>> timeout="5s"/>
>>>>> </operations>
>>>>> <instance_attributes id="IPaddr_Cluster_inst_attr">
>>>>> <attributes>
>>>>> <nvpair id="IPaddr_Cluster_attr_0" name="ip"
>>>>> value="192.168.87.100"/>
>>>>> </attributes>
>>>>> </instance_attributes>
>>>>> </primitive>
>>>>> <primitive class="ocf" id="apache_2" provider="heartbeat"
>>>>> type="apache">
>>>>> <operations>
>>>>> <op id="apache_2_mon" interval="30s" name="monitor"
>>>>> timeout="30s"/>
>>>>> </operations>
>>>>> <instance_attributes id="apache_2_inst_attr">
>>>>> <attributes>
>>>>> <nvpair id="apache_2_attr_0" name="configfile"
>>>>> value="/usr/local/apache/conf/httpd.conf"/>
>>>>> </attributes>
>>>>> </instance_attributes>
>>>>> </primitive>
>>>>> </group>
>>>>> </resources>
>>>>> <constraints>
>>>>> <rsc_location id="rsc_location_group_1" rsc="group_1">
>>>>> <rule id="prefered_location_group_1" score="100">
>>>>> <expression attribute="#uname"
>>>>> id="prefered_location_group_1_expr" operation="eq" value="server_a"/>
>>>>> </rule>
>>>>> </rsc_location>
>>>>> <rsc_colocation from="group_1" id="web_if_mysql" score="INFINITY"
>>>>> to="mysql_orb1"/>
>>>>>
>>>> This constraint looks strange. Not sure how should the cluster
>>>> behave, because you have two clones and the web group is bound to
>>>> both.
>>>>
>>>> Thanks,
>>>>
>>>> Dejan
>>>>
>>>>
>>>>> </constraints>
>>>>> </configuration>
>>>>>
>>>>>
>>>>>
>>>>> Franck Ganachaud a ?crit :
>>>>>
>>>>>> Thanks for the tips both of you.
>>>>>>
>>>>>> I'm going to work on that the next few days.
>>>>>>
>>>>>> Andrew Beekhof a ?crit :
>>>>>>
>>>>>>> On Dec 5, 2007, at 1:44 PM, Dejan Muhamedagic wrote:
>>>>>>>
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On Wed, Dec 05, 2007 at 11:51:20AM +0100, Franck Ganachaud wrote:
>>>>>>>>
>>>>>>>>> Well I don't want hearbeat to stop or start mysql.
>>>>>>>>>
>>>>>>>> You should be better off if you do. Otherwise, you'll probably
>>>>>>>> end up with an unmaintainable and complex configuration.
>>>>>>>>
>>>>>>>>
>>>>>>>>> And if I colocate R1 with mysql, will a R1 move from server A to B
>>>>>>>>> implie mysql move also?
>>>>>>>>>
>>>>>>>> Not necessarily. Colocations don't have to be symmetrical.
>>>>>>>>
>>>>>>> particularly not if its a clone (ie. a resource that has a copy
>>>>>>> running on each node)
>>>>>>>
>>>>>>> if you really object to having heartbeat manage mysql, use
>>>>>>> is_managed=false for just the mysql resource.
>>>>>>> with this setting, the cluster will never ever modify the state of
>>>>>>> your resource (only check it's health and make decisions for R1 based
>>>>>>> on that)
>>>>>>>
>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Dejan
>>>>>>>>
>>>>>>>>
>>>>>>>>> Franck.
>>>>>>>>>
>>>>>>>>> Andrew Beekhof a ?crit :
>>>>>>>>>
>>>>>>>>>> On Dec 5, 2007, at 9:42 AM, Franck Ganachaud wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> I try to be more explicit.
>>>>>>>>>>> I use v2 configuration
>>>>>>>>>>>
>>>>>>>>>>> I got 2 servers A and B. A set (group) of resource R1.
>>>>>>>>>>> R1 is running by default on server A and jump to server B in case
>>>>>>>>>>> of
>>>>>>>>>>> trouble.
>>>>>>>>>>> This is currently setup and working fine.
>>>>>>>>>>>
>>>>>>>>>>> Now, i need to check mysql running on both server A and B.
>>>>>>>>>>>
>>>>>>>>>>> If mysql isn't ok on server running R1, I need to stop
>>>>>>>>>>> whateverdaemond and move R1 to the other server
>>>>>>>>>>> If mysql isn't ok on server not running R1, I just need to stop
>>>>>>>>>>> whateverdaemond.
>>>>>>>>>>>
>>>>>>>>>>> I made a OCF agent that does the "stop whateverdaemond if mysql
>>>>>>>>>>> is
>>>>>>>>>>> down" job
>>>>>>>>>>>
>>>>>>>>>> dont do that
>>>>>>>>>> write a proper agent for whateverdaemond (maybe you can use an
>>>>>>>>>> init-script instead)
>>>>>>>>>>
>>>>>>>>>> add a clone resource for mysql
>>>>>>>>>> add a clone resource for whateverdaemond
>>>>>>>>>> colocate whateverdaemond with mysql
>>>>>>>>>> colocate R1 with mysql
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> This where I get puzzled, how to translate the relation between
>>>>>>>>>>> the
>>>>>>>>>>> "if running R1" and the agent I wrote it in heartbeat groups and
>>>>>>>>>>> constraints
>>>>>>>>>>>
>>>>>>>>>>> Hope it's clearer.
>>>>>>>>>>> Franck.
>>>>>>>>>>>
>>>>>>>>>>> Dejan Muhamedagic a ?crit :
>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, Dec 04, 2007 at 05:25:08PM +0100, Franck Ganachaud
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I have a two 2 node cluster.
>>>>>>>>>>>>> group1 is active/passive set of ressource.
>>>>>>>>>>>>> group1 is currently hop-ing from one node to the other as
>>>>>>>>>>>>> intended
>>>>>>>>>>>>> when one of the group ressource isn't available.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Now I have a second task for heartbeat.
>>>>>>>>>>>>> On each node, I have a mysql server, if it goes wrong, I must
>>>>>>>>>>>>> shutdown a service and migrate the group1 (if it runs on this
>>>>>>>>>>>>> node)
>>>>>>>>>>>>> to the other node.
>>>>>>>>>>>>> And this something I don't know how to do.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I was thinking about creating a group2 in an active/active
>>>>>>>>>>>>> configuration testing mysql and if goes wrong just shutdown the
>>>>>>>>>>>>> service in the stop process of the group2 but I don't know how
>>>>>>>>>>>>> to
>>>>>>>>>>>>> force in this case the push of the group1 to the other node of
>>>>>>>>>>>>> it's
>>>>>>>>>>>>> running on the group2 failing node.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>> Sorry, but I can't follow. Can you please rephrase.
>>>>>>>>>>>>
>>>>>>>>>>>> Which configuration do you use: v1 or v2?
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>
>>>>>>>>>>>> Dejan
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Any one can help me?
>>>>>>>>>>>>> Hope it's clear.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Franck.
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> Linux-HA mailing list
>>>>>>>>>>>>> Linux-HA at lists.linux-ha.org
>>>>>>>>>>>>> http://lists.linux-ha.org/mailman/listinfo/linux-ha
>>>>>>>>>>>>> See also: http://linux-ha.org/ReportingProblems
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> Linux-HA mailing list
>>>>>>>>>>>> Linux-HA at lists.linux-ha.org
>>>>>>>>>>>> http://lists.linux-ha.org/mailman/listinfo/linux-ha
>>>>>>>>>>>> See also: http://linux-ha.org/ReportingProblems
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> GANACHAUD Franck
>>>>>>>>>>> Consultant
>>>>>>>>>>> Tel. : +33 (0)2 98 05 43 21
>>>>>>>>>>> http://www.altran.com
>>>>>>>>>>> --
>>>>>>>>>>> Technop?le Brest Iroise
>>>>>>>>>>> Site du Vernis - CS 23866
>>>>>>>>>>> 29238 Brest Cedex 3 - France
>>>>>>>>>>> Tel. : +33 (0)2 98 05 43 21
>>>>>>>>>>> Fax. : +33 (0)2 98 05 20 34
>>>>>>>>>>> e-mail: franck.ganachaud at altran.com
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Linux-HA mailing list
>>>>>>>>>>> Linux-HA at lists.linux-ha.org
>>>>>>>>>>> http://lists.linux-ha.org/mailman/listinfo/linux-ha
>>>>>>>>>>> See also: http://linux-ha.org/ReportingProblems
>>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Linux-HA mailing list
>>>>>>>>>> Linux-HA at lists.linux-ha.org
>>>>>>>>>> http://lists.linux-ha.org/mailman/listinfo/linux-ha
>>>>>>>>>> See also: http://linux-ha.org/ReportingProblems
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> GANACHAUD Franck
>>>>>>>>> Consultant
>>>>>>>>> Tel. : +33 (0)2 98 05 43 21
>>>>>>>>> http://www.altran.com
>>>>>>>>> --
>>>>>>>>> Technop?le Brest Iroise
>>>>>>>>> Site du Vernis - CS 23866
>>>>>>>>> 29238 Brest Cedex 3 - France
>>>>>>>>> Tel. : +33 (0)2 98 05 43 21
>>>>>>>>> Fax. : +33 (0)2 98 05 20 34
>>>>>>>>> e-mail: franck.ganachaud at altran.com
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Linux-HA mailing list
>>>>>>>>> Linux-HA at lists.linux-ha.org
>>>>>>>>> http://lists.linux-ha.org/mailman/listinfo/linux-ha
>>>>>>>>> See also: http://linux-ha.org/ReportingProblems
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Linux-HA mailing list
>>>>>>>> Linux-HA at lists.linux-ha.org
>>>>>>>> http://lists.linux-ha.org/mailman/listinfo/linux-ha
>>>>>>>> See also: http://linux-ha.org/ReportingProblems
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Linux-HA mailing list
>>>>>>> Linux-HA at lists.linux-ha.org
>>>>>>> http://lists.linux-ha.org/mailman/listinfo/linux-ha
>>>>>>> See also: http://linux-ha.org/ReportingProblems
>>>>>>>
>>>>>>>
>>>>> --
>>>>> GANACHAUD Franck
>>>>> Consultant
>>>>> Tel. : +33 (0)2 98 05 43 21
>>>>> http://www.altran.com
>>>>> --
>>>>> Technop?le Brest Iroise
>>>>> Site du Vernis - CS 23866
>>>>> 29238 Brest Cedex 3 - France
>>>>> Tel. : +33 (0)2 98 05 43 21
>>>>> Fax. : +33 (0)2 98 05 20 34
>>>>> e-mail: franck.ganachaud at altran.com
>>>>>
>>>>> _______________________________________________
>>>>> Linux-HA mailing list
>>>>> Linux-HA at lists.linux-ha.org
>>>>> http://lists.linux-ha.org/mailman/listinfo/linux-ha
>>>>> See also: http://linux-ha.org/ReportingProblems
>>>>>
>>>> _______________________________________________
>>>> Linux-HA mailing list
>>>> Linux-HA at lists.linux-ha.org
>>>> http://lists.linux-ha.org/mailman/listinfo/linux-ha
>>>> See also: http://linux-ha.org/ReportingProblems
>>>>
>>>>
>>> --
>>> GANACHAUD Franck
>>> Consultant
>>> Tel. : +33 (0)2 98 05 43 21
>>> http://www.altran.com
>>> --
>>> Technop?le Brest Iroise
>>> Site du Vernis - CS 23866
>>> 29238 Brest Cedex 3 - France
>>> Tel. : +33 (0)2 98 05 43 21
>>> Fax. : +33 (0)2 98 05 20 34
>>> e-mail: franck.ganachaud at altran.com
>>>
>>> _______________________________________________
>>> Linux-HA mailing list
>>> Linux-HA at lists.linux-ha.org
>>> http://lists.linux-ha.org/mailman/listinfo/linux-ha
>>> See also: http://linux-ha.org/ReportingProblems
>>>
>> _______________________________________________
>> Linux-HA mailing list
>> Linux-HA at lists.linux-ha.org
>> http://lists.linux-ha.org/mailman/listinfo/linux-ha
>> See also: http://linux-ha.org/ReportingProblems
>>
>>
>
> --
> GANACHAUD Franck
> Consultant
> Tel. : +33 (0)2 98 05 43 21
> http://www.altran.com
> --
> Technop?le Brest Iroise
> Site du Vernis - CS 23866
> 29238 Brest Cedex 3 - France
> Tel. : +33 (0)2 98 05 43 21
> Fax. : +33 (0)2 98 05 20 34
> e-mail: franck.ganachaud at altran.com
>
> _______________________________________________
> Linux-HA mailing list
> Linux-HA at lists.linux-ha.org
> http://lists.linux-ha.org/mailman/listinfo/linux-ha
> See also: http://linux-ha.org/ReportingProblems
More information about the Linux-HA
mailing list