So mycheckpoint works in a completely different way. On one hand, it doesn’t bother with caching. On the other hand, it doesn’t bother with re-reads of data.

There are no staleness issues, the data is consistent as it can get (you can never get a completely atomic read of everything in MySQL), and you can issue as many calculations as you want at the price of one take of monitoring. As in Sheere’s example, you can run Threads_connected/max_connections*100, mix status variables, system variables, meta-variables (e.g. Seconds_behind_master), user-created variables (e.g. number of purchases in your online shop) etc.

mycheckpoint‘s concept is to store data. And store it in relational format. That is, INSERT it to a table.

A sample-run generates a row, which lists all status, server, OS, user, meta variables. It’s a huge row, with hundreds of columns. Columns like threads_connected, max_connections, innodb_buffer_pool_size, seconds_behind_master, etc.

mycheckpoint hardly cares about these columns. It identifies them dynamically. Have you just upgraded to MySQL 5.5? Oh, there’s a new bunch of server and status variables? No problem, mycheckpoint will notice it doesn’t have the matching columns and will add them via ALTER TABLE. There you go, now we have a place to store them.

Running a formula like Threads_connected/max_connections*100 is as easy as issuing the following query:

SELECT Threads_connected/max_connections*100 FROM status_variables WHERE id = ...

Hmmm. This means I can run this formula on the most recent row I’ve just added. But wait, this also means I can run this formula on any row I’ve ever gathered.

With mycheckpoint you can generate graphs retroactively using new formulas. The data is there, vanilla style. Any formula which can be calculated via SQL is good to go with. Plus, you get the benefit of cross referencing in fun ways: cross reference to the timestamp at which the sample was taken (so, for example, ignore the spikes generated at this and that timeframe due to maintenance. Don’t alert me on these), to system issues like load average or CPU usage (show me the average Seconds_behind_master when load average is over 8, or the average load average when slow query rate is over some threshold. You don’t do that all the time, but when you need it, well, you can get all the insight you ever wanted.

Actually storing the monitored data in an easy to access format allows one to query, re-query, re-formulate. No worries about caching, you only sample once.

For completeness, all the above is relevant when the data is of numeric types. Other types are far more complicated to manage (the list of running queries is a common example).

Article source: http://code.openark.org/blog/mysql/mysql-monitoring-storing-not-caching

Edited to add: I just took a look at the Percona monitoring plugins for Nagios and they check very, very different things. The level of customization is not as flexible as it is with the PalominoDB Nagios plugin, because it is checking very different things. The Percona monitoring plugins are a set of 12 different checks, as opposed to the 1 check that the PalominoDB plugin has. Still, I could see a value in caching the output of SHOW ENGINE INNODB STATUS (or whatever it uses) for the pmp-check-mysql-innodb plugin, so you can run it three times – once with the idle_blocker_duration option, once with the waiter_count option, and once with the max_duration option, and it only runs the command needed once.

Basically it comes down to this: Baron is correct when he says “Running SHOW STATUS infrequently doesn’t add load to the server.” and I am correct when I say “Running SHOW STATUS frequently adds a lot of load to the server.” The Percona plugin and the PalominoDB plugin are completely different, and there seems to be very little overlap.

Article source: http://www.sheeri.com/content/caching-monitoring-timing-everything

Obviously 1 billion is only of interest to us humans as we generally happen to have 10 fingers, and seem to name multiples in steps of 10^3 for some reason. Each processor involved in this benchmark is clocked at several billion cycles per second, so a single billion is not so vast or fast.

Measuring over a minute also feels unnatural for a computer performance benchmark – we are used to lots of things happening every second! A minute is a long time in silicon.

What’s more, these reads are served from tables stored entirely in memory – and everyone knows that main memory is infinitely fast and scalable and always getting cheaper, right?

If we convert to seconds we are left with only 17 million reads per second! Hardly worth getting out of bed for?

On the contrary, I think that achieving 17 million independent random reads per second, each read returning 100 bytes across a network, from a database that also supports arbitrary SQL, row locking, transactions, high availability and all sorts of other stuff, is pretty cool. I doubt that (m)any other similar databases can match this raw performance, though I look forward to being proved wrong.

(Also, don’t forget to meet + beat 1.9 million random updates/s, synchronously replicated)

Raw performance is good, but not everyone just needs horsepower. The parallel, independent work on improving join performance (also known as SPJ/AQL) and query optimisation helps more applications harness this power, by improving the efficiency of joins.

I wrote a post about SPJ/AQL at the start of last year, when it was still in the early stages. Since then much has improved, to the extent that the performance improvement factors have become embarrassingly high on real user queries. A further post on the technical details of SPJ/AQL is long overdue… Perhaps the most interesting details are on the integration between the parallel, streaming linked operations and the essentially serialised MySQL Nested Loops join executor. A linked scan and lookup operation can be considered to be a form of parallel hash join, which the normal MySQL NLJ executor can invoke as part of executing a query. Who says Nested Loop joins can’t scale?

Article source: http://messagepassing.blogspot.com/2012/02/one-billion.html

The SQLyog Query Profiler was introduced in SQLyog 8.o in February 2009 – exactly 3 years ago. The funny thing is actually that Baron Schwartz reviewed it before release (at friendly commercial terms) at the time. The SUM-aggregation and the ORDERING that we did (and it was solely our decision – not Baron’s advice) in SQLyog 8.0 to the result from SELECT FROM I_S.PROFILES is the same as Baron now announces as “something I developed”.

Well ..

1) First let me make it clear that I am not complaing.  I believe Baron when he tells that he does not remember details of the SQLyog Query Profiler today. When I use the term funny above I mean it. Baron is welcome to re-use it even if he forgot and had to re-invent it (and also we re-use his ‘Change Of STATUS VARIABLES Due To Execution Of Query’ profiling concept from the original Maatkit release as well).

