On 02/25/2010 03:38 AM, Marian Marinov wrote: > Hello, > again thanks for the comments. In this version of the patch I tried to fix > all > mentioned problems. > > However there are a few things: > > 1. the whitespaces after the HOSTNAME should remain since this is how are the > unames exported to the RA
Seriously? Then it's not your business to fix that, those environment variables must be set correctly. Andrew, can you confirm? > 2. I have added the ocf_is_ms function to the .ocf-shellfuncs and so I used > it > in this version of the patch I'll push that one with a minor change. > 3. I use IPs for mysql replication since this way I skip the resolving. We > had > a lot of problems with admins on our clusters. So this solved a bunch of > problems caused by wrong entries in resolv.conf and/or nsswitch.conf. It is clearly not the RA's job to "fix" a faulty resolver configuration, and _certainly_ not through a kludge like grepping /etc/hosts. Please, throw this out. > 4. I haven't thought about the SSL/TLS connections. I have to setup one > first. > I think it will be best to get the cert information from show variables. I > will add this functionality later, it seams easy to implement. > 5. Keep in mind that during promotion of one MySQL server all others should > execute demote even if they are already slaves. This is because all slaves > should be reconfigured or reconnected to the master. I found that this is not > how heartbeat behaves. So what I did was to add mysql_demote to the > mysql_notify stage. This is why I got the extra checks in the demote function. Firstly, please, it's not Heartbeat that does any of this, it's Pacemaker. Secondly, your logic is flawed there. What you want to do, IMHO, is this: * promote operation: - Unset read-only mode. - Pacemaker will take care of notifying the slaves of the new master * demote operation: - essentially a no-op. During demote, you may not have a clue which box is the new master, in fact there may not be one in the cluster at all if the admin just typed in "crm resource demote <your_ms_resource>. So there's no point in reconfiguring a master as a slave during a demote. The only thing you may want to to is set it to read-only mode. * notify operation: - post-promote: you've just been informed of the new master. STOP SLAVE, SET MASTER TO, START SLAVE. - post-demote: you've just been informed that there currently is no master. STOP SLAVE. Keep running in read-only mode. * start operation: - Just like in a standalone MySQL resource, except that you set read-only mode. Also, may I remind you of my question how you're going to calculate your master preference scores? 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/
