xen dev blog

ok we're on 1.5.5a now

it was just one character in the phrases.xml which was fucking with the character encoding even after converting the table to utf8

will make a start on the things I had actually intended to do today after a shower

 

I did actually keep working yesterday despite not posting more: There were some ongoing issues with cluster configuration (running out of memory I think) and also the 1.5.5a update replicating correctly. Cleaned those up and appears to be working now.

Moes has been stress testing the system and we've identified a lot of cluster deadlocks. I'm looking into installing an SQL load balancer today (or some other solution) to sort these out.

 

Fixing new (minor) security issues in current production

 

7.... no 8

 

After Moes stress tests it's clear that the percona cluster has write concurrency issues which the ndbcluster didn't. But ndbcluster required a phenomenal amount of memory and was slower for reads.

Probably going to need to install MariaDB MaxScale to split read and write requests. This will use the cluster as a defacto logical master slave setup to avoid deadlocks. I expect it will work ok.

Unfortunately there really is no manual or chart for setting a xen instance this big up. All of the other large boards using it just trail blazed their own paths. Digitalpoint (who I've followed until now) uses ndbcluster not percona (although they did use percona at one point).

It's good we're finding this out now rather than when we try move production traffic to the new cluster. Props to Moes for doing his job

 

He reported several serious exploits that no one else had found and I needed a bug bounty program lead. Logical choice

 

currently installing and configuring / researching MaxScale

 

I have maxscale installed on one node. Just considering the best way to push forward with it / test it.

It may be that I want to install it on all nodes and use it as a read/write split so that it's transparent for read requests which end up being executed on their originating server (i.e. localhost) but redirecting for write requests which can go to a dedicated write node. Effectively master slave emulation on top of the cluster.

Not the best solution in the world but we have to do something about these deadlocks. Under stress test xen is throwing up about 10,000 a day.

 

I've been on call 24/7 for this site for 10 years

 

Letting in three trusted CDT users to start exploring and writing their guides as soon as DD gets back to me with IPs

 

I have no idea. Also that's another thing that needs to be ported over good god.

Lots of retards write Sythe in the 'who referred you' box on the signup page. Mostly scammers I'd assume.