On Wed, Mar 27, 2013 at 8:23 AM, Robinson, Eric <[email protected]> wrote: >> On Wed, Mar 27, 2013 at 6:12 AM, Robinson, Eric >> <[email protected]> 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.
That would probably be one reason to prefer the non-set approach. > > --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 > [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
