On Friday 26 February 2010 09:55:40 Florian Haas wrote: > 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. :) >
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. However I think that this would be a little bit of overhead. But if want, I can implement this tonight. Regards, Marian > > 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 > -- Best regards, Marian Marinov
signature.asc
Description: This is a digitally signed message part.
_______________________________________________________ Linux-HA-Dev: [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