2) But *developed* is a pretty strong term to use for a rather trivial query (just a SELECT .. SUM() ..  GROUP BY .. ORDER BY .. basically), I think.  Just like there are only 12 notes in (western) music and it is difficult to write music that does not resemble previous music somehow, it is also difficult to write queries that do not resemble previous queries (I know chess-players would disagree – with 64 squares and 32 pieces  possibilities seem infinite – but maybe the rules of chess allow for more creative combinations than the rules of SQL? I belive so.  It probably also applies to music – but not to SQL IMHO ).

Happy PROFILING (with any tool you choose)! And Chess-playing as well!

<!–
digg_url = ‘http://www.webyog.com/blog/2012/02/20/sqlyog-query-profiler-re-invented/’;
digg_bgcolor = ‘#ff9900′;
digg_skin = ‘compact’;
digg_window = ‘new’;

–>

Comments(0)

Article source: http://www.webyog.com/blog/2012/02/20/sqlyog-query-profiler-re-invented/

Scalability has been enhanced in various ways, beginning with enhanced active/active replication that makes it easier for developers to detect and resolve conflicts across multiple clusters and eliminates the need for timestamp columns in applications.  MySQL Cluster 7.2’s multi-site clusters allow for the existence of individual data notes in different data centers with the automatic sharding of databases between them.  Additionally, data consistency and integrity among sites is maintained with quick automated failover and recovery via synchronous replication.

MySQL Cluster’s performance has become even better in version 7.2.  The product promises up to 70x higher performance when executing complex queries thanks to adaptive query localization.  This breakthrough allows more applications to leverage the power of real-time analytics across live data sets as well as other features offered under MySQL Cluster’s umbrella.

While previous versions of MySQL Cluster have been deemed user-friendly, version 7.2 takes things one step further by implemented shared user privilege tables.  These tables consolidated previously distributed tables into the data nodes to allow access from all MySQL servers, making life easier for administrators.  No longer do they need to define and maintain privileges on separate SQL nodes accessing the cluster.

