On 08/02/2013 05:12 AM, Nathan Neulinger wrote:
I've had good luck with a small deployment on percona as well, though there are a few minor issues (maybe stuff that can be corrected):
1. When FS tries to create indexes on various tables that already exist, it winds up causing a bunch of complaints/failures in the percona logs and creating various GAL_ dump files.
2. The external management of percona can be a mess. I tried running with Pacemaker/Corosync and really didn't have good luck with it failing over the floating IP properly, so I switched things back over to Keepalived, which I'm using for the freeswitch instances.
For the floating IP to follow to the new box, on a *2* node setup, you need to disable quorum and add a constraint in your pacemaker/corosync config so the resource (PerconaDB) follows the floating IP. Something like: $ pcs property set no-quorum-policy=ignore $ pcs constraint colocation add PerconaDB ClusterIP INFINITY $ pcs constraint order ClusterIP then PerconaDB And this example helps to prevent resources to move around when the failed node comes back online. Make sure the 'resource-stickiness' value is higher than the 'prefers' one: $ pcs constraint location PerconaDB prefers node-1=50 $ pcs resource rsc defaults resource-stickiness=100 I'm curious, did you use a shared filesystem (something like DRBD with GFS2/OCFS2) and regular Percona XtraDB on both nodes or did you use Percona XtraDB Cluster? Regards, Patrick