Upgrading to MySQL 5.7 Using the MySQL Repos for Linux

MySQL Server 5.7 was released around a month ago, and download numbers show huge interest in upgrading from older MySQL releases. As with any product that is frequently used as core infrastructure in complex systems with numerous interdependencies, major version upgrades of MySQL should be approached with some care. In this post, I will cover an essential part of such an upgrade, namely the mechanics of using the MySQL repos to do the actual upgrade. I will focus on upgrades from 5.6 to 5.7, and given the large number of ways that users may have tweaked their repo setups, I will limit myself to discussing scenarios that should cover the vast majority of cases. But first some general words about the business of upgrading to a new MySQL major version.

We’re in general applying a principle of least surprise wherever we can in product design and behavior, and that very much directs what should happen when a new MySQL major version comes out and you have an older version of MySQL installed from our repos: an apt-get upgrade should absolutely not silently and suddenly do a major version upgrade. While we have gone to great lengths in both development and testing to make sure that major version upgrades are as uneventful as possible, a new version will always behave somewhat differently, so some care needs to be exercised when upgrading, in particular where MySQL is used as a component in a large and complex infrastructure.

In short: a major version upgrade has to be a conscious decision.

If you’re using the MySQL package repos for Linux, once you have analyzed what an upgrade will mean for your setup, especially the Before You Begin section, plus taken the highly recommended precaution of backing up your database, the likelihood is that upgrading from MySQL 5.6 to 5.7 is largely a matter of upgrading the repo setup package and selecting 5.7. We will go through a few of the scenarios that you may encounter, and I will start off by covering the Debian/Ubuntu Apt repos.

You Have MySQL 5.6 from the MySQL Apt Repo on Ubuntu/Debian

I will assume that you originally installed the repo setup package from the Apt repo web page. See the note below if you chose the somewhat less recommended route of manually adding the MySQL repo to your system. Also note that the procedure discussed holds for those who have been using MySQL 5.7 pre-release versions, so called Development Milestone Releases.

The first step is always to make sure that you have the latest version both of the MySQL repo setup package and of MySQL 5.6 itself. Run apt-get update, then apt-get upgrade. If upgrades are offered for mysql-apt-config or for any of the MySQL Server bits (mysql-*), choose to upgrade them.

Depending on the initial update state of your system, the apt-get upgrade process may prompt you for the version of MySQL you want. Select 5.7. If you do not get this prompt, force a reconfiguration by using the command dpkg-reconfigure mysql-apt-config, then select 5.7.

You should now have a repo setup that has 5.7 selected as the desired MySQL version, and your system is ready for upgrade. Again, run apt-get update, then apt-get upgrade. You should now see another batch of MySQL Server package upgrades being offered. Accept the upgrades and you should soon have a running MySQL 5.7 install on your system.

And finally you need to run the mysql_upgrade command so that data and system internal structures get transformed to the MySQL 5.7 format.

NOTE: If you didn’t originally download the repo setup package and instead opted for manually editing the repo setup on your system, we recommend that you download and install the Apt repo setup package. Alternatively, you will have to manually edit your system’s repo setup again in order to enable 5.7.

You Have MySQL 5.6 from the MySQL Yum Repo on Enterprise Linux/Fedora

Again, I am assuming that you originally set up the MySQL repo on your system by using the repo setup package from the Yum repo web page.

To upgrade from 5.6 to 5.7 on a Yum-based system you will need to edit the /etc/yum.repos.d/mysql-community.repo MySQL repo setup file on your system to specify 5.7 as the desired version. Open the file for editing and locate the [mysql56-community] section. Change the “enabled” setting in that section to 0, then locate the [mysql57-community] and change the “enabled” setting to 1.

Then proceed to carry out the upgrade:

yum update mysql-community-server

… or if you’re using dnf:

dnf --refresh upgrade mysql-community-server

Your system now has MySQL 5.7 installed and running.

Finally, run the mysql_upgrade command to automatically transform data and system internal structures to the format used by MySQL 5.7.

Other Scenarios

Your system may conceivably be in a state where the procedures above won’t work “out of the box”, but we have hopefully covered the vast majority of cases. If you need more information, I strongly recommend consulting the MySQL Reference Manual, specifically the Upgrading MySQL section.

