PlanetMysql.ru — информация о СУБД MySQL

There has been a lot going on in MySQL community and I didn’t blogged about MySQL for some time. So this is a small update regarding MySQL in openSUSE Build Service and in openSUSE in general. This post is intended to let you know what, where and in which version we’ve got in Build Service And as I recently dropped server:database:UNSTABLE repo, everything is now in server:database, so the where part is quite easy

MySQL Community Server

First, let’s take a look at MySQL Community Server provided by the open source company we all love – Oracle. There are several versions around. Which one is the right one for you? That question you have to decide by yourself, but whichever it is, we’ve got in in obs

MySQL 5.5

MySQL 5.5 was in the in repositories for quite some time. Currently there is a version 5.5.18. You can get it by installing package mysql-community-server from server:database repository. As 5.5 is around a long time already and widely tested (was running my blog for several months) it is also the version shipped with openSUSE 12.1. Although version included there is just 5.5.16. But that’s good anyway, isn’t it?

MySQL 5.6

Do you think that MySQL 5.5 is old and not cool anymore? I kind of agree. Where is the fun in stable things So if you want, you can start testing the new cool branch people are speaking about – MySQL 5.6.2. You can find it in server:database repository as package mysql-community-server_56.

MariaDB

Now let’s talk a little bit about the stuff that folks from Monty Program are working on.

MariaDB 5.2

As for MariaDB, there is version 5.2.10 available in the server:database repository and version 5.2.9 made it to openSUSE 12.1. So you can choose from who do you want your MySQL even in distribution itself

MariaDB 5.3

As I said already, I don’t like stable stuff, I like living on the edge. The bleeding edge So if you like Maria but want the newest and coolest, we’ve got that too. You can get MariaDB 5.3.2 from server:database repository (package mariadb_53) right now and try it out! That is the MySQL version I’m using for this blog right now But who knows what variant I will be using next month or year?

MySQL Cluster

Do you want more options? Do you want to play with cluster? We’ve got that too

MySQL Cluster 7.1

For the conservative folks, we’ve got MySQL Cluster 7.1.17 in server:database repository and version 7.1.15 was included in openSUSE 12.1. As you may have read already, I dropped MySQL Cluster from openSUSE Factory, so there will be probably no MySQL Cluster in next openSUSE. But don’t worry, it will still be here in server:database repository

MySQL Cluster 7.2

Do you want to play some more with clusters? We’ve got also MySQL Cluster 7.2.1 in server:database repository (package mysql-cluster_72). So you can try new beta, play with new features and try to make it crash. I think Oracle will be happy if you will manage to and will tell them about it

Switching around

Thanks to the setup we’ve got in openSUSE it is quite easy to switch between all variants as you like. Is there really cool new feature you are dying to try in MySQL 5.6? No problem if you have server:database repository. Just type in:

# zypper in mysql-community-server_56

Have Oracle done something bad and are you angry at them? Do you want your symbolic virtual revenge? Just type in:

# zypper in mariadb

What will happen? Well regardless of what would you try to install, zypper will tell that it is not possible to have two different variants at the same time. And it will let you choose. Either you will continue with installation and deinstall your old variant, or you will cowardly decide to stick with what you have. Quite simple, isn’t it? There is one little catch… Your old configuration will be saved as my.cnf.rpmsave and you’ll  end up with default configuration. But you can solve this one easily
What do we still miss from widely used stuff in our repositories is Percona. But I created Google Code-In task, so maybe some student will step-up and fix this. And even if nobody will, you can always try to be that volunteer I tried to put together some HowTo contribute to MySQL in openSUSE, so it shouldn’t be hard

Overall, if you want to play with MySQL, I think we are well prepared

