Drizzle

(Reposted from blog.krow.net)From the 451 Group:“MySQL flirted with the open core licensing model in early 2008 with plans to introduce new features into Enterprise Edition that would not be available under an open source license.”MySQL didn’t flirt ... [More] with, it was going to do it. Why? Because we were asking the question, “how do we pull in customers to make more money”. MySQL was going to put the new backup API, which never materialized, into an Enterprise branch. It was a lousy idea for the following reasons:1) There was no internal API in the server for this, so the engineering was going to be messy and expensive. 2) We didn’t own the technology that was needed to even do this (Oracle owned Hot Backup)3) Percona has an awesome tool for doing this, that is Open Source (http://www.percona.com/software/percona-xtrabackup/)4) Backup is a core feature everyone needs, and some of those “everyones” are the folks who manufacture tools that you want to have work with your product.5) When we were going to announce it, we hadn’t even written it/completed it. It was vaporware. It would have been a horrible move, and would have caused Chaos for no particular reason. It was dead on arrival, and when it was to be announced as a strategy since it didn’t even exist. Lets look at Oracle’s move. Both the authentication module, and the Thread Pool come into the MySQL server as plugins. If the engineering of the MySQL server continues in the current direction (which is somewhat flattering to Drizzle I might add), then they are on a good path (if I can find my blog entry where I talked about this as a good strategy, I’ll link back to it here). Much of the hubbub around Open Source, Community, etc, in regards to this are a bit inflated I feel. They haven’t touched the core product, and they are creating API. Are they possibly hurting themselves in regards to ubiquity?Doubtful. Would I pick those two pieces? No, but they aren’t the last two I would pick either. If Sun had continued as a company? Something similar to this would have been done as well.From an engineering and usage stand point?The first person who sniffs at the authentication mechanism who knows anything about security is going to freak.The Thread Pool can only be used by a very limited number of users (and there are some restrictions on what can be done in the server while it is in use). MySQL’s IO was never designed for the Thread Pool, and there is a lot of engineering work that would need to be done to make it work. Still? People will use both, and I am betting some customers will want them badly enough to pay. If they are really badly needed? Well then someone will write an open source version of both.I have no great love of Oracle, but this is really not a big deal at all. The original GPL’ing of the Public Domain/LGPL clients was a much bigger deal. [Less]

From the 451 Group:“MySQL flirted with the open core licensing model in early 2008 with plans to introduce new features into Enterprise Edition that would not be available under an open source license.” MySQL didn’t flirt with, it was going to do ... [More] it.  Why? Because we were asking the question, “how do we pull in customers to make more money”.  MySQL was going to put the new backup API, which never materialized, into an Enterprise branch.  It was a lousy idea for the following reasons: 1) There was no internal API in the server for this, so the engineering was going to be messy and expensive.  2) We didn’t own the technology that was needed to even do this (Oracle owned Hot Backup) 3) Percona has an awesome tool for doing this, that is Open Source (http://www.percona.com/software/percona-xtrabackup/) 4) Backup is a core feature everyone needs, and some of those “everyones” are the folks who manufacture tools that you want to have work with your product. 5) When we were going to announce it, we hadn’t even written it/completed it. It was vaporware.  It would have been a horrible move, and would have caused Chaos for no particular reason. It was dead on arrival, and when it was to be announced as a strategy since it didn’t even exist.  Lets look at Oracle’s move. Both the authentication module, and the Thread Pool come into the MySQL server as plugins. If the engineering of the MySQL server continues in the current direction (which is somewhat flattering to Drizzle I might add), then they are on a good path (if I can find my blog entry where I talked about this as a good strategy, I’ll link back to it here).  Much of the hubbub around Open Source, Community, etc, in regards to this are a bit inflated I feel. They haven’t touched the core product, and they are creating API. Are they possibly hurting themselves in regards to ubiquity? Doubtful.  Would I pick those two pieces? No, but they aren’t the last two I would pick either.  If Sun had continued as a company? Something similar to this would have been done as well. From an engineering and usage stand point? The first person who sniffs at the authentication mechanism who knows anything about security is going to freak. The Thread Pool can only be used by a very limited number of users (and there are some restrictions on what can be done in the server while it is in use). MySQL’s IO was never designed for the Thread Pool, and there is a lot of engineering work that would need to be done to make it work.  Still? People will use both, and I am betting some customers will want them badly enough to pay.  If they are really badly needed? Well then someone will write an open source version of both. I have no great love of Oracle, but this is really not a big deal at all. The original GPL’ing of the Public Domain/LGPL clients was a much bigger deal. [Less]

From the 451 Group:“MySQL flirted with the open core licensing model in early 2008 with plans to introduce new features into Enterprise Edition that would not be available under an open source license.”MySQL didn’t flirt with, it was going to do ... [More] it. Why? Because we were asking the question, “how do we pull in customers to make more money”. MySQL was going to put the new backup API, which never materialized, into an Enterprise branch. It was a lousy idea for the following reasons:1) There was no internal API in the server for this, so the engineering was going to be messy and expensive. 2) We didn’t own the technology that was needed to even do this (Oracle owned Hot Backup)3) Percona has an awesome tool for doing this, that is Open Source (http://www.percona.com/software/percona-xtrabackup/)4) Backup is a core feature everyone needs, and some of those “everyones” are the folks who manufacture tools that you want to have work with your product.5) When we were going to announce it, we hadn’t even written it/completed it. It was vaporware. It would have been a horrible move, and would have caused Chaos for no particular reason. It was dead on arrival, and when it was to be announced as a strategy since it didn’t even exist. Lets look at Oracle’s move. Both the authentication module, and the Thread Pool come into the MySQL server as plugins. If the engineering of the MySQL server continues in the current direction (which is somewhat flattering to Drizzle I might add), then they are on a good path (if I can find my blog entry where I talked about this as a good strategy, I’ll link back to it here). Much of the hubbub around Open Source, Community, etc, in regards to this are a bit inflated I feel. They haven’t touched the core product, and they are creating API. Are they possibly hurting themselves in regards to ubiquity?Doubtful. Would I pick those two pieces? No, but they aren’t the last two I would pick either.  If Sun had continued as a company? Something similar to this would have been done as well.From an engineering and usage stand point?The first person who sniffs at the authentication mechanism who knows anything about security is going to freak.The Thread Pool can only be used by a very limited number of users (and there are some restrictions on what can be done in the server while it is in use). MySQL’s IO was never designed for the Thread Pool, and there is a lot of engineering work that would need to be done to make it work. Still? People will use both, and I am betting some customers will want them badly enough to pay. If they are really badly needed? Well then someone will write an open source version of both.I have no great love of Oracle, but this is really not a big deal at all. The original GPL’ing of the Public Domain/LGPL clients was a much bigger deal. [Less]

Thinking of attending the upcoming Percona Live event in London, but not yet registered?  Use discount code DrizzlePLUK and save 40 pounds off normal registration. Community members Henrik Ingo and Stewart Smith will be there and both will be presenting on Drizzle.  Hope to see you there!  

Drizzle source tarball, version 2011.09.26 has been released.  This is one of the final releases before the Fremont beta and consists of mostly polish.  Many thanks to those who have contributed time and effort into testing things. In this release: ... [More] Documentation updates. Thanks to everyone who has contributed edits / new documentation IPV6 bug fixes - continued polish of this new feature Query log improvements - thanks to Daniel Nichter (and also for his docs work!) The Drizzle download file can be found here. [Less]

October brings 2 very interesting conferences. I will be speaking first on Oct 3rd at HighLoad++ in Moscow and a few weeks later on Oct Oct 25 at Percona Live in London. I will give a talk called Choosing a MySQL Replication / High Availability ... [More] Solution which is based on my thinking developed in my recent blog post The ultimate MySQL high availability solution and many benchmarks and functional tests I've done while evaluating these technologies. At Percona Live I will also give a second talk Fixed in Drizzle: No more GOTCHA's. It looked like none of the Drizzle core team would be able to attend the conference and as I was going to be there I volunteered to cover a Drizzle topic at the same time. This is a talk Stewart Smith has given a few times at earlier conferences which I liked and proposed to Percona. As it turns out, also Stewart will be in London after all, so there will be 2 Drizzle talks, I will still give the one I'm committed to. read more [Less]

Drizzle trunk as of 2011-09-20 (r2422) has a new revision of my query_log plugin which is important because that revision works with the latest trunk revision of mk-query-digest (wget maatkit.org/trunk/mk-query-digest). I made the query log format ... [More] truly consistent and then wrote DrizzleQueryLogParser for mk-query-digest and added the command line option --type drizzlelog. I don’t intend [...] [Less]

Just in case anybody missed it: http://blogs.oracle.com/MySQL/entry/new_commercial_extensions_for_mysql MySQL has long been an open source product, not an open source project…. and this really is the final nail in that. To me, this was expected, but ... [More] it’s still sad to see it. I am very, very glad we have diverse copyright ownership in Drizzle so that this could not happen easily at all. [Less]

For months I’ve been perplexed that Drizzle authentication plugins did not seem to work. I filed bug 823637, asked on the mailing list, and made it need #1. I finally discovered how to authentication with authentication plugins like auth_pam: drizzle ... [More] -u daniel -P --protocol mysql-plugin-auth. The final command line option is the key: --protocol mysql-plugin-auth. [...] [Less]

My recent post on a new 95 percentile algo mentions a Python version of the algo. I’ve chosen Python 3 for development of new Drizzle tools. Problem is: the Python version of that algo is almost 3 times slower than the Perl version; here are the results (where “OLD” is Perl and “NEW” is Python): [...]