Another type of scenario is on systems where you want to upgrade to 5.7 from versions older than 5.6. The supported procedure for that is to upgrade via each intermediate version, so e.g. moving from 5.5 is a two step process: first follow the relevant procedure for your system above to upgrade to 5.6, then repeat that procedure to go from 5.6 to 5.7. To go to 5.7 from even older versions, please refer to the upgrade section of the reference manual.

Final Notes

We have gone through the most common scenarios for upgrading to MySQL 5.7 using the MySQL repos for Linux. For future versions of MySQL we will aim to improve the robustness of the repo setup package so that we can handle more scenarios with less manual intervention. That is of course subject to the limitations of the Apt and Yum/Dnf package managers, but some improvements are definitely possible.

If this posting whetted your appetite for 5.7, there is a lot more information available about the release at the MySQL Server blog, and for those who prefer a shorter summary, we have a terse list of new features over at http://www.thecompletelistoffeatures.com/.

In the meantime, if you encounter issues with upgrading that you think are related to the way our repos and packages work, please file a bug report at http://bugs.mysql.com under the category “MySQL Package Repos and Docker Images”.

MySQL Package Verification: Making sure we always ship correct, complete and installable packages

What is MySQL Package Verification?

Package verification (Pkgver for short) refers to black box testing of MySQL packages across all supported platforms and across different MySQL versions. In Pkgver, packages are tested in order to ensure that the basic user experience is as it should be, focusing on installation, initial startup and rudimentary functionality. When tests are written, we put ourselves into the role of the user and write tests accordingly. This involves checks for sanity and correctness of contents, installability and smoke testing. The MySQL user manual constitutes the underlying reference guide to write the tests, since this manual is the one that most users will follow.


MySQL has an ever growing test suite that performs regression tests on the MySQL code, testing old and new functionality. Our dedicated Quality Assurance (QA) teams do additional in-depth testing with main focus on verifying functional and non-functional (e.g. performance, high volume, stress, upgrade/downgrade etc.) characteristics of the product once it is up and running. What is needed in addition is testing to ensure that the initial and basic steps of getting up and running can be accomplished with the product packages we ship. And that is what Package verification does.

Objective and Scope

The basic objective of Pkgver is to make sure that the user can get MySQL up and running.

The Pkgver suite runs on MySQL versions 5.5, 5.6, 5.7, and what will eventually become 5.8, and on Cluster 7.2, 7.3 and 7.4 on several OS flavors and versions. It runs on release branches in our continuous integration test system, on weekly-trunk (where development builds happen on weekly basis) and on certain Worklog branches (where feature development happens, and where packaging and basic functionality may be involved.)


The Pkgver test suite attempts to install the relevant MySQL package, start the server, run some sanity and functionality tests, then uninstall and report if there are any issues.

Pkgver testing consists of the following phases:

Pkgver Flow

The Pkgver Testing Environments

Pkgver testing is done in chroot environments (MySQL 5.5 and 5.6) or in dedicated Virtualbox VMs (5.7 onwards).


This involves creation and maintenance of chroot images that mimic a clean system as closely as possible, except for the addition of the minimal set of files/libraries/executables required for doing the testing, all tied together with some Python scripts.

During a Pkgver test run, the chroot image corresponding to the package/platform in consideration is extracted, the Pkgver process then enters the chroot jail, executes the tests and reports success/failure.