In openSUSE we’ve got currently MySQL Community Server, MariaDB and MySQL Cluster. From all of these we have even multiple versions. Although these packages are different, they are quilte similar. So I’m handling them in a little bit special way.
When I was adding MariaDB I knew that packaging will be quite similar to the MySQL Community Server. So I took some parts of .spec file away into separate files so I can sync them easily and left only package dependent parts in .spec files. Later on, I created special git repository and few scripts to handle patches and patch sharing among these variants. And lately I automatized tre rest of the manual syncing I was diong. So today I want to present how do I do MySQL packaging today. And that is also some tutorial on how you can modify these packages easily or even create packages for other variants like Percona
Everything starts with one of my repositories on github. Let’s take a look at what it contains. Some scripts and few directories. Let’s start with directories.
First directory is named common and it contains several files. As you can guess, it contains code common to all MySQL variants. So you can find here build scripts, install scripts, rc script, few readmes and template for the spec file. Templates ends up with .in. All non-template files are later committed to the openSUSE Build Service as they are in the repository. Templates needs to be filled in first. For that I decided to use mustache. You can install it by running gem install mustache. But back to the packaging. We need some variant specific files, something to fill templates with and some patches, right?
For these reasons there are directories named after particular MySQL variant (for example mysql-community-server-56 or mariadb-53). Inside these directories are at least config.yaml file and series fil. But probably there is some more. config.yaml file is used by mustache to fill in the templates. So you can find here package names, descriptions, versions and such. Things that has to differ among all variants.
Apart from these, you can also find some .cnf files in variant specific directories. These are configuration files to be included. This way even if you modify your /etc/my.cnf, these snippets can get updated (if you don’t modify them as well). Here is also place for some contribution – you can send me just few snippets from my.cnf, that will improve default configuration Or create packages with new plugins and them register automatically here.
Last file in the variant directory I spoke about – series file and the last directory I havn’t spoke about yet – patches have something in common – they are used for patching. series file contains a list of patches to apply. And patches directory contains these patches. How it works is described in my other github repository. Basically the point is to use few scripts so I have to maintain just series file outside of .spec file. Then there are scripts that will fetch patches, pack them up and during build apply them. No need for me to take some extra care.

Example

So how it works in practice. Let’s imagine we want to update MariaDB 5.3.x to newer version. I will go to the local checkout of mariadb-53 package (how to get one was described in the first article of this series) and replace old tarball with new one. Then I will modify mariadb-53/config.yaml file in packaging repository (change the version). After that I will call the only thing I haven’t spoke about yet – update-package.sh script in my packaging repository. This will check current path and according to the directory I’m in it will pick correct variant and replace all files with updated variants from the repository – new rc script, updated .spec file and everything. After that I need to check whether all patches still apply or fix them (now quilt comes handy) and try building the package. It may happen that I’ll find something that needs to be fixed. In that case, I’ll fix stuff in the git repository and let the script recreate everything. When I’m finished, I’ll commit everything to obs and git and move to another package. The key is that this way although I’m maintaining a lot of MySQL variants, I maintain them all as one. An if I fix something in one variant, fixes will eventually get to all of them

Last time I described how to contribute quite to any package in openSUSE Build Service. But I left out the most important part. I haven’t shown how to change anything. This time I want to show you, how to create patches, if you need them, easily. Let’s start start with package we checked out from obs. Creating patch for anything is different only in first few steps.
First we got to the directory where do we have the package checked out. We run

quilt setup

This command will parse the .spec file, unpack tarball and prepare all quilt stuff. Now is time for patching, so let’s enter the newly created directory and try following command

quilt push

