As most of you know, Sun acquired MySQL (and later Oracle acquired Sun), and during these acquisitions, there were a lot of FUD in MySQL community which resulted in creation of various forks.
Today we have MySQL from MySQL, Percona (XtraDB) MySQL, OurDelta MySQL, MariaDB, Drizzle to name a few. Which brings us to the source of the problem.
We are in the process of upgrading our databases (hardware/software) and I would like to know which one of the forks should I go with. Each has their own set of pros/cons. We are currently using MySQL 5.0.x from MySQL/Linux on an 8-core machine. Our new hardware is a monster with 32 cores and 32GB of memory connecting to a fast NetApp Storage via FC.
I would like to stick with MySQL from MySQL but I have heard horror stories on how badly MySQL 5.1 performs on many cores. I have also heard that MySQL 5.4 performs better on multi-core machines but that's still not production ready. In addition, I have also heard a lot of good things about Percona builds.
This is what I know so far:
MySQL 5.1 from MySQL: Reliable choice, but doesn't scale well on a big machine
Percona: Scales well, good backing company. I don't have much experience with it
MariaDB: Don't know much about it besides that it was founded by Original MySQL developers (including Monty)
OurDelta: Don't know much
Drizzle: Mostly optimized for cloud computing
I would like to know what's the general notion about this problem. Which build/version should I go with? How are you guys picking your builds/versions?
Thanks!
All of the 'forks' you mentioned (except Drizzle) re-base off newer official releases of MySQL. I think that the word fork can lead you down the wrong path - since the intention is just to provide after market modifications. I wrote about this here:
http://mtocker.livejournal.com/50931.html
Since they re-base of MySQL, and MySQL 5.0 is in "extended maintenance", only major vulnerabilities are to be fixed. This means you want to be moving to 5.1. If we work with this assumption, then it cuts OurDelta out from your decisions - since they are just the 5.1 MariaDB build/packaging partners.
I think you can also rule out Drizzle, since it is currently pre-beta. They're planning a beta by the end of the summer - but it's still much earlier than what you'll want. I really don't think you use a database not ready for production, so this rules out MySQL 5.5 as well.
So this leaves Percona Server, Official MySQL 5.1 and MariaDB. It's true that 5.1 has some poor scalability with many cores, but if you enable the InnoDB plugin it is better.
The rest of my response from here on in is biased - I work for Percona:
Percona XtraDB has additional CPU scalability fixes than MySQL 5.1+InnoDB plugin. The ones that are going to matter are covered here:
http://www.percona.com/docs/wiki/percona-xtradb:features:start
One I can comment on in particular that will matter is this one:
http://www.percona.com/docs/wiki/percona-xtradb:patch:innodb_split_buf_pool_mutex
Personally, I think that everyone who needs to set up a new MySQL installation today should be using MariaDB. MariaDB is based on the latest MySQL 5.1, actively maintained (including fixes for bugs reported against MySQL) and packages Percona XtraDB / InnoDB plugin.
I don't even know if "fork" accurately describes Maria, since they are committed to keeping up with current releases of MySQL.
In short: MariaDB 5.1 = MySQL 5.1 + Percona XtraDB + additional useful patches + active development and maintenance
Update late 2011- May 2012: I switched from MariaDB to Percona Server to get to MySQL 5.5 but I intend on switching back once the Maria team has a stable 5.5 based release. I think that everyone who needs to set up a new MySQL installation today should be running Percona Server. If you are using SSDs, you *must* run Percona Server.
2013-2018: Happily ran Percona server 5.6 this whole time.
2018: upgraded to Percona server 5.7 and then almost immediately to MySQL 8.0. [ At this point, I am not knowledgable enough to talk about the differences between MySQL 8, Percona Server 5.7 and MariaDB 10 and I can't say why you might want to choose one over the others ]
Use MariaDB. They've just released a version lately. Maria engine is also much better than MyISAM. With opensource project, you go where the founder go.
Just an update on this. We chose to go with Percona and we can't be happier. Percona guys definitely know their stuff and keep up with the new technologies. Just checkout http://www.mysqlperformanceblog.com/ Top notch software plus top notch people and great support, you can't go wrong.
I think it's still too early to write off MySQL entirely. I'm not enthusiastic about Sun/Oracle gaining the reins, but I don't have a clear idea what direction they'll take with it. Regardless, I'd wait another year before seriously thinking of switching to a fork. Time will tell which project has the resources and motivation to survive, or if a fork is even necessary.
Google has a memory library patch out that supposedly improves performance on multi-thread / core mysql installations. Supposedly, the performance bottleneck was in the memory allocation routines, and would manifest itself starting at 4 cores. I'm currently running a dual proc box with 4 cores each, and am having no problems with 5.1.x without the memory library patch.
My biggest suggestion to you would be to install 5.4 and run a benchmark suite against it. If it does the job, go with it. The fragmentation of the various forks does suck, but maybe it will be for the best. At least the founders have money now to fund their own direction... I wouldn't take the advice to follow them blindly though... It took a lot of time and efffort to set up the mysql infrastructure initially, and while it wouldn't hurt to support the team that did it the first time, there is no guarantee they will succeed the second time. So... support them, but don't rely on them until you know you can rely on them.
If you're upgrading your databases anyway, you should consider other FOSS DBMSes, or data management software systems as well, not just MySQL.
For example, if your DB workload is analytics more than transactions, and data is mostly added in batches, you should consider using MonetDB, a columnar DBMSes which is about 1.5-2 orders of magnitude faster than MySQL when doing analytics-only.
Another option is PostgreSQL. It's more transaction-oriented - like MySQL; in fact, they're similar enough to be proper competitors. There are arguments for preferring PostgreSQL and arguments for preferring a MySQL variant.
On DB-engines.com you can find other potentially-relevant DBMSes, FOSS and closed-source/commercial.
Related
I have two questions:
is MySQL 5.7 is old ?
what the best version of mysql for Rails 5.2 ?
Thanks!
No, it is not the latest, but is still supported (up to October 2020, extended support up to October 2023)
best is the one that's compatible and satisfies your requirements (and is supported)
Obviously you'd start new apps with most current one, but unless you desperately need some new feature - do not rush the upgrade.
Prior to upgrading - make sure you're not using any deprecated features (official manual is your friend - https://dev.mysql.com/doc/refman/8.0/en/upgrading.html), have a good tests coverage, performance and error monitoring. Also have your team available during the upgrade, so that you'll have someone to help if something unexpected happens (like an error that did not show up in tests).
Upgrade options:
With a downtime - just make a backup, schedule downtime during usual lowest load time, bring your app down and upgrade server inplace (may take long for large databases, thus not for everyone)
With (hopefully) much less downtime - mysql supports replication to next version (5.7 -> 8.0 in this case) given both servers are GA-releases. You can create a 8.0 slave and make it the master once it is fully in sync. This way you only need to stop database writes during switching servers (heavily depends on your app, but a few minutes of downtime is still an option).
Please forgive my ignorance but I do not have a ton of experience with MySQL. I am a web developer but overall I have pretty much just installed MySQL or spun up an RDS instance, connected to it and everything just works. However I am currently being tasked with creating a complete backup of our primary server (essentially high availability with a load balancer etc). So I thought now might be a good time to change how I haver our MySQL setup to take advantage of having 2 servers. Currently our MySQL lives on our primary servers and that will probably stay that way for now, however my goal with this new setup is to have 2 identical servers, both running the application and both having the exact same MySQL data structure / data. I want to be able to essentially open up the web application on one server, make a change, see it on the other or vica versa.
From my research it looks like what I want is called "Master-Master Replication" however it seems as if this is an older / more outdated approach? Every article I read is from ~2010-2012 and most people say it is depreciated and I should use Percona XtraDB Cluster, MySQL Group Replication, or Galera Cluster etc. I basically have no idea what any of that means and I am looking for the easiest way to get Master-Master type setup working. On top of that even if I wanted to use regular Master-Master replication it seems as if this is something specific to MySQL and not Percona which is what I actually use.
I know plenty about dev ops and can get everything but the MySQL up and running in no time but I would love some insight on the best way to do this. Currently servers are running Centos 7, Percona 5.7, Apache 2.4.
The easiest way to start is to setup a percona xtradb cluster with proxysql.
Percona xtradb cluster handles all the problems that are present in basic MySQL Master-Master Replication.
Both Galera and Percona Xtradb CLuster are same, as they use the same galera plugin, Only that Percona has customized it and added some extra features like in built proxysql( kind of load balancer for database).
Let's clear up one thing first. Percona is MySQL. If a feature is available on Oracle MySQL (the community version is what I am referring to here), then it is also available on Percona. Think of the two like a cake: MySQL is the base "cake" and Percona is the frosting/sprinkles/etc that go on top.
That being said you can absolutely do Master/Master using Percona MySQL. The standard/best practice is to configure this in active/hot-standby. Meaning, do not write to both nodes at the same time. Your application, or your middleware/proxy, must isolate writes to only one node. This will save you insane headaches when/if replication breaks.
ProxySQL is not a Percona product, but we do support it 100%. You can place ProxySQL in front of your M/M and setup the correct query rules to only route to one MySQL.
You are correct that the most modern solution here, and in my opinion, an easier solution, is to set up a 3-node Percona XtraDB Cluster (PXC). Again, Galera MySQL is the "cake" and PXC is all the extras on top. Group Replication is pie (just to continue the analogy.)
We consider a 3-node PXC fronted with ProxySQL to be one of the best HA solutions out there for MySQL. It is still best practice to only write to one node, and utilize the other 2 for read-only queries. If the primary node goes down, each of the other two have an up-to-the-transaction copy of the data. Again, ProxySQL helps route the traffic if primary goes down.
Backups can be taken from any PXC node using Percona XtraBackup in a non-blocking/hot fashion.
I have a java / spring / hibernate app running with connections to a MySQL db.
We recently upgraded from 5.6 to 5.7 (on a Windows server) and the app has gone from taking 3 hours to 3 days to complete. It essentially uses hibernate connections to retrieve read only data from the db before processing it and dumping the result elsewhere.
However as a first step, partly to check it was the upgraded version that is causing the problem, I installed 5.7.21 on my dev machine. I then noticed that even doing a db restore took several hours rather than what used to take about 10 minutes on 5.6. This has lead me to believe it may be more of a config issue than 'drivers' being out of date (I did think my first step was going to be upgrading app dependencies). I didn't install the server but I installed my dev machine with a default 'developer' install. Both the server and the dev machine are 64 bit Windows.
I've had a scoot around for obvious gotchas and not found anything yet. I just wondered if anyone could point me in the right direction before I start seriously thrashing about ? I have a good basic understanding of out of the box MySQL but I haven't done much config so even pointers to likely suspects in my.ini and best ways to investigate would be helpful.
When upgrading, pay attention to innodb_buffer_pool_size variable value.
It controls how much memory MySQL uses to make I/O operations faster. Usually, this is the one that makes it fly or that makes it crawl like a snail. There's a lot to be written about this particular variable, there's a plethora of excellent blog posts about it so I'll avoid explaining it into detail.
To see the current value, type in MySQL terminal:
SHOW VARIABLES LIKE '%innodb_buffer_pool%';
Change the value in config file and restart MySQL.
For the value, don't go overboard, don't exceed your entire RAM. You want it as high as possible, especially for servers with a lot of data.
Does MySql support for cluster environment? Whether Community edition support for clustering?
I want to know more details about it. Please guide me where can I get details?
You can read everything about MySQL Cluster (which is a different version than MySQL Community, but you can get both for free) on the MySQL website:
http://www.mysql.com/products/database/cluster/
MySQL Community edition can be set up to do master-slaves replication, but that's not as cool and effective as what MySQl Cluster can do.
Yes, MySQL Cluster does support clustering. If you have a Amazon EC2 account, I recommend this tool/website for setting up a MySQL Cluster quickly for testing: http://support.severalnines.com/entries/20916823-installing-on-amazon-ec2
MySQL Cluster is apparently the only MySQL solution right now from Oracle (outside of Percona and others) that allows for 99.999% availability (HA).
From my initial tests, MySQL Cluster is really fast at writes, but slightly slower at reads, though it aggressively caches reads after the first read. I'm still studying it myself.
Also, MySQL Cluster community edition should suffice for most use cases. I think the Carrier Grade edition is only for real heavy-duty uses.
You can get straight to the community (GPL) download for MySQL Cluster at http://dev.mysql.com/downloads/cluster/ (or the commercial version from Oracle e-Delivery - the functionality and underlying code base is the same).
An alternative to MySQL Cluster is SchoonerSQL, a cluster based on MySQL but uses the standard InnoDB storage engine rather than NDB. It supports 99.999% availability and has a very simple GUI management console. Go to SchoonerInfoTechcom
I am looking for a hot backup system for mysql databases? I like to ask you for experiences and expertise.
So the place you want to look for good solutions to MySQL issues is Mysql Performance Blog/Percona. Specifically, what you want to do is use their XtraBackup, which fixes a number of issues that occur with InnoDBs hot backup. You'd be well served to use their patched server with their InnoDB replacement XtraDB.
They integrate a number of third party patches for MySQL, including their own and Google's, and have enhanced the InnoDB storage engine with fixes, enhancements and better logging. Additionally, Percona sponsors a fantastic toolbox for MySQL called Maatkit, which gives some components to help you with backups and integrity checks.
I know InnoDB hot backup but works just for InnoDB
http://www.innodb.com/products/hot-backup/
I use the MySQL GUI Administrator Tool. It has a backup tool, which you can use to schedule daily backups through windows. You can create different backup projects, schedule the backups, and control how the backup runs and the type of output file it creates.
I've always found it reliable, and the other tools bundled with it are also useful for basic database administration.