> On Wed, Mar 27, 2013 at 6:12 AM, Robinson, Eric > <eric.robin...@psmnv.com> wrote: > >> >> > In the simplest terms, we currently have resources: > >> >> > > >> >> > A = drbd > >> >> > B = filesystem > >> >> > C = cluster IP > >> >> > D thru J = mysql instances. > >> >> > > >> >> > Resource group G1 consists of resources B through J, in > >> >> that order, and is dependent on resource A. > >> >> > > >> >> > This fails over fine, but it has the serious disadvantage > >> >> that if you stop or remove a mysql resource in the > middle of the > >> >> list, all of the ones after it stop too. For example, if > >> you stop G, > >> >> then H thru J stop as well. > >> >> > > >> >> > We want to change it so that the resource group G1 consists > >> >> only of resources B & C. All of the mysql instances (D thru > >> >> J) are individually dependent on group G1, but not > >> dependent on each > >> >> other. That way you can stop or remove a mysql resource without > >> >> affecting the others. > >> >> > > >> >> > I saw this scenario described in the Pacemaker docs, but I > >> >> cannot find an example of the syntax. > >> >> > >> >> You can use two resource-sets and go without groups, > with that crm > >> >> shell > >> >> syntax: > >> >> > >> >> order o_drbd-filesystem-ip-dbs inf: A:promote B C (D E > F G H I J) > >> >> colocate co_all-follow-drbd inf: (D E F G H I J) B C A:Master > >> >> > >> >> Regards, > >> >> Andreas > >> >> > >> > > >> > Oh my gosh, that's what I have been trying to figure out > >> for a year or more. I am very excited to try this. Note that I > >> actually have more like 50 mysql resources, not just 7 like in the > >> example. Will that be a problem? > >> > >> No. > >> > >> Did you also consider: > >> > >> G1 = A, B, C > >> > >> colocate D with G1 > >> order D after G1 > >> > >> colocate E with G1 > >> order E after G1 > >> > >> ... > >> > >> The set syntax cuts down on the duplication, but the above > will also > >> work. > >> > > > > I tried that but without all the extra order statements. I > thought the order was implied. > > > > By definition, doesn't... > > > > colocation c1 inf: D G1 > > > > ..mean "figure out where to start G1 and THEN put D there?" > > No. Not in the way you're thinking. > > "THEN" applies to the order in which decisions are made, once > the decision is made the order in which they are executed is > unrelated.
Aaahhhhhhhh. Well, that makes a big difference. So, in terms of maintenance, is there any reason to prefer the colocation/order approach over the resource set approach? Ideally I would like to be able to add and remove resources using shell scripts. --Eric Disclaimer - March 26, 2013 This email and any files transmitted with it are confidential and intended solely for General Linux-HA mailing list. If you are not the named addressee you should not disseminate, distribute, copy or alter this email. Any views or opinions presented in this email are solely those of the author and might not represent those of Physicians' Managed Care or Physician Select Management. Warning: Although Physicians' Managed Care or Physician Select Management has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments. This disclaimer was added by Policy Patrol: http://www.policypatrol.com/ _______________________________________________ Linux-HA mailing list Linux-HA@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
