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

Rapid7 secures new funding. Microsoft drops Dryad. And more.

# Rapid7 secured $50m in series C funding.

# Microsoft confirmed that it is ditching its Dryad project in favour of Apache Hadoop.

# Arun Murthy provided more details of Apache Hadop 0.23.

# The Google Plugin for Eclipse and GWT Designer projects are now fully open source.

# openSUSE released version 12.1.

# Amazon released the source code of the Kindle Fire.

# Black Duck Software joined the GENIVI Alliance.

# dotCloud announced the availability of the top three databases MySQL, MongoDB and Redis on its PaaS.

I just finished reading a couple of interesting, and somewhat related, blog posts which I think are worth sharing (apologies to anyone who has already seen them). One is from Jelastic and the other is from Michal Hrušecký.

I’ve written about MariaDB and the Jelastic cloud before (see MariaDB now available as a hosted database via Jelastic cloud platform). Now Jelastic has published statistics on the relative popularity of the various databases they offer. The good news is MariaDB is currently the database of choice for 14% of their customers. The bad news is that we’re in fourth place behind their other three database choices (MySQL, PostgreSQL, and MongoDB). However, MariaDB has only been available on their platform for a little over two months and we’re very happy that so many users of Jelastic’s state-of-the-art Java cloud are choosing to use MariaDB. Thanks!

In the second blog post, Michal Hrušecký shares the results of what he terms his “little MySQL survey”. This time MariaDB comes in second behind MySQL Community Server (and ahead of MySQL Cluster and Percona Server). In case you didn’t know, Michal packages MySQL and MariaDB for openSUSE, so this survey was a good way for him to judge the relative popularity of some of the more popular variants and give him ideas on how to improve things.

BTW: If you know of other interesting/informative/etc… blog posts related to MariaDB, let us know so we can add them to the Blog Posts Relevant to MariaDB page of the AskMonty Knowledgebase!

As I promised a week ago, I’m publishing results of my little MySQL survey. Question that people (including me) are probably the most interested in is what variant(s) of MySQL are people using. No big surprise is that the most used variant (89%) is MySQL Community Server from Oracle. It’s well known default, people know what to expect and administrators golden rule is don’t touch it if it works. And other variants build on top of it anyway.
Second place (20%) belong to MariaDB. That is answer I also kind of expected. MariaDB guys are verbose and visible. At least I saw much more people talking about MariaDB then about Percona. Part of it might be that they position themselves as kind of MySQL competitor. Oracle is big controversial company. Sometimes we hate them (they killed OpenOffice!), sometimes we love them (btrfs is great!). So I can imagine regular users getting angry with Oracle and switching to the competitor. And there was a period of time in history when we all were unsure about what Oracle will do to the MySQL and MariaDB was there for us. Some people can also have some valid reasons. Like the need for one of the included storage engines.
What surprised me was how little people use MySQL Cluster included in the distribution. 4 people responded that they use MySQL Cluster and only two of them use it from main repository. Cluster uses same amount of people as people using Percona which we don’t have in our repositories at all! The outcome from this is that I’ll probably drop MySQL Cluster from main distribution and keep it only in obs for now. This change will help me concentrate more on variants that people use. But MySQL Cluster will be still available in obs in it’s latest version.
I’m not planning inclusion of Percona, but if anybody is interested, it should be pretty easy to put it to obs using templates I have for MySQL.
From the rest of the results, it’s apparent that unstable repository is not known and that plenty of responders have some suggestions for default MySQL configuration and they are keeping them to themselves! So if you are one of them, let me know you suggestions. Ideally by sending me configuration snippet everybody can benefit from
In the end I would like to thank all participants for their responses, it will help me concentrate on things you are interested the most and improve overall presence of MySQL in openSUSE Build Service. And of course, any comments are welcome and whole results can be seen on separate web page mentioned bellow

Survey results

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

Opscode appoints a new CEO. SugarCRM gains a new CFO. And more.

# Opscode named Mitch Hill as CEO, with Jesse Robbins becoming Chief Community Officer.

# SugarCRM claimed billings up 58% in Q2 and appointed a new CFO.

# Tasktop released Tasktop Dev 2.1 and announced Tasktop Sync 1.0.

# Pentaho delivered improved support for Hadoop and various NoSQL database projects.

# The openSUSE community approved its strategy document.

# Dustin Kirkland described the Ubuntu Orchestra Project.