MySQL 5.7.6 DMR: Packages, Repos, Docker Images

We are getting closer to the next major version of MySQL, and yesterday we announced another development milestone release of what will become MySQL Server 5.7. In addition to the announcement blog post itself, more in-depth posts on specific changes and improvements in the 5.7.6 milestone release will appear on the MySQL Server Team blog over the next few days and weeks.

We have been busy in the packaging, deployment and configuration area for this milestone as well, and we have made several important improvements and changes that we’ll run through in this post.

Goodbye mysql_install_db, Hello mysqld –initialize

The MySQL bootstrap process has always been complex, relying on a Perl (shell in older MySQL versions) script called mysql_install_db to initialize the data directory, set up system tables and create the MySQL root account. This created unnecessary complexity and also required Perl to be available on the database host. As of 5.7.6 mysqld knows how to bootstrap itself, and mysql_install_db has been replaced by the much simpler –initialize option to mysqld. Or alternatively –initialize-insecure. More on the difference between those two options can be found in the section on data directory initialization in the MySQL Server 5.7 manual.

Besides a reduction in general complexity and improved robustness and error reporting, the big gain for packaging and deployment is that server bootstrap is now completely platform agnostic: no dependency on Perl any more, and in particular no need to handle Windows as a special case.

Another implication is that most of the initial configuration of MySQL is now done only with the privileges of the mysql system user. As a consequence, we are no longer able to write the random mysql root password to /root/.mysql_secret, and this now instead gets written to MySQL’s error log.

The father of –initialize, Georgi Kodinov, has a much more in-depth story on this over on the MySQL Server Team blog.

Native systemd Support

Up until this milestone, we used a somewhat suboptimal mix of mysqld_safe, mysqladmin and shell scripting to control mysqld on operating systems with systemd. As of 5.7.6, we have introduced a (platform agnostic) –daemonize option to mysqld, which allows mysqld to run as a traditional, forking UNIX daemon. This allows us to work natively with systemd’s service control and monitoring infrastructure, and the MySQL 5.7 manual has a new section about managing MySQL Server with systemd.

A related change is that we now offer native support for handling MySQL logging through syslog. This appeared in the previous 5.7.5 milestone release.

And Finally: Docker!

So what is the easiest way to try out the 5.7.6 milestone? There are packages on our download site and in our Linux repos, but there is another way that will also easily coexist with any existing MySQL instances that you may already have on your system and that you may not want to disturb: try the MySQL Docker images.

We are currently ramping up our work on Docker, both to help maintain and improve the very popular community supported set of MySQL images on Docker Hub, but also with our own set of images, which we will develop in some new directions and also use as a proving ground for changes and enhancements that we will propose for inclusion in the community images.

You’ll find instructions for pulling and running our images in the MySQL area on Docker Hub. We have 5.5, 5.6 and the latest 5.7 DMR all in there, and the tag that will get you 5.7 is simply “5.7″, or alternatively the more specific “5.7.6″. Add your desired container name and admin password to the following command line and you will be up and running with 5.7.6 in next to no time at all:

docker run --name my-container-name -e MYSQL_ROOT_PASSWORD=my-secret-pw -d mysql/mysql-server:5.7.6

Suggestions, comments, issues? Please comment below, or submit a bug report to the MySQL bug tracker

MySQL Server on SUSE 12

When we launched repos for SUSE Linux 11 back in December, we said we would be adding SUSE 12 support as soon as possible, and we are happy to announce that as of last week the repo offers MySQL Server packages for SUSE 12.

It did take us a little bit of extra time to get this done, since SUSE 12 represents a major technological leap over the previous version. Among the most important changes is the move to systemd as init system, and we wanted to make sure that we support that the right way according to SUSE guidelines (by the way, we have important systemd related improvements coming in MySQL 5.7, so this area will be getting even better.)

Another important improvement is that we now enforce strict validation of metadata signing in the repository, as per the SUSE guidelines. And not least, we worked hard to make sure that our packages work as replacement for whatever MySQL-like variant you may already have on your system. The packages have gone through stringent testing of different possible upgrade flows, and the powerful SUSE package manager will recommend different replacement options for you.

