From MySQL+MMM to MariaDB+Galera Cluster: A High Availability Makeover • Hacker News Board

Re: From MySQL+MMM to MariaDB+Galera Cluster: A High Availability Makeover

#11

Post by jolan » Tue, Sep 24, 2013, 6:15 PM UTC

erevlydeux wrote: post #6

(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 tr…

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

http://www.percona.com/doc/percona-xtradb-cluster/release-no...

Re: From MySQL+MMM to MariaDB+Galera Cluster: A High Availability Makeover

#12

Post by jolan » Tue, Sep 24, 2013, 6:17 PM UTC

nknighthb wrote: post #9

erevlydeux wrote: post #8

Earlier quoted context omitted.

At that rate, I'm curious why Percona XtraDB Cluster (PXC) wasn't in the lineup of considerations.

PXC and MariaDB+Galera are mostly the same code.

I think the only difference is MariaDB has done more work on the query optimizer.

Maria uses Percona's InnoDB patchset (XtraDB).

Both use the galera patch from codership.

I don't think Percona merges anything back from Maria.

Re: From MySQL+MMM to MariaDB+Galera Cluster: A High Availability Makeover

#13

Post by erevlydeux » Tue, Sep 24, 2013, 6:24 PM UTC

jolan wrote: post #11

erevlydeux wrote: post #6

(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 tr…

They just released a socat-based solution a couple days ago: http://www.percona.com/doc/percona-xtradb-cluster/release-no...

Interesting. :)

Re: From MySQL+MMM to MariaDB+Galera Cluster: A High Availability Makeover

#14

Post by nknighthb » Tue, Sep 24, 2013, 6:28 PM UTC

davidjhall wrote: post #7

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?

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...

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.

Re: From MySQL+MMM to MariaDB+Galera Cluster: A High Availability Makeover

#15

Post by klaruz » Tue, Sep 24, 2013, 6:36 PM UTC

nknighthb wrote: post #14

davidjhall wrote: post #7

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?

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... And apparently they require a minimum of six nodes. And the supported installation met…

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

Re: From MySQL+MMM to MariaDB+Galera Cluster: A High Availability Makeover

#16

Post by nknighthb » Tue, Sep 24, 2013, 6:49 PM UTC

klaruz wrote: post #15

nknighthb wrote: post #14

Earlier quoted context omitted.

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... And apparently they require a minimum of six nodes. And the supported installation met…

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

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.

Re: From MySQL+MMM to MariaDB+Galera Cluster: A High Availability Makeover

#17

Post by nknighthb » Tue, Sep 24, 2013, 6:55 PM UTC

jolan wrote: post #12

nknighthb wrote: post #9

Earlier quoted context omitted.

PXC and MariaDB+Galera are mostly the same code.

I think the only difference is MariaDB has done more work on the query optimizer. Maria uses Percona's InnoDB patchset (XtraDB). Both use the galera patch from codership. I don't think Percona merges anything back from Maria.

I'm under the vague impression Percona's codebase has some additional patches involving backup and management that haven't been pulled into MariaDB, but I might be mistaken. Obviously there's also simple release cycle lag.

Re: From MySQL+MMM to MariaDB+Galera Cluster: A High Availability Makeover

#18

Post by druiid » Tue, Sep 24, 2013, 7:43 PM UTC

nknighthb wrote: post #17

jolan wrote: post #12

Earlier quoted context omitted.

I think the only difference is MariaDB has done more work on the query optimizer. Maria uses Percona's InnoDB patchset (XtraDB). Both use the galera patch from codership. I don't think Percona merges anything back from Maria.

I'm under the vague impression Percona's codebase has some additional patches involving backup and management that haven't been pulled into MariaDB, but I might be mistaken. Obviously there's also simple release cycle lag.

The percona tools are mostly outside the direct mysql environment and more on the innodb or linux end of things. I'm not personally aware of any that rely on codebase changes.

Re: From MySQL+MMM to MariaDB+Galera Cluster: A High Availability Makeover

#19

Post by kplawver » Tue, Sep 24, 2013, 8:48 PM UTC

davidjhall wrote: post #7

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?

(I helped write the piece)

I went with MariaDB because of the features in MariaDB - because the goal wasn't just to improve availability, but to speed up queries, and the improvements MariaDB's made to complex queries and indexing made that decision easy when compared to Percona Server or MySQL Cluster.

Re: From MySQL+MMM to MariaDB+Galera Cluster: A High Availability Makeover

#20

Post by crazygringo » Tue, Sep 24, 2013, 8:53 PM UTC

ck2 wrote: post #2

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.…

I agree it's not great, and annoying in theory.

But if you use file-per-table, I've never actually had a problem in practice, since in production, most tables tend to only grow. And even if you remove half the rows of a large table, you're probably expecting that space to be reclaimed eventually.

If, on the other hand, you do a big restructuring where you're deleting 90% of your rows in one big swoop... then it's probably actually easier and faster to just create a new table and copy the 10% valid rows into it, then drop the old table, and rename. All space reclaimed.

It's definitely something annoying to have to keep in mind, and it's why I prefer to use MyISAM when doing big data manipulation on my local dev machine (everything's faster without transactions too). But using InnoDB in production, I've found the never-shrinking-table-files to be a nonissue.

Curious if anyone else has had different experiences.