Pythian Group

“There are 10 types of people in the world — those who understand binary, and those who don’t.”

The term “binary” in MySQL has many different meanings. How many can you come up with? I have 6, but I am willing to believe there are more!

0) “Binary distribution” is the name for the package that contains a binary. Another use is “binary installation” but that’s pretty much the same usage pattern as “binary distribution”, so I won’t count “binary installation” as a separate usage.
1) “Server binary” or “client binary” is the actual program (mysqld, mysql).
2) “Binary format” is a compressed format. For example, DECIMAL is stored in a “binary format” — each group of nine digits is compressed into 4 bytes.
3) “Binary log” is the change log. You can argue that this is an extension of #3, because the binary log is a compressed log, but “binary log” is encountered ubiquitously in the MySQL world, and “binary format” is somewhat obscure knowledge.
4) “Binary CHARSET” – sets the collation to be case-insensitive. For instance, utf8_bin and latin1_bin are the binary collations for the utf8 and latin1 character sets, respectively.
5) “Binary string” – a byte string. This is also known as the BINARY data type. There is some kind of wit/pun in the fact that a number in binary is actually a “bit string”.

Any more I missed? There are over 1600 mentions of the word “binary” in the 5.0 manual!

Recently I had an interesting issue crop up. Due to an unfortunate migration incident in which involved master/master replication and not checking to see if replication was caught up, we ended up with an infinite replication loop of a number of SQL statements. awk helped immensely in the aftermath cleanup.

The basics of the replication infinite loop were Read the rest of this entry . . .

The MySQL Community version is different in theory from the Enterprise version in relation to the following points:

0) It’s free
1) It has community patches
2) It is released less often
3) It is tested less strictly

In reality, the first two differences are not applicable — the binaries and source code for Enterprise can be freely and legally downloaded at http://mirror.provenscaling.com/mysql/enterprise/. The process for adding community patches to the MySQL source code has not been changed sufficiently to be able to actually add community patches and encourage more community development.

I understand that MySQL (and now Sun) needs to make money. I also understand that development takes a lot of effort, and seeing an ROI is important. The Community/Enterprise split was designed to have tradeoffs on both sides. However, currently there is no benefit to running the Community version.

While I would love to magically make community contributions easy to put into a Community version of MySQL, logistically that’s not possible right now. I do have a solution that is possible right now, that takes very few additional resources, and is something I think will be acceptable to the MySQL community and to Sun — assuming the MySQL executives can admit that the Community version has not been working out.

I propose to make the Community release an older version of an Enterprise release. In this way, Enterprise users still get value in having bugs fixed and features added first, and Community users can choose to upgrade if they want the latest features. There is very little overhead in having Community releases, with no overhead in having to manage two trees/branches/whatever from both a code and build standpoint. Maintaining the promise of immediate security releases, 4 code releases per year and 2 binary releases per year becomes trivial.

The question is, of course, how far back the Community version should go. And should there be a delay (ie, release the January Enterprise version as the June Community version) or not?

I recommend that security releases be immediate (as they currently are) and for all other releases there should be a delay of at least 6 months, perhaps 1 year. Certainly that’s enough of an incentive to get customers to upgrade without having folks feel like the Community ersion is crippleware.

What do folks think of this as a solution to the Enterprise/Community split dilemma?

In http://www.mysqlperformanceblog.com/2008/07/01/should-we-proclaim-mysql-community-edition-dead/, Peter Zaitsev wonders if MySQL’s community edition is dead.

The title of Peter’s inquiry is somewhat misleading, as the database itself works fine. He clarifies a bit with, “there suppose to be 2 yearly binary releases (which are overdue) and 4 predictable yearly source releases, which we have not seen either.” I thought it was clear that “2 per year” doesn’t mean “one every six months”. It’s been eight months, sure. And I don’t actually believe that MySQL is going to have one source release per month until November, to make up for the lack of source releases. However, it’s certainly possible, if not probable.

The fact remains, however, that if you’re just looking for stable, recent, binary MySQL Community release, you might not find it. MySQL offers two out of three — stable and binary Community releases. Not recent, but I think it’s okay to charge for the most up-to-date version. In my experience only about half of the production environments out there have switched to 5.0, and many are running 4.1 and 4.0 still.

At the low end, a license costs just under USD$600. The requirement to buy a license to get the most recent version is a mere inconvenience, not a business-stopper. It’s not like MySQL is forcing everyone to run on version 3.23 unless they pay $10,000 per license. Charging a modest amount for the most up-to-date version is not a bad thing.

It would be nice to have been aware of that ahead of time, but MySQL as a company has not been so great at organizing and having all its ducks in a row. In fact this is where I hope Sun can really help MySQL out, as it has a reputation (a deserved one, in my experience) of being more highly organized.

Have you heard of Hanlon’s razor? “Never attribute to malice that which can be adequately explained by stupidity.”

Read the rest of this entry . . .