The repo has the latest MySQL Server 5.6 and the latest 5.7 development release for you, and the basic steps that will get you the latest MySQL Server 5.6 are as follows:

Go to the download page for the SUSE repository, click the Download button for the repo setup RPM package and install the package like this:

$ sudo rpm -Uvh mysql-community-release-sles12-2.noarch.rpm

Then import the key that will be used to verify the packages that come from the repo:

$ sudo rpm –import /etc/RPM-GPG-KEY-mysql

And then proceed to install the MySQL Server package from the repo:

$ sudo zypper install mysql-community-server

If you want the source rpm, enable the source subrepository you want, e.g. for MySQL 5.6:

zypper modifyrepo -e mysql56-community-source

And then proceed to install the MySQL source package from the repo:

zypper source-install  -D mysql-community-server

Alternatively, you can get source rpms manually from

And as usual, if you have general comments, leave them in the comments section here, and if you have concrete feature request or come across issues with using our packages and/or the repo in general, please submit a bug report.

Heads up: Going 100% GitHub at the End of January

Hi, all. Just a quick note to let you all know that we completed the move of MySQL Server development from Bazaar to Git some time ago.

This means that as of the upcoming, end of January batch of Server releases (5.6.23 and 5.5.42), our official source code hosting moves from Launchpad to GitHub. The Launchpad site for MySQL Server will continue to be available for some time, but 5.6.22 and 5.5.41 were the last releases to have their source code posted there.

Unfortunately, as we warned earlier, this also means that we will need to break the history of our GitHub repo. Until now, that repo has been a Git conversion of our Launchpad repo, and when we switch to publishing from our new internal Git repo, history breaks. So if you have cloned our repo, you will need to do so again and merge any changes in your old clone to the new one. Sorry for that inconvenience, but there is really no way around it.

So, in a few weeks, the place to go will be See you all there!

Open Source Collaboration: This is how we did it ‘together’ !

It was not long before when we all were discussing to meet in person during UDS. We did not have good enough reasons to get the logistics mobilized back then but over time we realized the vibrant MySQL Ecosystem on Debian and Ubuntu needs a brainstorming session. While we did try Google Hangout as the first option it appeared a lot more obvious to meet in person. I would appreciate how nicely Robie and James from Canonical took in the first step to host the complete MySQL community directly in touch with them for packaging various MySQL variants.

Finally, it was decided that we meet in the second week of December (8-12), 2014 to find solutions to the unique problem faced by these Linux Distros. Over time Debian and Ubuntu have seen collaboration and attendance like never before from the individual stakeholders willing to maintain their MySQL variant in the Distro backed software repositories. The increased interest also brought with it the technical challenges to allow choice amongst one of the many MySQL variants in the most meaningful way possible.

All of us namely, Me (Akhil) and Norvald from Oracle, George from Percona and Otto an independent maintainer for MariaDB agreed to meet at the Canonical’s London Office. We at Oracle have been referring this event for long as the “Canonical Sprint”. It is about time we take this name out in open as it quite aptly represents Canonical’s interest to enable maximum choices for its users.

Just because each one of us agreed to work in tandem with each other, it did not mean all was achieved. It is not so straight forward to get all the MySQL variants working seamlessly with each other allowing users to make a choice at their own pace and test a variant as they decide to use. Moreover, along with the packages it is also important that users  are allowed to make sustainable transition of configuration and data across variants when they decide to make a switch. All of this needed careful analysis of various use cases and also a well defined process that we can get implemented for changing variants in real time.

At the sprint not only did we get the packaging right for us to hit the ambitious target but we also worked on side projects listed below:

  • Got rid of the legacy packaging source not applicable any more,
  • Enabled systemd service for Debian,
  • Started using dep8 testing for the packages,
  • Established parallel builds and parallel MTR test runs to reduce development and build time.
  • Baselined common work processes and repositories to collaborate.

A lot was achieved over the week and lot more is yet to come in following months. We are looking forward to Ubutnu 15.04 which will be a great release for users of MySQL Ecosystem on Ubuntu. Thanks Canonical for hosting us all together and giving us a platform to achieve and demonstrate a kind of collaboration that has never taken shape before. Glad to be part of this sprint. Finally, towards end of the week here is one of the many happy outcomes from the event:

Canonical Sprint Team
Here we are (left to right): James (Canonical), Norvald (MySQL), George (Percona), Akhil (MySQL), Otto (independently maintains MariaDB) and Robie (Canonical).                  Graphic Courtesy: George.


Official MySQL Repos for SUSE Linux

Since we launched the official MySQL repos for Linux a little over a year ago, the offering has grown steadily. Starting off with support for the Yum based family of Red Hat/Fedora/Oracle Linux, we added Apt repos for Debian and Ubuntu in late spring, and throughout all of this, we have been continuously adding more and more MySQL products to each of these repos.

The one glaring exception so far has been the SUSE Linux family. So today we are launching official MySQL repos for SUSE Linux. We’re starting out with:

  • MySQL Server 5.5 (old GA version)
  • MySQL Server 5.6 (the current GA series)
  • MySQL Server 5.7 (development series)

… all for SUSE Linux Enterprise 11 (11.3 and newer).

Getting started

The basic steps that will get you the latest MySQL Server 5.6 are as follows:

Go to the download page for the SUSE repository and click the Download button for the repo setup RPM package. Then install the package like this:

$ sudo rpm -Uvh mysql-community-release-sles11-5.noarch.rpm

Then import the key that will be used to verify the packages that come from the repo:

$ sudo rpm --import /etc/RPM-GPG-KEY-mysql

And then proceed to install the MySQL Server package from the repo:

$ sudo zypper install mysql-community-server

Much more information, including how to select the Server major version and how to upgrade a pre-existing MySQL on your SUSE system, is available in the MySQL Server docs at


What’s next?

The initial SUSE repo offering is limited to MySQL Server and only one SUSE variant. We will be adding more products (connectors, utilities etc.) over the coming few months, and openSUSE packages are on the horizon. Regarding SUSE Linux Enterprise 12, SUSE unfortunately chose to not provide users with a mature and robust version of MySQL as part of the distro, and we are working hard to bring that option as quickly as possible to those who want to use MySQL on SLE 12.

And finally, the usual disclaimer. Nothing in this world is perfect: if you have comments or suggestions for improvements, please let us know in a comment here, or if you run into issues using our packages and repos, please take the time to submit a bug report.

MySQL on GitHub

Today MySQL is officially joining the GitHub community, with the launch of a beta GitHub repo for MySQL Server.

Why We’re Doing It

GitHub has become the place to be for successful open source projects; it has a large and rapidly growing user base, it is robust and fast, and it provides excellent tools for building and supporting vibrant open source communities. All this, plus the fact that lots of projects that are built on top of MySQL source code are on Github, meant that the choice was pretty obvious for us when we started looking for a new code hosting service.

This also means that we are switching our day to day development activities to use Git. The MySQL org is highly distributed, with many developers working from home and others working out of Oracle offices in almost every corner of the world, so it was a given that we needed a distributed version control system. Another requirement was that the system we chose had to have a large and active community around it; as we all know so very well, a large, competent and enthusiastic user base, coupled with openness, tend to make a system much more flexible, robust and better performing. Git fits the bill very well, with good performance, lots of useful tooling from the large community of Git users and a boatload of features that will make MySQL developers’ lives easier.

How to Get Started

Want to get stuck in?

The home of MySQL on GitHub is at, and here are the basics of using the repo:

Cloning over http: 
$ git clone 
Over the native Git protocol (requires SSH key on the GitHub server): 
$ git clone 
(The download size is ~ 410 MB)
Available branches: 
$ git branch -r 
origin/HEAD -> origin/5.7 
Checkout of MySQL 5.6: 
$ git checkout 5.6 

You can find a lot more in depth information in GitHub’s excellent documentation.

So, What Does ‘Beta’ Mean?

It means that we may change things around on GitHub for a while still, so we encourage everyone to exercise a little bit of care.