The final improvement featured in MySQL Cluster 7.2 that’s worth mentioning is Oracle VM certification, which makes it an appealing choice for customers seeking a cloud deployment solution for communications and web applications.  The inclusion of Oracle VM certification adds to pre-existing MySQL Cluster certifications with Oracle Linux and Oracle Solaris.

Beyond the release of MySQL Cluster 7.2, Oracle also announced the availability of MySQL Cluster Manager 1.1.4.  Just as with MySQL Cluster 7.2, the latest release of Cluster Manager has been enhanced to make using and administering MySQL Cluster easier. 

Tomas Ulin, Oracle’s VP of MySQL engineering, commented on the latest release: “MySQL Cluster 7.2 demonstrates Oracle’s investment in further strengthening MySQL’s position as the leading Web database.  The performance and flexibility enhancements in MySQL Cluster 7.2 provide users with a solid foundation for their mission-critical Web workloads, blending the best of SQL and NoSQL technologies to reduce risk, cost and complexity.”

For more on this topic, visit http://www.marketwatch.com/story/oracle-announces-general-availability-of-mysql-cluster-72-2012-02-15

Please enable JavaScript to view the comments powered by Disqus.blog comments powered by Disqus

Article source: http://www.devshed.com/c/a/MySQL/Oracle-Releases-MySQL-Cluster-72-69648/

We offer consulting, training, support, and custom development services.

We also create Percona Server, XtraDB and XtraBackup.

Article source: http://www.mysqlperformanceblog.com/2012/02/20/mysql-meetups-in-north-carolina-this-week/

When I wrote a set of high-quality Cacti templates for MySQL a few years ago (which are now replaced by the new project), making the Cacti templates use caching was important for two reasons:

1. Performance. Cacti runs some of its polling processes serially, so if each graph has to reach out to the MySQL server and retrieve a bunch of data, the polling can take too long. I’ve seen cases where a Cacti server that’s graphing too many MySQL servers doesn’t finish the current iteration before the next one starts. Making sure the data isn’t retrieved from MySQL repeatedly cuts a lot of latency out of the process. In fact, I went further than that; I didn’t cache the data retrieved from MySQL, I cached the resulting metrics. This avoids having to do InnoDB parsing repeatedly, too. With this approach, Cacti is capable of monitoring many more servers.
2. Consistency. Graphs are supposed to be generated at a single instant in time, but as I just said, they actually aren’t. Graphs that show slightly different data, or greatly different data in some cases I observed, are frustrating at best and wrong or misleading at worst. When you’re using these graphs for forensic or diagnostic purposes, this is very bad. Caching the results from the first call and reusing it for all subsequent polls avoids this problem. All of the graphs are generated from one and only one set of data retrieved from MySQL.

It’s worth noting that Cacti doesn’t do this itself, which I consider to be a Cacti design shortcoming. I did not like writing my own cache management code. Handling cached data correctly is one of the two hard things in programming (choosing proper variable names is the other one, of course).

Now, somewhere along the line “you should cache when you are monitoring a system for failures” became a tacit best practice. I don’t know why, but I can speculate that there might have been a misunderstanding — perhaps caching was understood to reduce load on MySQL, rather than reducing load on the Cacti server and speeding up the poller.

This is a very bad idea! I do NOT advocate caching for Nagios checks. Why? Exactly the inverse of the two reasons that graphing should be cached!

1. Performance doesn’t matter. First, most Nagios checks are run once every five minutes, or once a minute at most. Running SHOW STATUS infrequently doesn’t add load to the server. Most real production installations I see actually have multiple people running innotop or what have you, once a second! Second, if your monitoring is to be at all useful, you should not monitor too many things inside of MySQL. If you take the typical mass-market monitoring program’s silly “alert on 99 different kinds of cache hit ratio thresholds” approach, you’ll soon have sysadmins with /dev/null email filters, which will make your monitoring system utterly useless. However, even if you have multiple checks running once a minute, it’s still a trivial amount of load.
2. Consistency is just another word for staleness. Great, your monitoring system thinks that the server is fine, based on a three-minute-old file — what good is that? You should be monitoring the server, as of NOW, rather than monitoring the contents of some file as of several minutes ago.

