Sheeri Dot Org

Last month at the Boston MySQL User Group, I went through the meanings of INNER, LEFT/RIGHT OUTER, CROSS, NATURAL joins, how to do a FULL OUTER JOIN in MySQL, and what STRAIGHT_JOIN means. I also explained how to recognize when you want those types of joins, and best practices for the semantics of writing joins and design patterns. Subqueries were explained in this session, and some examples of how to think differently so that you end up writing JOINs instead of subqueries. The slides (slightly different from the slides in the video — due to error correction) can be found at http://technocation.org/files/doc/2010_01MySQLJoins.pdf.

Here’s the video:

The Call for Proposals for the 2010 MySQL User Conference and Expo ended about 6 hours ago. However, birds-of-a-feather sessions (BoFs) have a separate call for proposals. From the MySQL Conference page at http://en.oreilly.com/mysql2010/, select the “Program” menu item, then “Birds of a feather sessions”, and you will be directed to the proper page. Which, for easy clicking, is http://en.oreilly.com/mysql2010/public/cfp/90.

The call for proposals for Birds of a feather sessions closes at 11:59 pm PST on Thursday, February 18th, 2010. Sessions can be added during the conference, but if you submit and your BoF is accepted it will be printed in the schedule.

Note: If you submitted a BoF proposal in the regular call for proposals, it’s much much easier if you submit the proposal again through the BoF call for proposals.

In light of the official Oracle acquisition of Sun, I dug out a presentation video I realize I never officially shared with either the MySQL or the Oracle community. It’s the presentation I did at the 2008 Oracle Open World conference called, “So, you want to be an Oracle ACE?” and is a good resource for anyone who wants to contribute to anything — not just Oracle or MySQL, though certainly it’s based on my experiences with contributing to MySQL.

Oracle has lots of resources for the community. While I have joked about Oracle calling its conference “Open World”, I have also experience it, and the Oracle community first-hand and second-hand — through professional contacts such as my colleagues at Pythian who work on Oracle databases, and also through personal contacts such as my mother who has been to a few Oracle conferences herself.

Like MySQL, Oracle has recognized community contributors. However, Oracle offers more tangible benefits than a photo opportunity and a physical award. Oracle has the Oracle ACE program, with 2 levels: Oracle ACE and Oracle ACE director.

An Oracle ACE is similar to the MySQL Community award, and is a way of thanking community members for their contributions. An Oracle ACE director, on the other hand, has no official counterpart in the MySQL world (yet). An Oracle ACE director has the responsibilities and benefits of being a liasion between the Oracle community and companies that develop Oracle applications (including Oracle itself). The MySQL ecosystem already has some of this in place unofficially — MySQL employees and employees of MySQL-related products reach out to people like me all the time to solicit feedback.

After I won the MySQL Community award for a second time, Dan Norris, an Oracle ACE Director, got in contact with me and asked how the Oracle community could get more contributors, like the MySQL community has. So we devised this presentation to show people how to do it. It was a presentation that was very highly voted on by community members and thus was accepted. Perhaps in the future, MySQL will have a few slots for talks that are chosen by the whole community, instead of a small review committee!

Ronald Bradford’s recent warning to be sure to know your my.cnf sections reminded me of a similar issue that I ran into last summer, where putting the “group” option in both the [mysqld_safe] and [mysqld] directives resulted in a mostly silent problem.

I started noticing this in MySQL 5.1 and it affected both the official MySQL binary and the Percona binary. In trying to be conscientious, I had the following set:

[mysqld_safe]
user=mysql
group=mysql

[mysqld]
user=mysql
group=mysql


However, when the MySQL server started up, the error log showed

[Warning] option 'group_concat_max_len': unsigned value 0 adjusted to 4

This was obviously a problem, but I only started noticing it during MySQL restarts, which was mostly during upgrades to MySQL 5.1. I tracked it down and realized that when I removed the “group” option from the [mysqld] directive, the warning did not come up.

The problem is that [safe_mysqld] sees “group” as the “group” option, but [mysqld] does not know about the “group” option. The MySQL server allows the shortest unique identifier of an option to *be* that option. Thus, “group” is an acceptable abbreviation for “group_concat_max_len”.

So mysqld was taking:
group=mysql

and translating it to:
group_concat_max_len=mysql

but “mysql” is a string, not a number, so MySQL tried to be helpful by converting to a number….so it was as if I stated:
group_concat_max_len=0