Switching source code management system is a significant change for any development project. When you have hundreds of developers and contributors, lots of surrounding infrastructure for build, test and publication of source code and binaries, with processes to coordinate all of this, and when halting development for any period of time is an absolute no-go, the scope and complexity of change becomes huge.

This means that we are not quite done yet with our switch to Git. So the code we are publishing on GitHub now is an export from our existing Bazaar source code repo. That will change when we switch development to Git; at that point our GitHub repo will become a copy of our internal development Git repo. When we do that switchover we will have to break continuity, so that if you have created your own forked MySQL repo before the switch, you will be unable to pull code updates to that repo after the switch. You will have to fork again, export your commit history from your old fork and apply that to your new fork. We will of course make sure to give a heads up when that switchover point approaches.

So the “beta” label should be taken to mean that the MySQL repo on GitHub is a correct and fully usable Git repo, but we do reserve the right to tweak and tune things for a little while, and at some point in the near future, when we go out of beta, we will need to break continuity.


A basic question we expect to see from the GitHub community is “How do I contribute back?” For some projects, it is a simple matter of issuing a pull request to ask the upstream project to review and possibly merge in the changes you are contributing. In our case, we need to ask for a little bit more. The MySQL Server Team blog has a good step by step guide for those who want to contribute, and we encourage those who are interested to head over there for more information.

We will look for ways to better connect our contribution process with our presence on GitHub, and if you have suggestions, please let us know in the comments section below. For now, we promise to make sure that pull requests get a response with information on how to contribute “the right way”.

Let me end this posting by saying that we really hope that our presence on GitHub will be useful to everyone with an interest in our code, whether for their own development or simply as a way to keep up with the rapid pace of MySQL development in general. I would also like to thank the GitHub team for welcoming us into the fold, in particular Sam Lambert, who has been a very helpful guide along the way.

And if you have suggestions for how we can optimize our usage of GitHub, or if you should encounter issues with the repo, please let us know in the comments section.

Happy hacking!

Testing MySQL repository packages: how we make sure they work for you

Around nine months ago, we launched the MySQL yum repositories for Enterprise Linux and Fedora, followed by apt repos for Debian and Ubuntu back in May. We’re extremely happy that the repos have proved to be a big hit with the community: the monthly number of downloads hit 100K recently and it is still growing briskly. Indeed, the repos are now our most important community distribution channel for the MySQL product family on these platforms.

Right from the outset, it was clear that a thorough QA regime would be very important. The yum and apt projects involved a complete rearchitecting of our rpm and deb packaging, we expected the repos to become very popular, and not least: a key aspect of the repo distribution model is immediacy. If you release broken packages through your repos, lots of users are going to be hit by problems very quickly. So we made very sure that QA was placed front and center of the repo projects.

In this posting, we will describe the way we currently test MySQL packages that go into the repos. We will focus on the newest MySQL releases (5.6.20 and 5.5.39, both coming very shortly), and the most recently added platform, namely Enterprise Linux 7. The principles and overall approach are very similar between the yum and apt repos, while the specific test scope and types of install scenarios we test vary between different MySQL versions and OS flavors.

Objectives and strategy

Boiling down the motivation for our repo QA efforts to a few bullet points, this is what we get:

  • Provide users with overall high quality packages
  • MySQL is a core system component: our packages must not break the system in any way
  • Make sure we completely replace the distro native “mysql” without breaking compatibility
  • Make sure that distro native third party applications that depend on MySQL continue to work properly
  • Build and maintain user confidence in the official MySQL repos

The repository testing takes as its input a set of packages that comes from our continuous integration build and test system. The main focus is on testing the packaging, as opposed to the package contents; most of the testing of the product itself happens in a separate, parallel QA process. The entire process is applied for each and every maintenance release of MySQL.

The overall scope of testing covers numerous scenarios involving installation and upgrade, including verification of the resulting installs, and testing to make sure that third party applications that depend on MySQL work as expected. This is also the point where our chosen example becomes particularly interesting: as we have highlighted previously, Red Hat chose to ship an older, forked version of MySQL natively in EL7, and this meant we had to add some new testing scenarios in this latest round in order to make sure we got things right.

Scope and approach