In conclusion, you should cache for historical metrics monitoring, but not for fault detection monitoring. That’s why the new Nagios plugins don’t have any caching functionality.

Article source: http://www.mysqlperformanceblog.com/2012/02/19/why-dont-our-new-nagios-plugins-use-caching/

Galera Cluster for MySQL is offered as open source software. It can be downloaded freely from www.codership.com. Many of Codership customers are using Galera Cluster for business critical applications. FromDual will be offering consulting and support services for Galera users, especially in German speaking countries. ”FromDual has years of competence in MySQL consulting and support. They have a deep understanding of clustering and replication technologies and how to implement them into production. FromDual is the perfect partner for Codership” said Seppo Jaakola, CEO of Codership.

“With Galera we get a great high availability (HA) product for MySQL which removes all the pain we had with the existing MySQL HA solutions. Our customers are always looking for better ways to solve MySQL replication, scalability and management issues to secure 24/7 business availability and growth for the future business. Galera Cluster does exactly that. We are happy to add Galera Cluster to our consulting and support portfolio with the top level support from Codership” says Oli Sennhauser, Senior MySQL consultant and CEO of FromDual.

Galera Cluster is used by users who need highly available MySQL database back-ends with very fast fail-over time for business critical applications like Social networks, Gaming platforms, Telecom/VoiP solutions, Media and entertainment sites, Business Software as a Service (SaaS), Platform as a Service (PaaS), ERP systems, web-shops, e-commerce solutions or similar critical applications.

About FromDual GmbH

FromDual is a global acting, neutral and vendor independent consulting, support and training company for MySQL, Percona Server, MariaDB and Galera Cluster with numerous customers all over the world in the Telecom, Media, Public Service, Internet and Industry sector. FromDual is Oracle Silver Partner and Open Database Alliance (ODBA) Silver Partner. In addition to its MySQL services FromDual distributes its Performance Monitor for MySQL for local installations or as Software as a Service solution. For more information about FromDual, their products, consulting and support services, please visit www.fromdual.com.

Press contact:

FromDual GmbH
Oli Sennhauser, CEO
E-Mail: oli.sennhauser@fromdual.com
Cell: +41 79 830 09 33

About Codership Oy

Codership develops fundamentally new replication and clustering solutions for open source databases, adopting novel ideas from latest DBMS and distributed computing research. The founders of Codership have long experience in developing several widely used MySQL clustering solutions before starting Galera development in 2007. Already thousands of users have chosen Galera Cluster solution – the Codership’s flagship open source product and Codership is working actively for and with this growing user community. For more information about Codership, products, consulting and support services, please visit www.codership.com.

Press contact:

Codership OY
Seppo Jaakola, CEO
E-Mail: seppo.jaakola@codership.com
Cell: +358 405 105 938

Article source: http://www.fromdual.com/codership-partners-with-fromdual

A top 20 global website announced they have migrated from MySQL to Redis. There will be a keynote and everything. It doesn’t say how big the Redis Cluster is, but they serve 100M pages / day, and clock 300k Redis queries / second.
https://groups.google.com/forum/?fromgroups#!topic/redis-db/d4QcWV0p-YM

Btw, they mention that MySQL remains as the master data store from which the Redis indexes are generated.
(The reason I don’t mention the name of this Redis user is simply I feat my mom is sometimes reading my blog…)

This is an oldie, but already 2 years ago DeNA posted a benchmark doing 750k MySQL queries / second on only a single server. This was with HandlerSocket, the first widely used NoSQL API for InnoDB based MySQL databases.
http://yoshinorimatsunobu.blogspot.com/2010/10/using-mysql-as-nosql-stor…