I filed a bug for this back in June:
http://bugs.mysql.com/bug.php?id=45379. The response was “If 3 different people ask about removing this feature reclassifying report to feature request with new synopsis.”

So, a second moral: make a bug report if you want things to get changed, and if you see a bug report for a problem you’re encountering, make sure to add your voice so that MySQL understands that an issue is indeed serious.

On first glance, it looks like TEXT and VARCHAR can store the same information. However, there are fundamental differences between the way TEXT fields and VARCHAR fields work, which are important to take into consideration.

Standard
VARCHAR is actually part of the ISO SQL:2003 standard; The TEXT data types, including TINYTEXT, are non-standard.

Storage
TEXT data types are stored as separate objects from the tables and result sets that contain them. This storage is transparent — there is no difference in how a query involving a TEXT field is written versus one involving a VARCHAR field. Since TEXT is not stored as part of a row, retrieval of TEXT fields requires extra I/O overhead.

Maximum VARCHAR length
The maximum row length of a VARCHAR is restricted by the maximum row length of a table. This is 65,535 bytes for most storage engines (NDB has a different maximum row value). Theoretically the maximum length of a VARCHAR is 65,536 bytes. Overhead further limits the actual maximum size of a VARCHAR.

Storing the length of a VARCHAR field takes 1 byte if the VARCHAR field has a maximum length of 0-255 bytes; if it is greater than 255 bytes, the overhead to store the length is 2 bytes. If the VARCHAR field allows NULL values, that adds additional overhead — every table uses 1 byte of overhead for each set of 8 fields that allow NULL values. If the VARCHAR is the only row in the table, and does not allow NULL values, the maximum length allowed for VARCHAR is 65,532 bytes.

Keep in mind that that the number in VARCHAR(x) represents number of characters, not number of bytes. Therefore, you may have difficulties trying to define a table with only VARCHAR(65532) if the character set uses multi-byte characters, such as UTF-8.

If you attempt to define a VARCHAR value that is longer than allowed, you will run into an error such as 1118 or 1074:

ERROR 1118 (42000): Row size too large. The maximum row size for the used table type, not counting BLOBs, is 65535. You have to change some columns to TEXT or BLOBs.

ERROR 1074 (42000): Column length too big for column 'col_name' (max=[max number here]); use BLOB or TEXT instead

Maximum TEXT length
The maximum size of a TEXT data type depends on which type of TEXT data type is being used. Because they are stored as objects, the only row overhead in the table object is a pointer (8 or 16 bytes). Here is a list of the maximum TEXT length, and the overhead (in the TEXT object):

• TINYTEXT – up to 255 bytes, 1 byte overhead


• TEXT – up to 64 Kb, 2 bytes overhead


• MEDIUMTEXT – up to 16 Mb, 3 bytes overhead


• LONGTEXT – up to 4 Gb, 4 bytes overhead

DEFAULT values
MySQL does not allow TEXT data types to have a default value other than NULL. VARCHAR fields are allowed to be created with a DEFAULT value.

Conclusions
Because of the storage implications, it is preferable to use VARCHAR instead of TINYTEXT.

If you need to have a DEFAULT value that is not NULL, you must use VARCHAR (or CHAR).

If you need to store strings longer than approximately 64 Kb, use MEDIUMTEXT or LONGTEXT. VARCHAR cannot support storing values that large.

Make sure you are aware of the effects of a multi-byte character set. VARCHAR(255) stores 255 characters, which may be more than 255 bytes.

We’re looking for an intermediate to expert MySQL DBA who can jump right in. We have several offices in Ottawa, Boston, Sydney and Hyderabad, India.

Working at Pythian is different than working in-house or as a consultant, because you’ll be making your contributions available to each of the customers assigned to your team, allowing you to see more use cases, more technologies, and work with more and varied environments, all the while building interesting and long-lasting working relationships with your peers. I will gladly sponsor a work visa for the right candidate anywhere in the world.

We support some of the most interesting internet-scale MySQL environments in the world, see http://www.pythian.com/about/customers/ for a sampling of customers across many industries.

Top Criteria

* Outstanding MySQL production administration and server tuning skills, bonus points for cluster, partitioning, and major implementation and upgrades experience
* Exceptional troubleshooting, problem-solving and learning skills
* Superior productivity per hour and overall getting-the-job-done-right abilities
* Fluent communication skills in English, both written and oral, are mandatory. Second or third languages are also a plus (we have customers all over the world and are always eager to add a language to our repertoire)
* Stored procedure, trigger, view and nonstandard storage engine experience a plus (such as SoliddDB, the Amazon S3 engine, Falcon, etc.)
* Interest or experience in publications, blogging, and presentations a plus

