We're using in production on Amazon Web Services, in multiple
availability zones in a single region. Been running since the beginning
of the year with 1.1 and no issues thus far.
There's no issues with restoring a dump created from a Galera server
into standard MySQL. I *think* you could have a standard MySQL server as
a slave of one of the Galera servers, as a warm standby, although I've
not actually tested this.
Regards,
--
Sam Bashton, Director: Bashton Ltd
Bashton: Business Focussed Open Source
Building highly scalable Linux systems since 2004
www.bashton.com | 0161-424-9600 | DDI 0161-424-9611
We are yet to actually run it in production, but yes, I am
recommending it for production usage. I benchmarked the 0.8 version
for 5 weeks last Summer without a crash or issue. I'm also more
confident in Galera not screwing up data integrity compared to other
commonly used solutions like MySQL replicaiton - and I find the
management more pleasant.
> Does anyone have experience, running such a cluster
> on a virtualized environment, VMware for example?
Haven't yet. I don't really see an issue, other than things that could
be said about standalone MySQL in a VM too.
> What is the worst-case scenario when using galera? The plan is to run
> daily full dumps and activating binary logging to have the
> possibility, to restore the database on a native mysql server in case
> of troubles.
Sounds like a good idea. Notice that the binary log is only useful
together with a backup taken from the same node, and the node must not
have been subject to a full state snapshot after the backup.
henrik
--
henri...@avoinelama.fi
+358-40-8211286 skype: henrik.ingo irc: hingo
www.openlife.cc
My LinkedIn profile: http://www.linkedin.com/profile/view?id=9522559
Yep, done that.
We're using HAProxy on each client. No reason you couldn't use an F5 if
you've got one lying around, but it'd be hard to justify the expenditure
for this use only.
For backups, we run an extra galera server that we use for mysql dump at
30minute intervals.
HA PROXY <===> 3x galera (r/w) ----> galera (r) (backup only)
Are you actively participating/monitoring also bugs reported in relation
to Percona mysql server?
Are these planned to be included resolved in upcoming 2.0 release?
https://bugs.launchpad.net/percona-xtradb-cluster
kind regards
Haris
--
--
Haris Zukanovic
Hi Haris,
All of those bugs (except lp:917837, which is Percona-specific) are
mapped to either MySQL-wsrep or Galera projects. And if I'm not mistaken
they are all fixed already in Codership trees (so yes, they will be
included in 2.0). The process is then such that Percona pulls fixes from
Codership repos and applies them to their code base.
Regards,
Alex
-- -- Haris Zukanovic
HAProxy also supports layer 7 checks, albeit in a slightly hacky way
because you have to return HTTP content.
I can't reproduce the script we use in production because it does some
specific checks for that implementation, but we took the following blog
post as 'inspiration':
http://www.alexwilliams.ca/blog/2009/08/10/using-haproxy-for-mysql-failover-and-redundancy/
We actually use a Python script, started via upstart to ensure if it dies for
some reason it gets restarted.
Anyway, if your hardware load balancer can do layer 7 mysql checks it
seems like it might be simpler to just use that, and IMO simpler is
better in 99% of cases :)
Yes, I'd say that would be the only purpose of making backups of Galera
cluster. And it works like with a standalone mysql: all Galera nodes are
identical. You backuped one - you backuped them all. You restored table
to one - you restored it to all.
I didn't mean to say that it is not an important use case. I just
wanted to point out that Galera cluster is supposed to give you enough
redundancy against hardware or software failures (in a sense you have
synchronous binlogging to other nodes already), so the focus of taking
backups is somewhat different.
>> And yes, you'd better wait for 2.0 ;)
> It won't be long until, right? :)
Yes, yes, we're just squashing the regressions. Meanwhile you can try
2.0beta - just to have a feel.
Regards,
Alex
Heh, we're software developers and, ironically, have little use for
MySQL clusters. We practice with gcc and gdb. ;)
Seriously, most of experience that we have comes from our internal
testing, and that one is rather synthetic (to be efficient in hitting
problems) and obviously it is in no way comparable to using cluster in
production. Moreover, users whom we know to use Galera in production
have such different use cases and requirements, that we can't derive
much from there.
What I can say for certain, is that any user-space load balancer at
least doubles client connection latency, and usually it is even worse.
And client connection latency is so bad for SQL performance, that
sometimes it is impossible to saturate 16 core server to more than 400%
with sysbench no matter how many connections you use. (It is most likely
a bug in sysbench, but still). In short, the client network can easily
be your bottleneck and whatever you can do to make it faster, you should
do.
> Does glb fit best with a galera cluster?
GLB was written for our testing purposes, so the main requirement for
it was performance. So it is rather primitive feature-wise and, most
importantly, we didn't have much feedback about it in production.
> I've read a lot about haproxy and mysql loadbalancing and I'm not
> very optimistic but let's see.
HAProxy is rather popular, and I guess that's its main advantage -
there are volumes of proven track records.
> Actually, the test setup is running
> behind a physical loadbalancer, which works pretty fine since it
> natively supports layer 7 mysql checks (e.g. running a simple query
> every x seconds), which is a huge advantage compared to haproxy.
As I said before, I would not even consider anything else had I had a
HW load balancer. You obviously have a LAN cluster there, cluster
partition with preserved client connectivity is next to impossible
there, so even layer 7 checks are not of much importance.
In any case, you could write a simple notification script that changes
balancer's routing table in response to node leaving primary component.
This is way better than layer 7 polling.
Regards,
Alex
Exactly. You should not forget to enable log_slave_updates though.
> Does the binary log affect the overall performance of the cluster
> somehow?
Well, it obviously does, but it is impossible to foretell by how much.
Since for PITR, you don't need to sync or flush it, it should not be
much.
Regards,
Alex
This one is much much better:
WSSREP_STATUS=`/usr/bin/mysql --host=$MYSQL_HOST --user=
$MYSQL_USERNAME --password=$MYSQL_PASSWORD -e "show status like
'wsrep_local_state';" | awk '{if (NR!=1){print $2}}' 2>/dev/null`