Last week MySQL Cluster team announced a new version. (congratulations, fellows!) The hardware in this benchmark is quite beefy: 8 modern servers with Infiniband as the interconnect. Even so the results, again using the NDB NoSQL API, are impressive: 1 billion queries per minute, or 17 million per second.
http://mikaelronstrom.blogspot.com/2012/02/105bn-qpm-using-mysql-cluster…

It should be mentioned the above is not an apples to oranges comparison. The Redis numbers are from a production installation and not a benchmark. Obviously you wouldn’t want to max out your performance in production. Quite the contrary: for HA purposes you want to make sure to run at most at 50% your capacity. So if we take this 50% limit into account, then MySQL Cluster can only do a measly 8 million queries per second

PS: I’ve seen the Austin Powers movies, twice, yet I can’t understand the joke in Jonas blog. This can only mean one thing: I have to watch them again now!

Article source: http://openlife.cc/blogs/2012/february/nosql-performance-numbers-mysql-and-redis

I’ve been eyeing the Drizzle project since it started in 2008. Already then there were dozens of MySQL hackers for which this project was a refuge they instantly flocked to. Finally a real open source project based on MySQL code that they could contribute to, and they did. It was like a breath of fresh air in a culture that previously had only accepted one kind of relationships: that between an employer and an employee. Drizzle was more liberal. It accepted also forms of engagement already common in most other open source projects that are based on relationships between 2 or more consenting contributors.

But in 2008 I wasn’t yet ready to engage with Drizzle. Like I said, I worked in a role where I would go to database users and help them use MySQL in demanding production settings. So as much as I admired Drizzle already back then, I needed something that could give me good releases, and support me when needed.

So I stuck with my MySQL relationship – I was employed with MySQL. But eventually our paths separated, as they say, and I then became employed with another MySQL fork, MariaDB instead. I tried to give it my best, but also MariaDB couldn’t satisfy what I really needed. Eventually I left also MariaDB.

With two failed relationships behind me, I tried to be single and free for a while. Solo hacking. Based on what I learned from the MariaDB team I even published my own MySQL builds. You might remember exactly a year ago I blogged a lot about what I called MepSQL. It was quite interesting and I became quite good at building MySQL packages – you could use the MepSQL build tools to easily package any of the forks: MySQL vanilla, Percona, MariaDB and the Facebook branch. You could perhaps call it a meta-fork: I tried to provide technology to unite the fractured forks in the MySQL community.

My plan was to use this as a platform to showcase more of the community action out there in the MySQL ecosystem: patches and enhancements not yet available to users in any of the commercial forks (MySQL itself, Percona, MariaDB). There are lots of them, but just to mention 2 that go mostly unnoticed but are really great: The sqlstats plugin by Anders Karlsson (this is like pt-query-digest but inside MySQL, without logging overhead) and InnoDB row cache by Wen Tong of Taobao.

I suppose in hindsight it is clear that even if it was a solo project, I was showing clear signs of being at least community-curious, if not more. Indeed, it is my firm belief that the community as a whole will always produce more great code than any single commercial vendor can handle.

And then it happened. Drizzle announced their first stable version. I decided I should have a look at it to see what it’s like. I didn’t official abandon MepSQL or any of the other forks, but I lay low with MepSQL and stopped blogging about it. It seemed best to give Drizzle a chance, even if I didn’t commit to it in any way.

I went to last year’s Drizzle Day that took place after the MySQL user conference. (There is one again this year.) There were many other like minded people, everyone was very friendly and welcoming. They even wanted me to do a talk about trends in the MySQL world. When talking about JSON I decided to tease Stewart a little and said that “Stewart could probably do this in a day” and you know what, that’s exactly what he did a week later.

I also pointed out that many community projects choose to make their status legally recognized by joining some non-profit foundation that provides accounting and legal services to them. The Drizzle boys said they hadn’t done that because they just wanted to keep a low profile and enjoy hacking together. But once they realized that these umbrella organizations like Software in the Public Interest are really easy to join and not a lot of paperwork, they thought it was a good idea. They asked me if I wanted to make it happen. It felt good – it was my first thing I would do for the Drizzle project.