Job Highlights

* Work on an elite team of DBAs for an elite and growing group of customers; you’ll learn more here in a year than in any in-house DBA job no matter how long you stay; this is personally guaranteed by both me and Paul Vallee, founder of the Pythian Group.
* Work and gain valuable experience on every mainstream platform, including AIX, HP/UX, Solaris, Linux, Tru64, Windows, etc. We many not run MySQL on all of those platforms, but we certainly run enterprise infrastructure on one team or another on each of those and more. If you’re interested in technology, there a lot of it in use here and that makes it a great place to be.
* Learn and support every mainstream technology and feature, including cluster, advanced replication, GIS, etc. etc.
* Work across multiple industries including health care, manufacturing, media, dot-com, education, retail, services, and many more.
* Work in a company that values hard work, not long work.
* Work in a company that allows you to research and write articles, presentations and blog posts on company time, and pays for you to present your research at just about any user conference worldwide.
* There is also the obvious opportunity to learn Oracle and SQL Server, if you don’t already know those platforms. We here at Pythian are about the data, first and foremost. However, if you have no desire to work with Oracle and SQL Server, you do not have to.
* Consult for high-profile customers all around the world without leaving the office. This is really the most awesome part; almost any other job on the planet that lets you see this much tech has you traveling like mad. Not us.

To Apply

Send us an email with a one-paragraph introduction of who you are and why you are exceptional at hr@pythian.com. Feel free to attach your resume in any format — text, Word, PDF, RTF, ODT, whatever makes you happy.

The O’Reilly MySQL Conference & Expo 2010 Call for Participation ends in just under 3 weeks. I am on the conference committee, and thus get to see and review all the conference proposals.

This blog post will briefly explain the how each part of the proposal is used, then have a list of what not to do in your conference proposal, and end with a checklist of questions to go over your proposal before submitting. Click here if you want to skip to the checklist.

The proposal has several parts.
Title: This is the title of your presentation. This shows up on the schedules (online and print).
Description: This description appears in the conference program, and on the online session page.
Topics: These are the tracks that apply to your session. Sessions are shown online by time slot (the schedule), and by track.
Session Type: what type of session you are proposing. Most folks will propose a 45-minute conference session.
Abstract: This shows up only on the online session page.
Audience Level: Who the material is intended for
Additional notes: This is only seen by reviewers.
(and then you go on to add speakers)

Even if you are a veteran speaker, it is important to know what this all really means in terms of writing a good proposal. For example, only the title and speaker(s) show up in the online and printed schedule. The description shows up in the conference booklet, and the abstract only shows up on the web page for that session.

With that in mind, how not to write a good conference proposal:

Have a vague title
Last year, I gave a 3-hour tutorial entitled “Understanding How MySQL Works by Understanding Metadata”. My first title was “I never metadata I didn’t like.” I still think the first title is awesome, but the conference organizers contacted me and said that the title was hard to understand if you were not a native English speaker, and said absolutely nothing about the workshop.

Remember that the title and speaker is the only information that shows up on the online and printed schedules. When someone is rushing from one session to another, they may only look at their schedule. Will your title remind them what your session is about? The first title I tried to use would only evoke “that one about the metadata” — which might not be enough information. The title that I changed to is much more descriptive, and would evoke “that one about using metadata to figure out MySQL internals”.

Have an unbelievable premise
If you claim something difficult to believe, such as “The new Connector/Fast will speed up every single MySQL query and can be used in Java, PHP and .NET environments”, be ready to back it up. In the “Additional notes” section, provide pointers to websites, documentation and benchmarks so we believe your claim. I would hate to miss out on an awesome product because it seems “too good to be true”!

Short description or abstract
The description and abstract are how the conference committee members are going to be convinced that you are going to present a good topic. If your entire proposal is:

Title: MySQL Performance tuning
Description: This presentation will take you through how to configure MySQL for the best performance. Overall MySQL options and specific MyISAM and InnoDB options will be discussed. Learn how to configure MySQL in the best way for your environment!
Abstract: This presentation will cover how to tune MySQL. It will also point out the many tuning possibilities that can be done while the server is running and do not require a restart.