You know that in .spec there might be some patches. quilt push will take first patch that is not applied yet and apply it. If you want to go back, you can use quilt pop. You can also use quilt patch -a to apply all patches if possible. If it is not possible, it will tell you loudly and you have to handle situation manually. This often happens when you are updating package to the newer version.
How to deal with it? Trick is to start with quilt patch -f which will apply everything it can and tell you about stuff that can’t be applied (and creates bunch of .rej files. Now you have to fix these, but you are already working on patch, so just skip following paragraph and continue with howto
If all patches applied without problems/you don’t have any yet, you have to start one. You can also start here, if you don’t have a spec file and you just want to create a patch for some sources that were lying on your hard drive. You can start new patch by calling

quilt new package-version-patch-name.patch

From now you are working on patch. As patch consists from changes to the files, you have to do that changes now, right? One easy way is to call

quilt edit path/file

This will open up you favorite editor (the one that is set in your EDITOR variable) and open up specified file and let you edit it. You can also do a little bit different trick. You can use

quilt add path/file

This just saves the current state of the file. You can then edit it how ever you want or replace it with another file or do some changes to it however you want.
Once you are done with editing, it’s time to actually create a patch. You can review all changes by using quilt diff and if you are happy with them, call

quilt refresh -p0

This will create patch with patch level 0 (this is the best choice for .spec files, git creates patch level 1 by default). It will also tell you where your patch is. So you can just take it and use it.
Last little note, as I already pointed out, you can of course use quilt not only with .spec files. You can enter any directory anywhere and start creating patch using quilt new patchname.patch, quilt edit path/file and quilt refresh -p0. It will work too. quilt setup and quilt push are just great help to apply all patches that you have already prepared and continue from there.
Hope this may help some of you with patching software and playing with packaging. Next time, I’ll continue with how do I package MySQL on openSUSE in more details and how do I handle all different variants.

I promised that I’ll write a post about how you can contribute. There are several ways how to contribute to MySQL, but most of it means modifying packages. And as everything in openSUSE is built using openSUSE Build service, first post will be actually pretty general obs and osc howto. In the next posts, I’ll go deeper into specific details of MySQL packaging.

Find the package

If you want to play with any package in openSUSE Build Service, you need to have a Novell login and preferably the osc command line client for obs. You can do most of the stuff from web as well, but this way is more comfortable So let’s say that we want to play with MariaDB. First we have to find package we want to update. This can be easily done on the web. Just take a look at packages at server:database repository. mariadb is the version currently included in the Factory. If you want to update bleeding edge version, these are named usually something like mariadb-53 for 5.3 branch or mysql-commmunity-server-56 for MySQL Community Server 5.6 branch. So basically if package name doesn’t contain version, it’s package for factory, if it does, it is just for people wanting something that is not in Factory yet (or already).

Get source

As you can’t commit to server:database directly, you will need to branch this package somewhere you can commit to and check it out. In examples I will use NICK as a placeholder for the nickname that you got during your registration. Let’s go through example during which we want to play with MariaDB in 5.3 branch. First step is to create our own branch of the code we can commit to:

osc branch server:database mariadb-53 home:NICK

Now we have a copy of mariadb-53package in our repository in obs. But we want to do some changes locally on the hard drive. So let’s check it out:

osc co home:NICK/mariadb-53

Now we have it in directory home:NICK/mariadb-53 and we can start playing with it and do some changes. How to do some changes will be described in the following blog posts.

Building and testing

After some changes are done, we want to test them, don’t we? Let’s call osc build --ccache to test whether it builds. --ccache enables ccache support which takes more space but speeds up built and consequent rebuilds. So it is a good idea to use it especially in MySQL case If compilation will work well, it will give you several packages to try. And if everything goes well, it’s time to finally contribute all the work back!

Contribute

Few final commands:

osc ar
osc vc
osc commit

Which marks all new files for addition, deleted files for deletion (osc ar), document the changes (osc vc) and commit them (osc commit). Next step it to wait and see whether it build on server as well (osc results) and if it does and it still works, it’s time to send it to me using osc sr command. After that I will get it, take a look at it and either accept it and if it is factory version then also forward it to the Factory (you’ll have your name forever in the changelogs) or I will decline it and tell you what’s wrong. If there is something wrong, you would need to fix it to get you changes accepted. So goto 'Building and testing'

Temporal conclusion

As you have seen, it is quite easy to use osc to contribute to the packages. Well, I left out the most complicated part – actually changing the package, but that will be topic of the next post and you’ll see that even that part isn’t hard

Earlier today I asked on this blog and everywhere else people to fill in a simple survey of how do they use MySQL, which one and what should I focus on. I already have more than 30 answers (don’t stop answering, keep providing more) so I will have to publish the results and do something with them. But first I’ll let the survey run for at least a week Oh, and even though I write MySQL, this post is general about all MySQL variants (MariaDB, MySQL Cluster, … (not counting Drizzle)).
Now what is behind this survey? Well, I have a lot of stuff to do and MySQL is not my only responsibility. And I know that sometimes it can use some extra hands. Sometimes I get lucky and we have new beta packaged same day as it was released, other times it takes me weeks or even more than month before I’ll get to the updates. And I see several ways, how to make MySQL presence even better in openSUSE Build Service. But as always, it’s matter of manpower and time. As several people already responded, that they want to get involved, I’ll publish in next few days several posts about how you can help with various tasks around MySQL. So ti will be even better available, more polished and more awesome
Other thing I was interested in was whether somebody actually uses the non-core stuff. Whether it is great to have it around or whether I should just stop doing it and spend more time on the core stuff.
First of my doubts was whether having server:database:UNSTABLE repository is a good thing… Well, so far not many people responded that they use it, but quite a lot of people responded that they want the latest & coolest stuff. I can imagine this means MySQL Community Server 5.6 or MariaDB 5.3. Both of them can be found in server:database:UNSTABLE. So I think this one I should keep around, but I should be definitely more verbose about what we already have.
Second doubt was whether anybody actually uses MySQL Cluster we added to openSUSE in 11.4. So far I’m not really convinced. But survey just started, so we will see. If nobody uses it, I may drop it after 12.1 from Factory and have it just in additional repository. We will see, how survey will end.
So thank you for filling in the survey and expect some more information about how you can help to improve MySQL presence in openSUSE soon

This is not really a blog post. I just would like to know you opinion on state of MySQL at openSUSE and openSUSE Build Service. But I’m interested in your feedback even if you are not using openSUSE or even if you are not using packages I provide. As my TODO is quite long and I can’t do everything, I would like to know what should I pay the most attention to. Later I will publish a post about the current state of MySQL and how you can participate

There has been a lot happening in the MariaDB community recently, and there has been growth. Here are some of the highlights. Thank you to all our current contributors, and to others that want to contribute, shoot community[at]askmonty[dot]org an e-mail.

MariaDB 5.2.3 binaries for Solaris and Debian Sparc

Our Sparc community contributor, Mark, has continued to make popular binaries for Solaris 10 and Debian Sparc. He’s kept up to speed with MariaDB 5.2.3, so please visit him and download the binaries.

MariaDB 5.2.3 on the openSUSE Build Service

Community contributor Michal Hrušecký has packaged MariaDB for openSUSE and its available via the openSUSE build service. It is ready up to version 5.2.3, and is still in the unstable repository (it will progress further based on more testing). A benefit of the openSUSE build service is that it also churns out RPMs for CentOS, Fedora, Mandriva, Red Hat Enterprise Linux, openSUSE and SUSE Linux Enterprise.

MariaDB Virtual Machines

Again from Mark, he’s been working on creating virtual machines for people to test MariaDB with. He’s looking for feedback on which virtualization platform people are looking for VMs for. Currently there is a VM for CentOS 5.5 and Ubuntu 10.04 LTS. These are all 64-bit virtual machines. You can make use of them using VirtualBox.

Mirrors

Looking back at the releases page, we have made eleven 5.1 releases and four 5.2 releases. When we made our first 5.1 release we had one mirror (this was in April 2009). When we made our first 5.2 release, we had four mirrors (this was in April 2010). Today we are up to seven mirrors, and from recent requests I expect this to grow. If you want to mirror MariaDB, check out the Mirroring MariaDB guide on the AskMonty Knowledgebase.

The aims of this kind of blog post is simple – I want to help keep the masses informed as to what’s happening with MariaDB, as a whole. There is a community growing, and MariaDB is a community project, not necessarily a Monty Program Ab baby (and we’re clear on this distinction: think of it like Canonical/Ubuntu). So, think of it as such that I’m sharing the good news, and summarising what’s been happening, to save you time.

MariaDB added to the Debian/Ubuntu wishlists
One of MariaDB’s goals is that it should be easily available for download. While we provide binaries and source at the MariaDB download page, we would love to see the binaries sitting in Linux distributions. So it is definitely good to see that it is on the Debian wishlist. It is also worth noting that Ubuntu has got it as a wishlist item as well.

MariaDB via the OpenSUSE build service
A community member, Michal Hrušecký, has decided that there will be tracking of MariaDB, and since it comes out of the OpenSUSE build service, you can find them in the unstable repository, for CentOS/RHEL 5, Fedora 11 and 12, Mandriva 2010, and OpenSUSE 11.1, 11.2, and the factory builds. All these are of course of the latest release available, which is MariaDB 5.1.42.

MariaDB for Solaris 10 and Debian on SPARC
Mark has very kindly decided to build binaries for Solaris 10 on Sparc as well as Debian GNU/Linux on Sparc. He even managed to write up a quick & dirty install guide, which should suffice for all intents and purposes. Note that these are still 5.1.41-RC releases, and you can expect to get updates soon for the released 5.1.42.

Using MariaDB with the MySQL Sandbox
The MySQL Sandbox is a great way to play with new releases of MySQL or MariaDB. Gerry Narvaja has got some tricks up his sleeve, to allow you to get going using MariaDB with the MySQL Sandbox.

MariaDB resources
A few resources if you’re new to the community:

• maria-discuss mailing list (and its archives)
• maria-developers mailing list (and its archives)
• #maria IRC logs. Don’t hesitate to join us on irc.freenode.net on #maria

Hope you’ve found this useful, and the aim is to have this bi-monthly, more frequent if there is a need for it. I might even record it as a short podcast, so you can take it on the go. If you have thoughts on this, don’t hesitate to contact me, or drop me an email at colin[AT]askmonty.org.

Related posts:

1. MariaDB 5.1.42 released!
2. MySQL with yaSSL vulnerability
3. Getting emo over binaries?