xen dev blog

bad news: cluster with maxscale got butt raped under stress test conditions over night.

looking into it today

 

pretty fed up with this database fuckery at this juncture

seriously considering returning to traditional master slave configuration

 

going to reconfigure the way maxscale is used

I'll put a maxscale instance on each of the two load balancer nodes and make all the connections persistent. Part of the problem is the vast amount of physical memory a single mysql connection uses in percona (even when using conservatively configured buffers). If every node has a maxscale instance which connects to every other node then we use a lot more connections than necessary.

Originally I wanted it so that each maxscale instance makes a simple decision to route the request to localhost if it is a read, or to the variably elected master node if it is a write. However this configuration is not possible, and the aforesaid n-to-n configuration is not desirable. So we will try this third configuration now.

 

I'm adding a haproxy instance to each cluster node so each php instance can connect randomly and reliably to a maxscale instance on the load balancers

everything is really annoyingly complicated when you can't really modify the application you are trying to run (xenforo) for fear of future update-incompaitibility

 

thanks fam updated and gave you one too for cleaning it up

 

new setup seems to be working but only another stress test will tell

 

polishing this setup with some automation

 

looking into posticons and breadcrumbs

 

ye maxscale is fucked & I hate it

not sure what to try next. don't want to ditch cluster if I can avoid it.

thinking

 

trying a master slave addon on top of the cluster as a way of filtering writes to a single node

 

this solution looks like it might actually work

 

so to clarify I've removed maxscale and the haproxy load balancers for the sql nodes (not for the http load balancing though)

we're back to an almost pure cluster, but xen has been patched to redirect its writes to a single 'write-only' node. (Essentially a master.) However the cluster nodes are still all technically writable nodes it's just we're only writing to one in order to avoid deadlocks.

If this doesn't work I'll just remove the cluster altogether and go back to a traditional master slave setup I think.