Here is an overview of the different categories of repository package testing we do and the scenarios we cover, specifically for MySQL on EL7:

Installation testing

  • We install the following mysql community packages: mysql-community-bench, mysql-community-client, mysql-community-common, mysql-community-devel, mysql-community-embedded, mysql-community-embedded-devel, mysql-community-libs, mysql-community-server, mysql-community-test packages, all at once.
  • After installation, we validate that we have a running service, we connect to it, we verify plugins, do version checks and check mysql system tables, information_schema tables etc. in order to ensure that we have a valid install.
  • We test multilib support to ensure that users can run 32 bit applications with 64 bit MySQL packages.
  • We do individual package installation in order to ensure that the correct dependencies get installed automatically. E.g. the mysql-community-server package depends on mysql-community-client, mysql-community-common and mysql-community-libs.

Upgrade testing

As part of upgrade testing, we cover a number of different upgrade flows: upgrades between different server releases from the MySQL repo; upgrade from distro native packages to MySQL repo packages; upgrade from older MySQL repo packages to new ones, and finally that none of these three upgrade types break multilib support.

Let us take a more detailed look at each of these flows:

Upgrades between MySQL release series in the MySQL repo

As we have multiple MySQL major release series (5.5, 5.6 and 5.7) in the repository, we cover relevant upgrade flows between these releases in order to ensure that all the packages we deliver are compatible with each other:

mysql55-community → mysql56-community
mysql56-community → mysql57-community
mysql55-community → mysql57-community

Upgrade from distro native to MySQL repo with different MySQL versions

Here we test upgrade or replacement of native distro packages with real MySQL packages in order to ensure that nothing breaks. Example: EL7 comes with MariaDB 5.5.35 by default, we want to offer users a move to the real MySQL from MariaDB without any compatibility issues, so we thoroughly test upgrades from the distro native MariaDB to the different MySQL versions that we offer from the MySQL repo:

mariadb5.5.35 → mysql55-community
mariadb5.5.35 → mysql56-community

We verify and validate the upgrade process with various checks like monitoring information_schema and mysql database tables, installing plugins, verifying already installed plugins, defined users, running mysql_secure_installation, doing storage engine and version checks etc.

Upgrade from “old style” MySQL rpms to repo rpms with different MySQL versions

As we mentioned above, the repository rpms represent a deep rearchitecting of our “old style” rpms. We continue to support the old style packages, but we also give users a choice to “upgrade” to the repo style ones and thus simplify future upgrades and administration. To make sure this works seamlessly, we test all relevant version combinations of old style rpms and yum repo rpms (note: for EL7 there are no legacy old style packages, so this scenario does not apply there)

Upgrade from older to new MySQL packages in the MySQL repo

It is critically important that we don’t break the chain of upgradability between what we have delivered already and what we are delivering. This means that we need to test upgrades from older MySQL versions in the repo to new versions. For MySQL 5.6.20 and 5.5.39, this means:

mysql55-community(e.g. 5.5.38) → mysql55-community(e.g. 5.5.39)
mysql55-community(e.g. 5.5.38) → mysql56-community(e.g. 5.6.20)
mysql56-community(e.g. 5.6.19) → mysql56-community(e.g. 5.6.20)

(The precise combinations above will of course vary with the actual server versions in the repository at any given time)

Upgrade between 32 bit and 64 bit packages

We offer multilib support in our repo packages, meaning that users can install 32 bit and 64 bit packages side by side on a 64 bit system. In this testing we cover installation of individual 32 bit packages and verify that those still exist on the system after installing all 64 bit packages.

Third party application dependency testing

Most distros come with many third party applications which internally depend on some MySQL-like client, libraries or server being available on the system. Our testing in this area aims to ensure that dependent applications continue to work correctly after a user installs the real MySQL.

A good test strategy often involves reducing the number of combinations to be tested to a workable set, so we have been identifying three different dependency patterns and one  or more third party MySQL-dependent applications for each of these. We then check that these applications are unaffected by the installation.

These are the dependency patterns and their representative applications:

  • applications that depend on client and libs: dpm-name-server-mysql
  • applications that depend on libs: mysql-connector-odbc,mysql++
  • applications that depend on devel and libs: mysql++-devel