As a conference reviewer and an attendee, I have no idea if you have any grasp of the subject yourself. As a conference reviewer, I want to approve good sessions. The presenter may be an expert, or they may be a someone using the information they found by doing a Google search on “MySQL performance tips”.

As an attendee, I would trust that this session delivers what it promises. If it does not, I will be disappointed and frustrated.

Too much (or too little) material
The previous example promised to deliver a lot of material — tuning MySQL in any environment is a lofty goal. That is definitely too much information for a 45-minute presentation.

If you have even a small question as to whether you have the right amount of material, start outlining specifically what you want to cover in your presentation. You could actually start making the slides, or you could be slightly more vague. If you were the presenter of the previous example, thinking about the presentation might go like this:

–MySQL system variables
— with explanations of what they do
— how to tune them (ie, what values are accepted, how to figure out what values are good for you)
— the related status variables to see if you need to tune them

That seems short, but there are over 250 global system variables. Even if you were only explaining the system variables, not the status ones, that gives you 10 seconds for each variable, for a 45-minute presentation.

Sales pitch
If you are doing a presentation about using a particular technology, make sure it’s not a sales pitch. If you want to do a sales pitch, do not submit a proposal. If you are part of the company that owns the product, particularly if you are high up in the organization or in marketing/sales, co-present with an *independent* technical person, and talk with them about what people want to learn about your product.

For instance, the presentation could explain the high-level details of how to install and migrate existing data to your product — for a new storage engine, it could be “install the binary provided, then install the plugin with 2 MySQL commands (no need to restart MySQL), then use ALTER TABLE to convert an existing table to the new storage engine.” Or it might be “Export all the data with mysqldump, install the binary, import all the data using tool X”.

Have a vague description
If your session is accepted, it has to compete with up to 9 other sessions in the same slot (plus the desire for a nap and conversations with fellow attendees). If your title and/or description is vague, people are not going to know if your session is something they should attend. For example, here’s a sample (made up by me) bad title and description:

All about MyISAM
In this workshop, attendees will learn all about MyISAM and what it’s good for. This often-overlooked storage engine is really powerful in many situations. Find out tips and tricks for high volume MySQL usage, and where MyISAM can be used with better performance than InnoDB.

Who should go to that session — developers to learn about how to write performant MyISAM queries? DBAs to learn about performance tuning and debugging for MyISAM? DB Architects to learn about how to create optimal schemas (including indexes) for MyISAM?

If I did not know anything about MyISAM, I would have no idea if I should go to that session or not.

After you write your proposal, put yourself in the mindset of a potential attendee. What do you need to say to him/her to get them to understand that your workshop will help them? If you have a general topic, such as in the example above, your potential audience is all those folks who hear “Use InnoDB for everything.”

Put specifics in the description, like:

Even though MyISAM has table-level locking, it is actually more performant than InnoDB for a high-volume logging table.

See how that gives you a specific use case? A potential attendee with a relatively closed mind will gloss over the original description, because they think “Eh, MyISAM is only good for reporting queries, and I have a lots of short queries.” With examples such as “for a high-volume logging table”, this potential attendee will think, “Oh, I have a few logging tables that are InnoDB, I’ll go to learn how MyISAM could make them faster!”

Either that, or “That’s not true! I’ll go to the workshop to prove to them how wrong they are!” and be pleasantly surprised when they learn that yes, it’s true, MyISAM is better in that case.

Non-meaningful statements
Often, attendees read the session descriptions when they’re tired or rushed. Try to put the most important information first — otherwise people might get bored because they are not reading anything useful. For example, a description for a session on query optimization may start with:

Everybody wants to increase query performance, but in reality there is no one way to make every query faster. Server tuning variables can help. The real power is in optimizing the queries and the schema.

Compare that to the following sentence to start the description:

Optimizing the queries and the schema is the most powerful way to make every query faster, though tuning server variables can help in some cases.

(note that both these descriptions are not good as *complete* descriptions of a session. But cut out all the junk up front. If you end up using words like “obviously” or phrases like “everybody wants” or “everybody knows”, chances are you can probably delete the entire sentence.)

Assuming you are well-known
Perhaps you are famous in the foo community, and are doing a presentation on how to use foo with MySQL. The conference committee, and the conference attendees, may have no idea who you are. Or worse, they may have been exposed to an early work where you made some mistakes, and have a skewed view of your knowledge level.

For instance, if someone was exposed to just a few blog posts I made, including one I made early on that made a suboptimal recommendation, they might think I know very little about MySQL.