By making the project’s non-profit status official Drizzle immediately got a lot of goodwill from other open source community projects. In fact, the ceremony of applying for SPI membership was officiated by Josh Berkus, well known for his contributions in another open source database community called PostgreSQL, but also a Drizzle contributor.

After we had joined the SPI I thought I could probably contribute best in non-technical ways, such as PR. A year ago the Drizzle website was… I suppose “simple” is a polite way of putting it. Actually, it didn’t look that bad, but it was really just one page. There was some talk about the need for something fancier. Brian decreed that the website needs to be either static html files or use a SaaS solution – we were not going to use a lot of effort maintaining our own web server stack. I offered to help in creating the new website. We fooled around with Google Apps for a few days and got nowhere. There was no support for CSS and a weird scripting language that wasn’t JavaScript – we just didn’t get it. Being a long time Drupal user and contributor, I knew I could make a kickass website in no time using that. To obey Brian’s orders I signed up for the free account at Drupal Gardens which is an amazing Drupal service. The wizards and templates that you use to get started literally save you at least 2-4 days of work compared to setting up your own Drupal. But it is also flexible, allowing you to add your own CSS either by point and click or hand coding.

Being a non-profit community project again payed off. When the site was done, it turned out we couldn’t actually point our domain “drizzle.org” to it. This was a feature of the paid tiers. At OSCON I talked to Angela Byron, known as webchick in Drupal circles, and she arranged us to get an upgrade for free. It again felt good to get this kind of help from another open source community. And I should say, big thanks to Acquia, the company behind Drupal Gardens for sponsoring Drizzle in this way.

I have to say I’m pretty satisfied with the new website. I’m not a graphics designer, but have some basic training from a few university courses. Using the Drupal Gardens templates really helped though, I couldn’t have done it without them.

For reasons I will mention below, I felt there was nothing to do PR-wise and I was mainly blocked by waiting for others. I decided to become a Drizzle hacker, you know, just as a way to have fun while waiting. I asked Roland Bouman what would be to JSON what XPath is to XML. He suggested to just embed a JavaScript engine into Drizzle so that people could parse and do whatever they wanted with JSON documents. So I created a Drizzle plugin that does that. It is in the 7.1 RC if you want to play with it.

It should be emphasized that I never really did anything of even this complexity in C++ before. I mean Symbian code yes, but you wouldn’t recognize it as C++ before someone tells you that’s what it is. Even then I didn’t actually code much Symbian either. My point is, it is true what they say: Drizzle code has really been refactored into a clean and modular code base. Writing a plugin is dead simple. It’s great that even a novice like me can approach a complex project like a relational database server and produce a useful, non-trivial feature just in a couple of weeks! This was great validation for me that it is true what they say about Drizzle – the years of refactoring work has really paid of and it is a pleasant project to start hacking on: both socially and from a code perspective.

After success with my first plugin, I went on to extend the JSON HTTP API that Stewart had created. Stewart’s version 0.1 uses JSON over HTTP, but the payload is still a good old SQL query. I’ve worked on a drizzle branch that provides a second api that is true JSON key value queries, similar to Couchbase or MQL. The evhttp library we used didn’t support HTTP DELETE, so I had to stop until I upgraded my Kubuntu version to one that comes with evhttp2. I now have done that, and after DELETE and a way to create a table is implemented, I will blog about this interesting project too. With the rise of both client side and server side JavaScript I really think this could be an interesting API for Drizzle.

If you read Stewarts blog post carefully – or just read the comments where I point this out – you’ll notice there is a bug: Every result set has an empty row at the end. This is not a bug in Stewart’s json_server, rather in the Drizzle Execute API. I traced the function calls made when you use this API and fixed the off by one error. I had become a committer to Drizzle core code.