Overview of test scenarios and combinations

Here is the detailed test specification matrix for 5.6.20 repository package testing:

Test Scripts
Installnew server packages within repository like 5.5/5.6/5.7OracleMySQL_only
UpgradeUpgrade from native to current repository with different server version packages. Upgrade from native mariadb to 5.5.39. Upgrade from native mariadb to 5.6.20MariaDB_OracleMySQL
Upgrade between the server packages within same repository5.5.39_5.6.20-mysql-mysql
Upgrade from server packages in public repository to current repository5.5.39_5.6.20-public_mysql-mysql
Upgrade from regular rpms to current repository with different Server version packagesNo EL7 regular rpms available
Upgrade between 32 bit<-->64 bit packages within same server version or installing oracle mysql packages after every individual package Installation from the same repository of same server version but different architecture5.6.20_32bit_5.6.20_64bit_EL7
Upgrade between 32-bit<-->64-bit packages wrt native packages and oracle mysql packages update or installing oracle mysql packages after every individual package installation from native repo (mariadb) with 32-bit<--64-bit variations5.5.35maria_32_5.6.20_32_EL7
3rd party depApplications depending on:
client and libs-->dpm-name-server-mysql
libs-->mysql-connector-odbc, mysql++
devel and libs-->mysql++-devel

So, what is it good for?

For an activity such as this, a key metric will always be cost versus benefit. The QA regime we describe in this posting is resource consuming, both in terms of initial investment and ongoing test development and execution for each release, and careful management of test scope and intense automation is important in order to keep especially the recurring execution costs down.

So, has it been worth it so far? The answer is a resounding “yes”, and we have data points to back that up. First and foremost, in spite of well over half a million downloads and a steady stream of new releases, the number of community reported issues has been very low. Of course, that doesn’t mean that we haven’t seen any issues, just that we tend to catch them before release. Here are a few bugs encountered during the 5.6.20 / 5.5.39 test cycle. Please note that this was the first test cycle run on the final GA version of EL7, so some issues were indeed expected:

  • MySQL bug #73073: update to community-server fails if mariadb-galera-server already installed
  • MySQL bug #73113: yum update fails when community repo enabled and mariadb-embedded-devel installed
  • MySQL bug #73194: 5.5 packages failed to install after installing mysql-bench from native repo

What’s next?

As the distro landscape develops and changes, our packages and our testing regime need to change as well. An example is the evolution of EL7: Red Hat made a number of big MySQL related packaging changes beginning with the EL7 beta version they released back in December 2013, to the release candidate in April and finally to the GA that appeared some weeks ago. For each of these milestones, we adjusted and expanded our testing in order to make sure that our packages worked as they should.

Going forward, we will of course continue to adapt to any changes. We will also continue to pursue efficiency by investing in more automation. In particular, we will add more automatic validation points at different stages of the install and upgrade process, we will enhance the system for test triggering and we will hook everything into our automated test reporting system. This should all hopefully allow us to spend even more time to ensure that we follow the distros closely and in general that we test the right things as thoroughly as possible.

And finally, we’d be delighted to hear your comments, questions and thoughts on all this. Ping us in the comments section!


This article was jointly authored by Ramana Yeruva and Yngve Svendsen from the MySQL Engineering team. We would also like to thank the MySQL Repository Project team for helpful suggestions and for valuable QA of the article contents.

They’re Here: Official MySQL Repos for Debian and Ubuntu

As we’ve hinted at for some time now, we have been busy preparing some good stuff for our Debian and Ubuntu users. And today we’re delighted to launch our own official MySQL apt repos for Debian and Ubuntu.

After working closely with the Debian and Ubuntu communities to make sure that the native MySQL packages in those distros work really well, we have now taken all the valuable knowledge and experience gained from that work and applied it to our own official packages.

We have support for Debian 7 and Ubuntu 12.04 and 14.04, and we initially offer MySQL Server 5.6 plus the latest 5.7 development milestone release. 5.6 is what we recommend for production use, while milestone releases are for those who want a taste of the absolutely latest. We will be adding more products in the near future.

