
From MySQL+MMM to MariaDB+Galera Cluster: A High Availability Makeover - itsderek23
http://blog.scoutapp.com/articles/2013/09/24/from-mysql-mmm-to-mariadb-galera-cluster-a-high-availability-makeover
======
contingencies
Apologies for a slight tangent, but if you _really_ need SQL's structure _and_
you can't shard the data to avoid scaling issues, please let me know what kind
of system you are running because it IMHO has to be pretty weird.

Even in these cases, there are always other potential options, for instance
using query playback with a combination less frequent FS or blockstore layer
provided snapshot functionality.

In practice, in my own experience, generally when people get an SQL based
database to a huge size the often greater issue is that someone has a huge
mess of bad application code relying completely on the current database
configuration that is not time or cost-feasible to modify.

------
erevlydeux
(shameless plug here)

Galera doesn't come out of the box with a secure SST option. SST, or state
snapshot transfer, is how it bootstraps a new/failed node to get it close
enough to continue with regular Galera replication. If you're running on a
public cloud, you might care about secured SST communication. I wrote a drop-
in secure rsync SST option, based on socat, that uses SSL encryption to
seamlessly secure that traffic. Not perfect by any means, but it works without
any futzing around.

[https://github.com/tobz/galera-secure-rsync](https://github.com/tobz/galera-
secure-rsync)

~~~
jolan
They just released a socat-based solution a couple days ago:

[http://www.percona.com/doc/percona-xtradb-cluster/release-
no...](http://www.percona.com/doc/percona-xtradb-cluster/release-
notes/Percona-XtraDB-Cluster-5.5.33-23.7.6.html)

~~~
erevlydeux
Interesting. :)

------
ck2
What I want to know is how people deal with innodb's dirty horrible secret -
how ibdata can grow to infinite massive sizes and can never be reduced, ever.
Regardless if you are using "file per table".

It is a ten year old bug [1] never addressed, no tools ever made to optimize
it, and the larger your data, the sooner it will come to bite you. Doesn't
matter if you are using mysql, percona or mariadb.

[1]
[http://bugs.mysql.com/bug.php?id=1341](http://bugs.mysql.com/bug.php?id=1341)

~~~
lotsofcows
You want to "defrag" a live database? You're brave. Dump it and rebuild it -
you should be able to do a node at a time.

~~~
ck2
With terabyte sized databases, thousands of tables, not really an option to
dump and reload.

Alter and optimize are already possible on a live innodb table, in theory it
should not be exponentially harder to optimize ibdata.

Note that oracle solved this problem on their commercial database product.

------
davidjhall
Why MariaDB+Galera vs. MySQL Cluster? I read the political decision of Maria
being more robust and non-Oracle, but was MySQL Cluster considered? And if
not, why?

~~~
nknighthb
Dunno about the author here, but when I looked at MySQL Cluster a while back,
it immediately disqualified itself for lacking foreign key support. That's
apparently been newly added in the last few months, but there's still no
shortage of annoying limitations to be had.

[http://dev.mysql.com/doc/refman/5.6/en/mysql-cluster-
limitat...](http://dev.mysql.com/doc/refman/5.6/en/mysql-cluster-
limitations.html)

And apparently they require a minimum of six nodes. And the supported
installation method is a GUI installer. Sounds like typical "enterprise"
Oracle trash, further eroding whatever confidence I might have in it.

~~~
klaruz
That's NDB cluster, not Galera. They are apples and oranges.

~~~
nknighthb
Please re-read the comment I replied to, which was asking why MySQL Cluster
(NDB) would not be considered as an alternative to Galera. Using Galera in
production myself, I'm well aware they are different things.

