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 >>>>>>>>>>>>> [email protected] >>>>>>>>>>>>> http://lists.linux-ha.org/mailman/listinfo/linux-ha >>>>>>>>>>>>> See also: http://linux-ha.org/ReportingProblems >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Linux-HA mailing list >>>>>>>>>>>> [email protected] >>>>>>>>>>>> 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: [EMAIL PROTECTED] >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Linux-HA mailing list >>>>>>>>>>> [email protected] >>>>>>>>>>> http://lists.linux-ha.org/mailman/listinfo/linux-ha >>>>>>>>>>> See also: http://linux-ha.org/ReportingProblems >>>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Linux-HA mailing list >>>>>>>>>> [email protected] >>>>>>>>>> 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: [EMAIL PROTECTED] >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Linux-HA mailing list >>>>>>>>> [email protected] >>>>>>>>> http://lists.linux-ha.org/mailman/listinfo/linux-ha >>>>>>>>> See also: http://linux-ha.org/ReportingProblems >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Linux-HA mailing list >>>>>>>> [email protected] >>>>>>>> http://lists.linux-ha.org/mailman/listinfo/linux-ha >>>>>>>> See also: http://linux-ha.org/ReportingProblems >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> Linux-HA mailing list >>>>>>> [email protected] >>>>>>> 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: [EMAIL PROTECTED] >>>>> >>>>> _______________________________________________ >>>>> Linux-HA mailing list >>>>> [email protected] >>>>> http://lists.linux-ha.org/mailman/listinfo/linux-ha >>>>> See also: http://linux-ha.org/ReportingProblems >>>>> >>>> _______________________________________________ >>>> Linux-HA mailing list >>>> [email protected] >>>> 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: [EMAIL PROTECTED] >>> >>> _______________________________________________ >>> Linux-HA mailing list >>> [email protected] >>> http://lists.linux-ha.org/mailman/listinfo/linux-ha >>> See also: http://linux-ha.org/ReportingProblems >>> >> _______________________________________________ >> Linux-HA mailing list >> [email protected] >> 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: [EMAIL PROTECTED] > > _______________________________________________ > Linux-HA mailing list > [email protected] > http://lists.linux-ha.org/mailman/listinfo/linux-ha > See also: http://linux-ha.org/ReportingProblems _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