Assume that your proposal is all that the conference committee knows; put information in your bio and the Additional Notes pointing to your blog, previous presentations you have done (at places other than the MySQL conference), and other sources that will show that you can do a good presentation on your topic.

Before you submit your proposal, ask yourself:
0) Will non-native English speakers understand my title/description? Being funny or cute can backfire; if you want to make sure you get the joke in, put it later in the description.

1) Will someone who has just “heard of” what I am presenting be able to figure out from the title and description if they should come to my talk?

2) Is my topic too long or too short for the time allotted (45 minutes for most sessions)?

3) Have I shown the conference committee that I’m knowledgeable in the subject, and that hard-to-believe material is true? If not, use the Additional notes field for information you want only the reviewers to see. If you have a demo or draft (or more!) of the presentation, put it on a web site somewhere and point reviewers to the URL they can access.

4) Can I write down points people will learn from my session? For a 45-minute session, try to write down 10 points. For example, Want faster queries? has a very short description, but the abstract itself is a list of 6 bullet points, and the last bullet point “Common mistakes” can easily be turned into the 4 most important mistakes people make.

5) Will someone who has 5 minutes to decide on and get to the next session be able to make a good decision on whether or not they should go to my talk based on the title?

6) Have I gotten rid of statements and introductory phrases/sentences that have very low meaning?

7) For presentations about technology you work on, is the presentation suited for DBAs or developers? A presentation should balance “why you should use this” with “when not to use this” and “the problems you might run into”.

8) Is it clear to a person who already knows most/all the information in my talk that they will *not* be interested?

In this article I am responding to many parts of Monty’s post at http://monty-says.blogspot.com/2009/12/help-keep-internet-free.html which are just plain not true, or are exaggerations.

I will give my own answers to the self-interview questions Monty provides, as I feel he is using his name and popularity to spreading fear that is not warranted.

Q: Why don’t you trust that Oracle would be a good owner of MySQL?

I cannot say whether or not Oracle would kill MySQL. However, I have already stated I believe Oracle will not kill MySQL. This is based on the fact that Oracle has had the chance to kill MySQL for several years, by making InnoDB proprietary, and has not.

Folks can debate until they are blue in the fact about whether or not it is in Oracle’s best interest to kill MySQL. Actually, I see more logic in the arguments that Oracle should kill MySQL, than in the arguments why it should not. But the fact remains that Oracle has had better opportunities to kill MySQL and has not. The “why” does not really matter; Oracle has put in development effort into making MySQL better, with InnoDB, instead of killing off MySQL — years before Oracle had any possible ownership.

Q: Can Oracle change the license of MySQL ?
Monty’s entire answer is:

Oracle can’t change the license for old versions of MySQL. They can however change the license for all new code and put a majority of all new development on the new closed source version. Over time the MySQL GPL code from Oracle will be as usable as Betamax video cassettes. It is just not enough to give promises for the next 5 years as MySQL will be needed in the market for years to come.

Again, I point to the fact that Oracle could have done this 5 years ago with InnoDB — several years before Percona and Monty AB came along with their own forks. Read Jeremy Zawodny’s post from 2005 and especially the comments. For instance:

Comment: “this does put a crimp in MySQL’s dual licensing model, because they won’t necessarily be able to sell a MySQL/InnoDB solution commercially unless Oracle agrees.”

Fact: The comment is true — however, Oracle did agree, and MySQL did sell a commercial version of MySQL+InnoDB for a while (remember the big problems with the community/Enterprise version split? MySQL sold MySQL, with InnoDB, and Oracle allowed them to.)

Comment: “InnoDB was the only thing MySQL had going for it to seriously compete with Oracle, and Oracle knew it. Now that Oracle is acquiring InnoDB, in a year ot two, we’ll see Larry Ellison but the major squeeze on MySQL AB to either pay up for licensing InnoDB or not include it at all.”

Comment: “Now, what happens when Oracle decides to put a little squeeze on that license cost or heavily influence the evolution and support of that product? MySQL customers and prospects will have to reevaluate their database investments and analyze short and long term impact on their businesses.”

Comment: “I’ve been an Oracle customer for 15+ years. Based on that relationship, I have no reason to believe that Oracle has anything but their own interests in mind. MySQL users should be very worried.”

Fact: InnoDB is still GPL, still freely distributed with MySQL. The fears of these commenters were unwarranted. Just as the fear Monty is trying to spread is unwarranted.