So why are we doing this?

First and foremost, we want to provide officially supported, very high quality MySQL packages that integrate well with the distros, from easy-to-use repos that will always contain the latest and greatest; while distros typically choose one specific version of MySQL to include, we can offer several different versions, including development releases, from our repos. We think this is a nice complement to the good MySQL stuff that ships natively with the distros.

Second, running our own repos keeps us better hooked into what the community, and especially the different Linux distros, want and need from us. As part of our apt repo work, we’ve seen how we need to improve important stuff such as our startup scripts and config file handling in order to make life easier both for ourselves and for the Linux distro package maintainers. Going forward, we will continue to listen closely to what our users and our friends in the distros tell us, so that whether or not you use the native distro packages or our official repos, you will have a good and smooth experience.

What took us so long?

Well, learning takes time, and we wanted to begin by giving the distros full attention before we started work on our own stuff. And this is indeed complex stuff, with a huge matrix of possible migration paths and upgrades from distro packages, other vendors’ packages and our own old debs, all in multiple possible configurations, versions and editions.

When we put the “official” stamp on something it means that we have put a lot of time and effort into design and implementation and not least testing in order to make sure that things work as expected and that users have as smooth an experience as possible (there is a good blog posting on some of this over on the MySQL Server Team blog). We’ll hopefully at some point have a blog posting telling the story of how we translated that huge matrix into actual testing, but take my word for it: QA has been burning the midnight oil on this project.

Finally, while starting to use our repo will be very straightforward for probably 90% of our users, we have put together in-depth documentation that covers those few cases where the move requires a bit more care.

Want to get started?

Head over to the APT repo download page to get the setup package, install instructions and pointers to more in-depth docs.

There are a few minor limitations in these initial packages, where a tiny handful of distro native applications are incompatible with our repo packages. The docs have more details on this. We believe that this will affect very few users, but we will look at fixes for later revisions.

What’s next?

Over time, we will add more products to our repos and we will continue to improve the user experience. We will also continue to work closely with the Debian and Ubuntu maintainers and communities to make sure that we are doing the right things and that the native distro packages get even better in the future.

And finally, nothing in this world is perfect: if you have comments or suggestions for improvements, please let us know in a comment here, or if you run into issues using our packages and repos, please take the time to submit a bug report.

Congratulations, Ubuntu!

Today, we congratulate our friends at Ubuntu on a great new release, Ubuntu 14.04 LTS. As you can see in Mark Shuttleworth’s posting on Google+ from a few weeks back, MySQL has been cooperating closely with the Debian and Ubuntu communities to make sure that MySQL works very well on these platforms, and Ubuntu 14.04 bears the first fruits of those efforts.

Out of the gates, Ubuntu 14.04 comes with MySQL 5.5.35 as default, while 5.6.16 is available in the Ubuntu Universe repository. So whatever your MySQL preference – the mature and battle hardened 5.5 or the newer, richer and better performing 5.6 – Ubuntu 14.04 has what you need.

Going forward, Ubuntu is set to offer a great MySQL experience. Traditionally, Linux distros have tended to stay with a specific version of key components such as MySQL for a long time in order to avoid hitting possible issues introduced in newer versions. However, Ubuntu has recently introduced an approval process that will allow “trusted” software to get updated more often, and MySQL is now on that list of trusted products. Basically, Ubuntu has reviewed our development and QA processes and policies and concluded that upgrading to new versions of MySQL can be assumed to be safe. For Ubuntu users, this means that the distro repos should always have a recent version of MySQL available.

With 14.04 out and about, we really look forward to continuing our fruitful collaboration with the Debian and Ubuntu communities. We want to get MySQL 5.6 into Debian stable soon, and we think it would be natural to roll over to 5.6 as the default MySQL in Ubuntu 14.10. And we have some other good stuff in store for Debian and Ubuntu users pretty soon…

Repos and Distros: Upstream and Downstream

When we launched the official MySQL repos back in October, we wanted to achieve a number of things:

