Inuits Day

Kris Buytaert — Mon, 21 Jun 2010 19:14:12 +0000

Couple of Fridays ago we had one of our @Inuits days again. Rather than having some people give talks and presentations about what they have been doing for the past couple of months this time we set out to research, test, and build stuff.

We split up in 3 different groups, one focusing on CI and testing freshly build stuff with cucumber, a second one setup and tested Galera

We setup a 3 node Galera cluster , not really as smooth as we'd like to ..

Our first bump was that the installation of the package on CentOS is hell, it needs manual interaction such as replacing packages. Deploying this from a repository is probably not going to be a straight forward option.

Galera only takes care of replicating data, just as with MySQL MM replication there still is a need for an external tool to define where to access the database, and implement monitoring in such a way that you are connecting to an up to date database.

Karl started wondering about Galera's locking, turns out the locks aren't cluster wide, locks within the same node work fine.. so if galera is solely used for HA with 1 active node and X failover nodes, it will work (so all transactions happening on 1 node).

We also ran into some issues when trying to start a node which couldn't contact the wsrep_cluster_address point (which is a node it will sync from at startup if specified in the wsrep.cnf file) , it just didn't want to start. This means that when the referenced node (configured in wsrep_cluster_address)is down, you will need to comment it out before you are able to start the mysql server.

The fact that Galera replicates everythying brought us to the discussion if we really wanted that , or if we wanted more finegrained control over which databases or even tables we want to replicate and which ones we didn't want to replicate. A minority of people wanted to replicate everything, the majority of our group wanted finere grained control over what is being replicated to another node.

I`m sure Lefred will shortly be writing about the progress his group made on Banquise

The day ended as it should .. with BBQ and plenty of drinks

To not yum or to not apt-get, that's NOT the question.

Kris Buytaert — Tue, 16 Feb 2010 20:13:33 +0000

Over at the OPenARK blog Shlomi Noach argues that using apt-get or yum to install your MySQL instance will one day most likeley break your MySQL setup. Depdendencies, distros not shipping the MySQL version you want to use and on some distro's indeed the mysql vs MySQL issue, agreed, it all makes things less trivial.

However why give up a clean packaged system if there are other ways out ?

First of all by claiming that such an installation can break a working production environment looks to me like admitting you don't have a split development, production environment and that rather than testing stuff upfront indeed you just hack a long in production.

So rather than using a tarball for the MySQL instance an --force to satisfy the missing dependencies (hence also cluttering your system) , a much cleaner and less error prone setup is to only deploy from your own , self controlled repository , in which you only allow tested packages, most probably not the distro based package , hence packages that won't break your setups ;) But still you will be using apt or yum and deploying rpm's and debs , perfectly satisfying dependency needs.

Apart from that .. watch out for Banquise .. :) Coming to your favourite distro soon..

Everything is a Freaking DNS problem - banquise

Inuits Day

To not yum or to not apt-get, that's NOT the question.