Q: MySQL is free (GPL) software, how could anyone be able to kill it?

Monty says: “GPL only guarantees that the (old) code will always be free. It doesn’t guarantee the economics around the project or that anyone can or will develop it further.”

He is factually accurate here. However, he continues to spread fear that MySQL will die because the “economies around the project” will suffer. This is actually contradictory to what the general public wants, by Monty’s own petition:

(From http://helpmysql.org/en/stats at the time of this writing):
Total number of confirmed sign-ups: 691
Suggested solutions:

1) MySQL must be divested to a suitable third party that can continue to develop it under the GPL. 650 94.1 %

2) Oracle must commit to a linking exception for applications that use MySQL with the client libraries (for all programming languages), for plugins and libmysqld. MySQL itself remains licensed under the GPL. 357 51.7 %

3) Oracle must release all past and future versions of MySQL (until December 2012) under the Apache Software License 2.0 or similar permissive license so that developers of applications and derived versions (forks) have flexibility concerning the code. 383 55.4 %

Look at that — over 94% of responders think MySQL should continue to be released under the GPL. But remember what Monty said?

“GPL only guarantees that the (old) code will always be free. It doesn’t guarantee the economics around the project or that anyone can or will develop it further.”

Oracle has kept the GPL licensing for InnoDB for 4 years. Oracle has promised to keep GPL licensing for MySQL for at least 5 years. They are doing as much as they can to guarantee that MySQL will continue to use the GPL. Why is there confidence that a third-party will keep MySQL under the GPL license? It really depends on who the third party is! Oracle has a proven track record of keeping MySQL’s critical code (InnoDB) open and GPL’d.

Using the GPL is not what Monty wants — he wants to be able to have the “economy” around MySQL, by having the exceptions noted in suggestion 2, or a different license entirely, as noted in suggestion 3. He writes:

“The fork can’t be used with other products that are using MySQL as a building block for their closed source applications.”

Factually, this statements is true. But it is misleading; plenty of products can be closed source and use MySQL. Under the GPL, it is not legal to redistribute a closed version of MySQL. Effectively, this means a closed source product cannot *embed* MySQL. MySQL currently is dual-licensed and sells embedded licensing, so that closed source products can in fact redistribute a closed version of MySQL.

Crystal Reports is an excellent example of a legal, closed-source commercial product that can run using MySQL as backend storage. Crystal Reports does not have to pay an embedded license, because they do not embed MySQL in their product.

Anyone can redistribute MySQL, for free or commercially, so long as they keep the source open. MySQL itself did this, with the Enterprise version.

Monty does not want MySQL to be GPL’d. He says this himself:

“It is wishful thinking to claim that released under the GPL license is enough remedy for Oracle”

Ask yourself this: If Oracle sells MySQL to a third party that keeps MySQL GPL’d, will Monty use his popularity to go after them, until they change the licensing? What’s the difference between Oracle owning MySQL and keeping it GPL, and a different company owning MySQL and keeping it GPL? There is no difference to the community. GPL is GPL, no matter who owns it, and the problem is not Oracle owning MySQL, it’s that Monty does not want MySQL to be GPL’d.

Note that solutions 2 and 3 in the poll, exceptions and alternatives to GPL, have just over 50% support, much less than the 94% that agree MySQL should be GPL’d. I can hear the argument now — “Well, that’s still over half, that’s the majority!” Except that the poll is self-selecting for people who do not want Oracle to acquire MySQL. There are many, many people, including myself, who think that it is OK for Oracle to buy MySQL and keep the status quo of the GPL — and those opinions are excluded from the poll.

I do not have a different poll, but I feel that most people that are happy with (or even just OK with) Oracle acquiring MySQL and keeping the license GPL (similar to solution 1, with over 94% agreement to those who do not want Oracle to acquire MySQL). Therefore, if there was a regular poll, not Monty’s “petition plus a poll”, I feel we would see similar near-consensus that MySQL should stay GPL, regardless of who owns it.

Q: You are doing your own fork of MySQL called MariaDB. How can you do that if it’s so hard to fork MySQL?

Monty says: “When we started with MariaDB, MySQL was owned by Sun, which has a lot of reasons to keep MySQL alive and well. We had seen no changes in the policies of SUN regarding licenses or costs. In this scenario it’s possible to do a successful fork if you can provide added value to what Sun is doing (like working more closely with the community).”

