On 2010-02-26 10:45, Marian Marinov wrote: >>> I believe that every slave in the cluster must be able to become a >>> master. And because of that I don't think the RA should have any part in >>> the decision making process. This way, if you want to have any >>> preference, you will be able to set it up within the CRM using >>> constrains. >>> >> Nope. That won't do. You _must_ cater for the fact that the master might >> die, as IMHO it's unacceptable to then keep the MySQL setup running, by >> default, without a master. You at least have to make automatic failover >> to the "next best" slave _possible_, and then leave it to the admin's >> discretion whether they use that capability or not. Pacemaker has all >> the infrastructure in place to allow for this via its master preference >> logic, it's just up to the RA to actually use that infrastructure. :) > > For me the master preference is clear, if you have only two nodes, it will be > the other node. If you have more, then you have to connect to all nodes > within > the cluster and collect information as to which node has the most recent > master_log and position. If more then one node is with the same log and > position then you choose the first.
People will want to use this functionality primarily for scale-out. So you should assume multi-node by default. In a 2-node cluster, you just slap MySQL on DRBD and are done. And, asking around _when the master dies_ is a really poor approach. You can, however, do something along the lines of: * Current master always has the highest master preference (let's call that X, say, 10000 or so) * Every slave sets its own master preference to X-Y, where Y is a measure of "how far behind" it is behind the master. Take a look at the ocf:linbit:drbd RA to see how this can be done. Now, when the master dies, * Any "fully caught up" slave can take over immediately, as it has the same master pref as the old master that just died. Pacemaker will promote it, your promote and notify implementations do the rest. * When no fully caught up slaves are available, the least behind gets the highest master pref, and it becomes the new master. > However I think that this would be a little bit of overhead. But if want, I > can implement this tonight. Really, the only thing that you need to figure out is how you calculate Y. That's the hard part. Adding a configurable RA parameter to initially set X is the real easy part, and updating the master preference is something you can add to the monitor op with minimal hassle. crm_master is your friend. Dejan or Andrew will of course correct me if what I suggest is totally off the mark. :) Let us know what you think. Cheers, Florian
signature.asc
Description: OpenPGP digital signature
_______________________________________________________ Linux-HA-Dev: [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