The Drizzle 7 release of last year has, imho, proven quite stable. I mean, of course it had bugs, but compared to some historical MySQL releases I’d say it is good quality software. Unfortunately it was not a very polished piece of software. You know, it was something a Steve Wozniak would create, but not something Steve Jobs would approve of. In particular, while there was a manual, and it had parts that were quite good (SQL and core functions are actually documented), it wasn’t really useful to get Drizzle up and running. Most plugins weren’t even mentioned in the documentation.

Another problem was that the people that used to build RPM and DEB packages became busy with new day jobs and the 7.1 series deteriorated into just source releases.

This was the reason I stopped doing PR tasks in the Autumn. It seemed pointless to evangelize a website when people would not find any packages to download on said website if they actually went there. Altough it must be said Drizzle is much easier to compile from source than my experience with MySQL was. Especially after I updated the README file to reflect reality. Anyway, I swore I will not post a single blog about Drizzle until there are binary packages available again. I shouldn’t have done that…

The first problem has been vigorously attacked by Daniel Nichter with myself and a few others helping. I’d say the current manual is something we don’t have to be ashamed of anymore. Btw, I have really enjoyed working with you Daniel. Your focus on the end user experience is exactly what Drizzle needs just now, and without you being there I might have lost hope along the way. You are the Steve Jobs of Drizzle, except you are a much nicer person than he was

While there has been some personnel turnover for sure, another thing that has continued to work great is the build and continuous integration process. Mark Atwood is there almost every night (well, it’s night in Europe) and tirelessly merging patches, and giving feedback on those that don’t pass the test suite. Even if some of the core devs have either completely gone or are very passive, it is Mark’s work that really keeps the pulse going. And for all the talk of Rackspace pulling out as a sponsor, there’s still someone submitting patches because there’s a queue building every week. So Drizzle is doing fine, but it is much thanks to Mark who keeps the engine running.

The third thing I think is really great is the Google Summer of Code students. Drizzle has attended and been really successful with this Google program each year, with a high percentage of successfully completed projects. Last Summer 3 students completed their projects successfully, and they are all still active in various ways with the project. VJ Samuel has even become the release manager for the release candidates! I already look forward to next Summer so I can be part of GSoC too.

The thing that wasn’t so great was… have you paid attention what is still missing? The packages. Nobody was doing them. I should’ve realized this earlier. In an open source project, if there is something that needs to be done, you look around and nobody is doing it, it means you have to do it. Even if somebody promises to do something, you look around and don’t see any code actually appearing on launchpad, it means you have to do it.

A thing in the same category was the version number. Drizzle had initially wanted to adopt the Ubuntu release system. But somewhere along the line it just became a datestamp that was really difficult to understand. You needed secret knowledge to know that 2011.03.13 and 2011.11.29 are not the same major version while 2011.11.29 and 2012.01.30 are the same version. Not something Steve Jobs would approve of.

So I submitted a patch that changed the whole build system to produce versions that look like 7.1.31-rc instead. I was a bit nervous of this one. It felt great when my plugins where swiftly approved and merged, and that’s exactly the point with making open source projects modular so you can be very inclusive of new contributors. But here I was touching the very heart of everything. Much to my delight, this code was approved of and after fixing some test failures we finally managed to merge the code and release the first RC with a human readable version number. It even says “-rc” now so you know what it is!

Acceptance of my proposal again grew my faith in the relationship I have with Drizzle. I feel like sometimes we don’t talk enough in the Drizzle project, because the other guys often are busy at work and don’t have time for my emails. It felt good to know they understand what is important to me and approved of it.

Unfortunately the change in version numbers along with some other last minute changes meant that my work on DEB and RPM packaging was obsolete and couldn’t be merged into the RC as I had hoped. I have now pushed a branch that does the DEBs correctly again, but need to also update the RPMs.

Then Drizzle will have binary packages for the 7.1 series and I can break my silence and blog about it again. Oops, guess I already did Yeah, it’s been a pretty great year!

If you are one of those brave souls that are not afraid to compile Drizzle from source, the brand new release candidate can be downloaded here.

Article source: http://openlife.cc/blogs/2012/february/year-drizzle