There is no difference between Sun or Oracle here — only Monty spreading fear, uncertainty and doubt (FUD) that Oracle *might* close the source of MySQL. As I said before, people can argue about what Oracle might or might not do. History has proven that Oracle will keep MySQL open source and GPL’d, and for me that is stronger than any conjecture of what Oracle *might* do.

Q: Why have a lot of companies put money into developing Linux? Doesn’t Linux have the same problems with GPL as MySQL?

Monty says:
“While Linux is indeed distributed under the GPL, as is MySQL, Linux has an exception that allows anyone to run any kind of applications (including closed source applications) on top of Linux.”

See the argument above about embedded licensing, complete with naming Crystal Reports as a successful, legal, commercial, closed-source product that uses MySQL as a backend.

Q: Why are you working with the EC to try to block the deal?

Monty’s answer:
“I have two main objects in my business life:

* Save the product, that I worked on for 27 year, from getting killed as an open source project.
* Ensure that the core developers of MySQL, who I have worked with for many years, get a good ‘home’ where they can continue to develop MySQL.”

Oracle has already promised to keep MySQL alive as an open source product, so the first item does not apply as a valid reason. As for the second item, if he cared so much about the core developers of MySQL, why does he continue to let Sun lose tons of money while this deal stagnates? Why not just encourage Percona to hire them all to work on Xtradb? (Monty has limited MariaDB to 50 employees, because after that it loses the “family feel” — which I agree with — so MariaDB could employ some, but not all, of the developers).

This post is getting long, but here is a good clue that Monty is spreading FUD — he makes “the sky is falling” and “slippery slope” arguments:

“If the deal is approved based on the fact that ‘MySQL can be forked’, that will be a big blow to open source Software.
It means that open source software is not protected for anticompetitive measures and it will be ok for big companies to freely buy up their open source competitors and kill them.”

Monty cannot use facts to win his case, so he is resorting to scare tactics by effectively saying: “If Oracle acquires MySQL, open source software is doomed!”

Another good FUD tactic — blame the enemy: “We also have to recognize that it’s Oracle that is holding Sun hostage just to get MySQL. Oracle could have got the deal closed very quickly if they had divested MySQL and just forked it.”

Actually, it is Monty that is responsible. Before he started his campaign against Oracle, the EC would have approved the deal. Monty is spreading fear by doubting what Oracle will do with MySQL in the future. The future is uncertain; it is also possible a third party will close MySQL’s source.

Monty’s argument is like a bank robber saying “If everyone would have just stayed on the floor, I would not have had to shoot.” That is indeed a factual statement — just like Monty’s accusation that Oracle could close the deal quickly if they listened to his demands.

In short — Oracle has a proven history of keeping InnoDB free and open source. There is no reason to believe they would not keep it free and open source, and they have promised to keep it free and open source for the foreseeable future — 5 years is a LONG time in software development terms. For example, Ruby only gained acceptance only 3 years ago.

The bottom line: As both a community member of MySQL, and a service provider, I am not worried about Oracle buying Sun and acquiring MySQL in the process. There is no validity to the argument that Oracle will slow down or stop MySQL development — it is not possible, with various forks already in heavy development, and it is not probable, because Oracle has owned the InnoDB codebase for 4 years and has not slowed that development down.

My bias

I use MySQL, and want to see it continue to be developed. I work for The Pythian Group, providing DBA services to clients running MySQL. Together with my MySQL colleagues at The Pythian Group, the services provided run the gamut from rotating logs, monitoring, performance tuning, designing and implementing and optimizing database architectures and schemas and queries and debugging problems throughout the full stack. The only service we do not provide is code patches.

Some of our clients use MySQL Enterprise (and used the binaries when they were different), others use Google patches and the Percona fork of MySQL, and many stay with the official MySQL binary, or popular distributions’ packaging of the official, documented MySQL source code.

If anything, my bias runs more towards “I want to see MySQL continue to be developed” because patching is the only service Pythian does *not* provide.

Does Oracle lose money because of MySQL?

The statement “There is overlap between the niches that Oracle and MySQL fills” is true. The Pythian Group provides system administration sercvices, and DBA services for Oracle and SQL Server in addition to MySQL. We have worked with many clients who want to switch from Oracle to MySQL, in order to save money.

However, in most cases, it is either cost-prohibitive or impossible to switch from Oracle to MySQL. Because migrating often requires significant amounts of effort, many organizations decide to keep the current applications on Oracle and consider starting new projects on MySQL — particularly small transaction, high-volume applications, including web 2.0 applications (for example, a Facebook application).

