Hi Thorn,
I am working on it, most of Fred's work is integrated, I am now merging the new master score code. Ping me back in a week, it should be ready.
Regards,
Yves
You received this message because you are subscribed to a topic in the Google Groups "PRM-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/prm-discuss/XUKhE7QAs30/unsubscribe.
To unsubscribe from this group and all its topics, send an email to prm-discuss...@googlegroups.com.
--
I tried that but no change. Then I tried to simplify things but that didn't help either.
Sorry, by "simplify things" I meant I reassigned everything to a single network (the MM.NN.32.0 network where the replication would normally run).
Yes, I followed the setup guide. And, as I said, replication is working fine. The configuration does have
primitive p_mysql ocf:percona:mysql
By adding the "datadir" parameter to the CIB I was able to get the cluster to start up and start mysql. However, only 2 of the 3 nodes (P2,P3) successfully join the cluster and start replication. Replication is running on all 3 nodes and is caught up but the cluster reports P1 is not accessible, although it also assigns all 3 reader_vips to it. The cluster sees P2 as current master, and P3 agrees, but P1 still sees the master as P3 instead of P2 (which it was earlier) . Manually changing the master on P1 to be P2 is successful, but the cluster still reports P1 p_mysql is not started.
After increasing the "start" timeout from 60 to 120 seconds I am able to get the 3 node cluster running. For a while I was able to connect to reader VIPs. However, now the pattern is that the cluster comes up, briefly shows all reader vips assigned to a single node (the one most recently started), then after about one minute all reader VIPs disappear, and no mysql connection can be made to them. The writer VIP remains intact, and all instances of mysql are running. Testing the readable parameter results in all nodes reporting readable:
Hi Thorn,
At least there's a progress. Please send me the output of 'crm_mon -A1' went the rvips are gone.
Regards,
Yves
--
I forgot to mention that with pacemaker off, replication functions normally with no thread restarts.
On Monday, February 3, 2014 5:56:52 PM UTC-7, Thorn Roby wrote:The cluster runs but continually resets the slave. I'm not sure if this has been happening all along, it's possible I just didn't notice because the status looks OK unless I tail the mysql log, and replication does work (I tested a few inserts) . I'm attaching mysql, corosync and pacemaker logs for the duration of a cycle starting up corosync, then pacemaker, and waiting until the master/slave status is established, then shutting everything down.
--