MySQL Room for Improvement

Patryk Golabek
CTO/Software Architect at Translucent Computing Inc
As for what can be improved, right now we don't use the MySQL cluster. There is a MySQL cluster that you can run in a standalone mode, like a single database or you can do it in a cluster master-slave implementation. The cluster is not the best when it comes to MySQL. That's why we switched to MariaDB. For that simple reason that the cluster there is better. It's more manageable and it's easier to work with. We decide what to use depending on the needs. For example, if we need to mount something in a cluster mode, we use MariaDB, which again, is a Dockerized solution with a Helm chart as well, and it's very easy for us to deploy and manage, and also to scale when you just increase the number of slave versions. So MySQL doesn't have that great support when it comes to clusters. You can definitely use MySQL for that too, both support clustering, but the MariaDB is better. Additional features that I would like to see included in the next release of this solution include better support for backups. Because if you go with the MySQL Percona version, it gives you the tools to back it up securely. The vanilla version of MySQL doesn't have that. It actually does have it, but it is just really poorly executed. I would improve the backup system as well as the encryption. To make it smoother right now takes too much work. It should be a little bit smoother to backup the encrypted data the way you want it and have the ability to push it anywhere you want. That is not part of it right now. Now it is a database, so you don't know what you're going to do with it. It's difficult. You're just going to come up with solutions. But I think you can generalize here and come up with really simple solutions, which we have already in MySQL. That's probably the one thing that I would try and push right now for people to switch. But people are still not biting, because if you go with the managed version, then all the backups are taken care of for you by Amazon or Google or Microsoft. Then you really don't care. But for us, since we're doing it locally, self-hosted, we would like to have better tools for locking up the data. Right now, one aspect that is also linked to backups is running things in a crosscheck with semi-managed solutions. This requires a bit of a context. Since we're running things within the clustered communities, we're kind of pushing the Cloud into the cluster. We also want to push some of the tools for the database into a cluster, as well. So these are what we call Kubernetes operators. And there's MySQL operators that were first developed by the community. Those kind give you the ability to backup data within the cluster. So now you have a fully managed solution running from your cluster. These are called MySQL Kubernetes operators. We are looking into those right now to upgrade our solution, which would mean that we can just execute our backup natively within Kubernetes, not via special scripts. This would make it much easier to actually deal with any kind of MySQL issues within the cluster, because it would be cluster-native. That's what the operators are for. I think Oracle just created a really good one. It surprised me that they have this. It's not because of Oracle, but they got pushed by the community and actually created the MySQL Operator for Kubernetes, and that's what we're moving towards. This is going to give you an ability to have a cloud-managed solution within the cluster. And then you can ask the MySQL Operator for the database. They'll partition the database and give it to you. So it will change the nature from you deploying it to you just asking the cluster to give you a database. It's a fully managed solution right from the cluster. So that's what we're heavily looking into right now. We'll be switching to using Kubernetes MySQL Operators. It's a high-availability cluster running within the Kubernetes cluster. Right now we're pretty good with that. It's working fine. We're trying to find some time to actually release that globally everywhere. That's where I am right now. But in terms of technology, if you give up Oracle, you just go to a MySQL operator. That's the one we're using, what we're actually looking at - to create, operate and scale mySQL and sell it within the cluster. This idea of having a cognitive MySQL becomes much easier to manage within the cluster, as well. So you don't have to go with the cloud solution with AWS or Google cloud or Amazon MySQL or the Microsoft version. The Oracle SuperCluster is the Oracle MySQL operator. That's what we we are looking into a lot right now. Mainly because it does backups on demand - it's so easy to backup. You can just tell Kubernetes to backup and you don't have to run special scripts or special extra software or codes to back it up. You can make the backup as you would do anything else. Send a backup or some other data source or insert an Elasticsearch into it here. Just say "Kubernetes, back it up" and you know Oracle has this adapters within the cluster to back it up for you taking increments or different companies. So that makes it really nice and easy to use and to deploy. With that kind of solution you can ask to class or petition the database how you want. So again, it changed the nature of the kind of push-to-pull second nature system. Are you pushing your containers to a cluster? You just say cluster, "give me a database" and the class gives you the base partition database, creates a database in a secure manner, gives the connection to the database, and you're done. Then you can back it up on a schedule on to any backup switches. It's much easier. So once this goes, it is going to be widely adopted, which it should be. But I think people might not have the tech skills right now. But once it's adaptive, maybe in a few more months, it's going to be the number one solution for everybody. In terms of what I'd like to see in the next release, one thing that's always missing is dash boarding. There's no real BI tool for MySQL, like there is in Yellowfin and all the different tools that you get. They all have MySQL connectors, but there's no specific BI tool for MySQL. Open source projects have sprung up, but they're more general purpose, like Postgress, a MySQL kind of database, a relational database. I don't see any really nice tool like Cabana for elastic searches that I can tell clients to use because it would be too technical for them. They would have to have more technical engagement with writing the course, drag and drop, and creating a graph like in Power BI where you just connect with DIA. So I'd like to see the grab and drag and drop tables, nice beautiful graphics, and pie charts. You don't necessarily have that with MySQL like you have other solutions, which are really cost prohibitive for some clients. It'd be nice to have an open source solution for that. Decent solutions. I mean decent that I can take to clients. It's so technical. They want to drag and drop. View full review »
Database Engineer at L Brands, Inc.
The developers of MySQL, which are Oracle MySQL, Percona, and MariaDB, seem to not be focusing much on object-oriented replication. Basically, replication is based on a text level of replication. There is a text level replication in Oracle, that is so similar it can be implemented in MySQL, however, it needs to pull a lot of resources. They have altered their approach for replication. Still, more focus on object-oriented replication would be good. They should come up with a better solution than the NDB cluster for better scaling. If they could come up with a better solution for write scaling, apart from the NDB cluster, which is supported by all open source communities, that would be great. Although the NDB cluster, I believe, is an open-source tool, it's not widely supported as a solution. My understanding is there are a lot of features in MySQL 8.0, the latest release, which I'm not too familiar with yet. View full review »
CCO at a construction company with 11-50 employees
The replication needs improvement. It's becoming a native cloud product like Oracle DB or Cockroach DB. View full review »
Learn what your peers think about MySQL. Get advice and tips from experienced pros sharing their opinions. Updated: April 2020.
431,790 professionals have used our research since 2012.
Grégory Tabourin
Infrastructure Platform Engineer at a cloud provider with 51-200 employees
We haven't noticed and features that are lacking. From a user perspective, the initial setup could be simplified a bit. View full review »
Partner at a tech services company with 51-200 employees
* I think a better front end would be a better solution (web application front end, similar to what Red Hat is doing to Fedora). * Another nice solution for MySQL clustering would be the use of Webmin. * Also, security measures could always be improved, and the clustering process could be enhanced as well. I recommend using UFW, iptables, and firewalld. View full review »
Business Intelligence Manager at a translation and localization position with 501-1,000 employees
What it would compare it to, from my point of view would be, Microsoft SQL Studio. I find the Microsoft solution a bit better. But mostly in terms of the UI layout, I would say. I just find it a little bit more efficient. But to be honest, I can work equally as well with both. View full review »
George Otako
CEO at OS Labs
We would like to see more security. View full review »
Manzeel Uprety
Co-Founder at Mero Reading Room
The only service which could be improved is its usability. The entire user experience needs to be revamped to meet the 2018 design standards. View full review »
Learn what your peers think about MySQL. Get advice and tips from experienced pros sharing their opinions. Updated: April 2020.
431,790 professionals have used our research since 2012.