Is Oracle losing business there? Perhaps. Many companies just do not have the money required to develop technology using Oracle. Microsoft has combated this problem by offering free software (including their SQL Server) and services to small businesses (one such program is here). Many companies choose Postgres or MySQL by default because it is free, or because it is already in use unofficially in their organization.

On the flip side, MySQL loses plenty of business to Oracle and Postgres for lacking some features, or having features that are not well-developed enough. For one client, not having a MySQL equivalent of SQL Loader was enough to stop them from converting from Oracle to MySQL. Other clients have a difficult time figuring out what is the lesser of two evils — Oracle’s well-developed partitioning feature costs $40,000 per server while MySQL’s partitioning is free, but has only basic functionality.

Why I feel Oracle will not slow down MySQL development

If Oracle wanted to slow down MySQL development, they could have put barriers in place when they bought Innobase in 2005. Four years ago, there were no popular forks of and patches to MySQL. The fact is that when Oracle bought Innobase in 2005, there was no alternative to using InnoDB for high-speed, high-concurrency, and high-volume ACID-compliant transactional needs. Thus, if the bottom line was the issue, Oracle would have slowed down InnoDB development or closed the source years ago.

In fact, Oracle actually makes money from MySQL, because Innobase (which Oracle owns) sells the InnoDB Hot Backup program, the most popular hot backup program for InnoDB and MySQL (the free Xtrabackup has started to gain market share, but has not surpassed the official hot backup program yet).

I have had several occasions to talk with Ken Jacobs, who oversees InnoDB. Every time I have talked to him in the past 5 years, he has expressed a commitment to developing InnoDB. There is absolutely no reason to believe that Oracle would put resources into developing InnoDB for 4 years, then turn around and throw away that hard work by somehow slowing MySQL development.

Particularly now that there are InnoDB alternatives — commercial and free. Why would Oracle put money and business into the hands of other companies? If Oracle puts more resources into developing MySQL, they can reap the benefits — including producing more storage engine plugins, that could be free or commercial. Another important fact: MySQL — first as owned by MySQL AB, and then Sun Microsystems — attempted to develop an alternative to InnoDB after Oracle bought Innobase. To date, Falcon has failed to provide anything other than an alpha release.

Why I am wary when others think Oracle buying MySQL is a bad idea

When others spread the fear, uncertainty and doubt that Oracle will somehow kill MySQL, I consider the source. Many people weigh heavily on the fact that Monty Widenius, founder of MySQL, is doing everything in his power to avoid Oracle acquiring MySQL. However, I do not put much weight into his opinion — right now Monty owns a company that has created a MySQL fork, and he wants rights to be able to sell embedded and non-GPL’d versions of his MySQL fork.

Many of the publicly available and popular patch sets (Google/Facebook) and forks (Drizzle/Percona) came about because MySQL — back when it was owned by Monty — was not able to accept patches from community sources quickly enough for the community. Even today, with Sun owning MySQL, a feature patch can take years to get back into the source code, due to this legacy Monty left behind.

Conclusion

While it is theoretically possible that Oracle could decide to slow the growth of MySQL, it is not probable — if Oracle wanted to damage MySQL, Oracle would have caused a lot more damage a long time ago. The FUD about Oracle slowing development MySQL are not valid, and not true. The motivations behind those spreading this FUD are monetary and selfish. As a community member, I have seen Oracle put plenty of time, money and effort into developing InnoDB. I look forward to even more of Oracle’s resources being used to develop MySQL further.

According to the official lifecycle calendar at http://www.mysql.com/about/legal/lifecycle/#calendar, active support for MySQL 5.0 (including regular binary updates) will end on December 31st, 2009, which is about 3 weeks away.

Many folks are still using MySQL 5.0.45, as until October that was the package that came with RedHat. That was released in July 2007, over 2 years ago!

Upgrading to MySQL 5.1 is not difficult, though it requires more steps than just upgrading the packages.

There is a list with all the changes made that might affect the upgrade process at http://www.pythian.com/news/1414/new-in-mysql-51-sheeris-presentation/. This includes which variable names have been deprecated and changed, as well as how to upgrade stored procedures, functions, triggers and views so they work properly in MySQL 5.1.

I hope this helps folks out, and please feel free to ask any questions. Pythian is available to assist you in the upgrade process, just contact us if you want to engage our help.