During the course of automating the tests using chroot environments, we realized that this approach has some drawbacks:

  • As the product evolves, so do its dependencies, and the chroot image needs to keep up. So we got into a constant race to keep the chroot environments updated. Chroot maintenance is cumbersome; even keeping OS patch levels reasonable requires significant work, so our Pkgver work over time became more about fixing chroots than adding or automating new tests.
  • Often, if the environment is found to be missing something in the chroot image of one particular platform, the same is the case for the images of other platforms as well. So the effort required by the item above often gets a sizable multiplier due to the wide range of platforms we support.
  • It is also a problem that a chroot is only a very weakly isolated system. It shares e.g. ports and other facilities with the underlying host OS; this causes issues with Pkgver testing from time to time, and those issues can be quite hard to track down.
  • Our introduction of systemd support caused issues: Service commands available with el7 and related newer platforms do not get executed in chroot enviroments (https://bugzilla.redhat.com/show_bug.cgi?id=1110675). Inside a chroot jail, you simply get the following response to a service mysqld start:
    $ service mysqld start
    Redirecting to /bin/systemctl start mysqld.service
    Running in chroot, ignoring request.

Virtual machines on the other hand give you much stronger isolation and the option of using regular system maintenance tools to keep images up to date. Hence the decision to replace chroots with Virtualbox VMs as our testing environment, and we are now using VMs to test 5.7+ packages.

Virtual machines

For MySQL 5.7 and above VMs now form the basic infrastructure for Package verification. For each Pkgver run, we create a new VM instance, start the VM, run Pkgver on it, get the results and destroy it. By creating a new VM instance for every Pkgver run, we ensure that we have a clean and pristine environment during testing.

Overview of Test Scenarios

The tests are performed in phases as follows:

Phase I – INSTALL: Install MySQL package

Test 1:

  • For .deb, run `dpkg -i <pkg-name>`
  • For .tar.gz, unpack the tarball, symlink to ‘mysql’, and run mysql_install_db to initialize database(for MySQL >= 5.7.6, run mysqld –initialize)
  • For RPM, it’s rpm -Uvh(in case of new-style RPMs, it is `yum localinstall`)
  • For Solaris .pkg file, it’s pkgadd,
  • For .msi, do a batch install (using msiexec command line)
  • For MySQL version >= 5.6, this test also grabs the random password either from .mysql_secret file or mysqld error log(in case of MySQL version >= 5.7.7) and sets a new password.

Phase II – post-INSTALL: Perform post-installation checks

Test 2: Find .la Files

  • Checks if there are any .la files present in the package and reports error if they are present.

Test 3: Check Standard Plugins in Package

  • Checks that the standard plugins are present in the package.

Test 4: Check package dependencies

  • Ensures that the package does not have unwanted dependencies. This test is implemented only for RPMs. Specifically, the package should not depend on Intel icc runtime libraries like libimf, libipr, etc. (https://bugs.mysql.com/bug.php?id=16662)

Test 5: Contains ChangeLog

  • Ensures that the ChangeLog exists and has the correct content.

Test 6: Contains errmsg files

  • Ensures that errmsg file (errmsg.sys) exists and is in the correct location.

Test 7: Contains include directory

  • Ensures that the include directory exists and contains mysql.h.

Test 8: Contains libraries

  • Ensures that relevant libraries exist (libmysqlclient.a in Unix and debug/mysqlclient.lib in Windows) and are in the correct location.

Test 9: Contains debug binaries

  • Ensures that the mysqld-debug binary exists.

Test 10: mysqld has debugging symbols

  • Ensure that mysqld and mysqld-debug are not stripped.

Test 11: Check mandatory common plugins in 5.6+ packages

  • Checks that the mandatory plugin validate_password.so/.dll is present in both commercial and community 5.6+ packages.

Test 12: Check permissions of files/binaries/libraries in 5.7.6+ packages on Unix platforms

  • Verifies that the permissions of files/binaries/libraries are correct as per WL5608/WL8129. This test is not applicable to Windows.

Test 13: Check permissions and ownership of the data directory and its contents in 5.7.6+ packages

  • Verifies that the data directory has mysql:mysql ownership and permissions as per WL5608 (750 for dir and 640 for files).
  • This test is applicable for new-style RPMs and DEBs only.
  • NB: RPMs have data dir permissions of 755.

Test 14: Check package signature

  • This test is applicable to OS X DMG only.
  •  Verifies that the DMG has the correct Oracle Certificate.


Test 15: Perform server start

Phase IV – post-START SERVER: Performs post-start checks

Test 16: Smoke Test – Nuke & Restart

  • Kills the mysqld process and verifies that the mysqld_safe process triggers a new mysqld process. Else errors out.

Test 17: Smoke Test – Version Variables

  • Displays version variables.

Test 18: Smoke Test – Check HELP Contents

  • An arbitrary test of the server’s HELP contents – checks if HELP SELECT mentions GROUP BY.

Test 19: Smoke Test – Simple MySQL Test

  • Runs commands for creation of a dummy database, a table, insertion of data, display of rows and dropping of the table and database. These commands are run for the MyISAM, Memory and InnoDB engines.

Test 20: Check that the mysql user is unable to login on 5.7.6+

  • Verifies that the mysql user has /bin/false as its default shell.
  • This test is applicable for new-style RPMs and DEBs only(WL5608).

Test 21: Check the value of the secure_file_priv variable and data export/import functionality

  • Checks that the secure_file_priv variable has the correct path of the mysql-files directory.
  • Verifies that the export/import of data happens correctly.
  • This is implemented in 5.7.6+ packages, as a part of WL6782.

Test 22: Check that dtrace is enabled in the package

  • This test is implemented for OS X DMG and Solaris 11 as of now.
  • Runs 2 tests, viz:
    1. Using PID provider, checks if MySQL probes are present.
    2. Verifies MySQL query and connection probes by running specific D scripts. This is to check that mysql providers are present in the package.



  • Tests server stop.



  • Uninstalls the package.


We will keep adding new tests as new Worklogs that affect the functionality that Pkgver verifies get implemented. We will also be porting Pkgver to new OSes that get added to our list of supported platforms, and we will of course make sure that any future packaging related issue that may arise gets the headstone that every bug deserves: a new regression test in the test suite.

And finally, if you have viewpoints, comments or suggestions for improvements, please let us know in a comment below.

MySQL User Camp, Bangalore – 26th June, 2015

MySQL User Camp Bangalore, organized on 26th June, 2015, was a huge success with an excellent turnout of 49 attendees. We got many users from different companies, like Flipkart, Snapdeal, CTS, Capgemini, Yahoo, VMware, HCL, Datavail, Bosch, Rakuten and more.

The event started on time with a welcome speech by Balasubramanian Kandasamy, (Principal Member Technical Staff, MySQL Release Engineering). He welcomed all the attendees, followed by a brief agenda and introduction of the attendees.

Mahesh Patil (from Rakuten, a MySQL community member) presented on MySQL Tools Usage in Rakuten and Overview of Replication GTIDs. He provided a good summary on the MySQL Tools usage in Rakuten with snapshot of inbuilt tools and how the replication GTIDs are used.

Mahesh Patil

Key points from the presentation

  • Different MySQL built-in tools used in Rakuten
  • Usage of replication GITDs

We had a quick MySQL quiz before the second presentation and some goodies were distributed in the audience.

The next presentation was on “MySQL Software Repositories” by Akhil Mohan, (Software Engineer, MySQL Release Engineering). It was followed by a demonstration of Apt repository configuration and upgrading from the MySQL 5.5 available in the distro native repos of Ubuntu 14.04 to the latest version of MySQL 5.6 available in the official MySQL software repositories. We got good feedback from users on the MySQL repos.

Akhil Mohan

Key points from the presentation

  • DevOps at MySQL
  • Different MySQL repos (Apt/Yum/SUSE)
  • Docker (currently in beta)
  • Demonstration of the Apt repo configuration.

The final presentation was on “Ansible for large scale MySQL deployment” by PR Karthik, (MySQL DBA, Yahoo). Good overview of how Ansible can be of great value in the context of large scale MySQL deployment.

PR Karthik

Key points from the presentation

  • Ansible installation and configuration
  • Using Ansible for configuration management across multiple installations of MySQL

Later, we had an open talk session where the users interacted with MySQL engineers from different teams.

Feedback from attendees:

We had great responses from the attendees. There were some requests for presentations on MySQL new features and replication in the next meetup, and we will definitely take that into consideration.

For more information follow us on:

Facebook Group : MySQL User Camp

Google Group : bangalore-mysql-user-camp

LinkedIn Group : MySQL India

Fedora 22 is out, and we’re ready

Fedora 22 arrived yesterday. With a cutting edge GCC (5.1), the new DNF package management system, and improved tooling for server administration, we congratulate the Fedora community on yet another innovative release.

We’re following up from our side, and as of yesterday our repos offer Fedora 22 packages of these products:

  • MySQL Server 5.6 (currently 5.6.24) and 5.7 (currently 5.7.7). The latter one is the latest 5.7 Development Milestone Release.
  • Connector ODBC 5.3.4
  • Connector Python 2.0.4
  • Utilities 1.5.4

We also have MySQL Workbench for Fedora 22 wending its way through QA. Keep an eye out for it in a week or two.

Head over to the Linux repo page on dev.mysql.com (the page currently refers to Yum only — we’ll fix that asap) to get the Fedora 22 setup package. And as usual, please add general comments below, or submit specific issues or feature requests to the MySQL bug tracker.


MySQL Repos for Debian 8

Hi, everyone. Just a quick note here to let you all know that we’ve just added Debian 8 support to our Apt repos. We have the latest MySQL Server 5.6 ready for you, as well as the latest 5.7 Development Milestone, and more of our products for Debian 8 are in our QA pipeline as we speak.

Head over to the Apt repo page on dev.mysql.com, and we should have you up and running in next to no time at all.

MySQL in Dockerland

Around 18 months ago, we launched the first MySQL Linux package repos, marking an important milestone in our efforts to modernize and improve the way we package and deliver MySQL products to our user community. MySQL product development had gone through radical improvements in terms of quality, dependability and sheer output, but the way we delivered those products had quite frankly fallen way behind.

Now, with our repo offerings rapidly maturing, we have started looking at other new distribution and deployment technologies. We’re investigating how we can help make Puppet an even better tool for MySQL infrastructure deployment, we’re playing around with Ubuntu Snappy Core packaging of MySQL, and not least: we’re working as part of the Docker community to help make sure that the community maintained MySQL Docker images continue to be as wildly popular as they are now.

MySQL on Docker

>> Video: Whales and dolphins have been observed in playful company

The basic principle of Docker is extremely attractive: We can offer you a pre-configured image of a MySQL installation, and you can go from a blank system to a ready-to-use MySQL instance answering on port 3306 with one simple command line in the time it takes to finish a cup of coffee. Real world mileage may of course vary, but the core fact is that Docker can be a very useful alternative for many users and developers who deploy and run MySQL, either as part of a larger container based application infrastructure or as a general database service. And this is something that many of you have discovered: By early May of this year, the community maintained MySQL images had been pulled more than 4 million times. Basically: During its relatively brief existence, Docker has become an important way for many of our users to run MySQL.

MySQL and the Docker Community

When we started our adventure in Dockerland, we quickly discovered that it is in some ways quite similar to the Linux communities that we are working with: a large collection of people who are passionate about the underlying technology and the myriad uses it can be put to, and who are willing to put a lot of effort into building and improving stuff. And this is what we are gearing up to support: We want to help ensure that MySQL on Docker is as robust, easy to set up and well supported as possible.

As part of this, we’re also rolling our own, optimized Docker images. That allows us to take MySQL on Docker in some new directions, and lets us implement changes and improvements that may also be of value in the community maintained MySQL images. We will treat this as a regular release channel for MySQL Server, which means that we will apply a rigorous QA process and publish new images as part of our regular flow of update releases. We are seeing considerable interest in these images, and we’d like to say thank you to everyone who’ve taken them out for a spin.

For the community maintained images, our primary contribution so far has been revamped and much expanded documentation which aims to make MySQL deployment with Docker a more approachable task. Coming into Dockerland as relative newbies entailed climbing a learning curve that we’ve hopefully now made slightly less steep for others. We’ve also helped keep the images in sync with changes in the MySQL 5.7 development release series, and we have several other pull requests being queued up for discussion and possible inclusion into the community images.

How Docker improves MySQL

On the MySQL side, working with Docker has uncovered some areas that could use improvement. Our initialization on first startup is improving a lot in the upcoming MySQL 5.7, but we have more work to do in order to smoothly support the way Docker does things. The ability to set a far greater range of MySQL configuration parameters during runtime would also make MySQL run better inside Docker containers. Happily, we’re putting those things onto our engineering road map, so keep watching our development releases, and you should see improvements appearing.

Using Docker for Previewing and Testing MySQL

This brings us to another great use for Docker images, besides running regular production MySQL instances: testing out development releases in an isolated setting, alongside any other MySQL instances you may have running on your system. MySQL development milestone releases are of course available, and today we’re adding another image flavor: a so called MySQL Labs release. Labs releases are what we use when we have something experimental or particularly interesting to show the MySQL community in order to get very early feedback. The latest Labs release is based on the recent 5.7.7 development milestone and introduces a new data type for storing JSON data in MySQL tables, along with a range of new functions to access and manipulate JSON documents. The Docker image for this release is available in the MySQL Labs area on Docker Hub now, or for the very eager:

docker run --name my-container-name -e MYSQL_ROOT_PASSWORD=my-secret-pw -d mysql/mysql-labs:5.7.7-json

Try it out and let us know what you think!

That was a whirlwind tour of what we’re doing with Docker and other new deployment and runtime environments these days. We’d be delighted to hear from you if you have ideas or suggestions for us. Please drop us a line in the comments section below, comment on our main page on Docker Hub, or in cause you (gasp) encounter issues: file a bug in the MySQL bug database.

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 https://github.com/mysql. 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.