On 2010-02-25 07:48, Marian Marinov wrote: > On Thursday 25 February 2010 04:38:16 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 >> 2. I have added the ocf_is_ms function to the .ocf-shellfuncs and so I used >> it in this version of the patch >> 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. >> 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. >> > I'm sorry, I forgot to write about the master...
And I overlooked it. :) Apologies on my part. > 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. :) > One requirement that I didn't mention was that the replication_user should be > existing on all machines within the cluster and should have not only > REPLICATION SLAVE but also REPLICATION CLIENT privileges. The idea is that > every slave will connect to the master so it can setup the its replication > all > by its self. That sounds fine to me. It would be helpful to include that in the longdesc for the replication_user RA parameter, though, so it can get pulled into the generated docs and man pages. 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/