First, we closed a gaping hole in our distribution on Linux. Some Linux distros do not ship all the MySQL products, and not everyone is able to or always wants to use the distro packages. And the distros naturally focus on stable releases, while some users want to test development releases from us. Second, this represented a good opportunity to get off our behinds and finally modernize our Linux packaging. And last, but definitely not least, we would put ourselves in the same position as those valuable volunteers that take our products and integrate and maintain them in the Linux distros.

When you’re upstream, you can easily lapse into a mode where you stop listening properly to those who sit downstream and have to process what you’re releasing. There will always be some amount of difference in priorities and opinions between upstream and downstream, but putting ourselves downstream and in that sense having to “eat our own dogfood” turned out to be very educational and highly useful.

This change in perspective made it easier for us to understand many of the important pain points of the distros. It quickly became clear to us that a good deal of those pain points could be fairly easily addressed, and in some of the more difficult cases, the folks involved in the repo project have acted as lobbyists internally in order to have Engineering priorities changed so we could fix some of the bigger things.

Below, I will go into some more detail on what we are doing and what we have accomplished in the Debian and Ubuntu communities, let me first just say that we hope that we are being considered useful citizens in the different distro communities, and that distro maintainers of MySQL products see us an approachable and responsive upstream. And if we aren’t, let us know!

Debian and Ubuntu

Over the last couple of weeks, we have seen our new experience and efforts bearing fruit in Debian and Ubuntu. Since late fall last year, release engineers and developers from the MySQL team have been working with the Debian and Ubuntu community to bring MySQL 5.6 into both distros. Two weeks ago, Ubuntu bug #1256931 (“please include MySQL 5.6″) got closed, and as you can see from the package status, 5.6 is now headed for Ubuntu 14.04 LTS, Trusty Tahr.

Hot on the heels of the Ubuntu news came the inclusion of 5.6 in Debian experimental. We do believe that the current packages are quite solid, and we will continue to work closely with the Debian community to deal with any reported issues and in general refine things so that 5.6 can go into Debian testing soon.

Working with the Debian and Ubuntu folks has been an absolute pleasure, and at the risk of leaving out someone, I will say a heartfelt thanks to Robie Basak, Björn Boschman, Clint Byrum, Dustin Kirkland and James Page, and to our very own Akhil Mohan and Norvald Ryeng for their hard work.

Maintenance and Updates

And now that we have 5.6 in Ubuntu, how will it get maintained there? MySQL maintenance releases come out on a bi-monthly schedule, containing fixes for important bugs reported by the community, by customers and by our own developers. This is not a perfect match for Linux distros, where the approach has historically been to select a specific MySQL release to go into a new major release of the distro. Subsequent maintenance has largely consisted of the distro maintainer fixing reported issues or security bugs by either backporting from later MySQL releases or implementing their own fixes.

There are many good reasons for this approach, and a key one is trust. If a distro maintainer were to update the distro packages more or less in sync with upstream releases (for MySQL, “upstream” is us), he or she would have to be able to trust that upstream doesn’t invite trouble by introducing risky bug fixes or new features in maintenance releases, that upgrades and forward compatibility don’t break, and that upstream in general has development and QA processes in place to prevent any surprises in new releases.

We are happy to say that we have earned that trust in Ubuntu. Earlier this month, MySQL was granted a so-called “micro release exception”, which means that new MySQL maintenance releases should appear on a regular basis in Ubuntu going forward. The relevant mail thread is on the Ubuntu tech board mailing list, and you can read much more about MySQL’s maintenance release process in an excellent post over on the MySQL Server Team blog.

What’s Next?

Right now, we’re taking all the experience and knowledge we have gathered while working with and in the Debian and Ubuntu community and applying that to our own debs. The current debs were in much need of some love, and we’ll have some very good news for our Debian and Ubuntu users in a little while.

In parallel with that, we are continuing the work to further refine the current repo packages, add more platforms and more products to the official MySQL repos, and in the process also try to reach out to distro maintainers of the same products to make sure we understand what life downstream is like. And we will continue to work with distros in areas beyond packaging.

Requests, ideas, thoughts on our packaging efforts? Anything else we should be doing together with the distros? Let us know in a comment!