Since Oracle and MySQL just renewed that InnoDB contract there seems little reason to have major concerns about InnoDB for at least the next few years.
The description at the start was wrong. The Nerds were the MySQL plus IBM team and that's the team shown holding the trophy. I've had the pleasure of spending many hours with Brian Aker of MySQL and couldn't miss his classic look.
Your assertion is incorrect. They are going to block the mail which does not have this fee paid because their normal system routinely rejects legitimate bulk email. They also reduced the service by reducing the existing legitimate bulk mail whitelist system.
Your example should be that they first closed the bus and taxi lanes, then randomly reject 50% of busses and taxis unless they are paying a fee.
Now, it's no problem in theory to require AOL members to pay the fees AOL is imposing for bulk delivery to AOL members, so we'll see whether that happens.
How high should your AOL surcharge be to pay the fees being demanded? AOL wants to force people to pay the fees, so letting their customers know that it's necessary for them to pay an extra fee to get mail on AOL seems of value.
Sued for what? The problematic bits were found to be a joke with no harmful intent, so there's no libel there. Even if there had been, the person doing it resigning is likely more than ample penalty. And it's simply imposible to effectively sue Wikipedia or the Wikimedia Foundation or those who didn't write those versions, given US law on the subject.
Article histories contain two types of entry. First are the public ones. Those are distributed in dumps and availabel to anyone. Next are the "deleted" or hidden revisions, visible only to administrators. Those are not visible to the general public, are stored in different locations and are not made available in database dumps. The last time I checked there were several hundred of those hidden revisions for this article (some moved to a different title). The early versions of the article were removed from both, well after the fuss had largely died down. So who removed part of our history and why, since it didn't gain anything which hadn't already been achieved?
The events surrounding that article aren't minor or anything close to it. Results include stopping about 30% of all new page creations by blocking anonymous article creation and stimulating press coverage which roughly doubled traffic in a few weeks.
... Or correct it. The bit about Jimbo was added on 23 Feb with no discussion on that talk page for that page and is not long-standing policy of the Wikipedia authors and community. Here's the real long-standing policy in that area:
"Wikipedia is not an experiment in democracy. Its primary method of finding consensus is discussion, not voting. In difficult cases, straw polls may be conducted to help determine consensus, but are to be used with caution and not to be treated as binding votes. Suggestions that Wikipedia use the latest fancy transferable vote system for some election or another will likely be met with disdain, at best."
Of course, the views of Jimbo are treated with great respect and are very influential, but that's not quite the same thing.
Already happened. Someone removed the early edits in the Seigenthaler article so even administrators for the project can't see them. Wave goodbye to a key part of the history of Wikipedia.
I had a chance to chat about this with the head of MySQL's support group today and we're wondering whether this is with MyISAM or InnoDB? Also, how exactly does it break, with what errors? Wondering if there's a way it can be made to handle it more gracefully.
If you happen to have a MySQL support contract, can you open a support issue on this the next time it happens and link back to this discussion so it can be investigated that way? Could use a bug report but the support side helps the flow of things.
No reason MySQL can't be doing ten things simultaneously.
Even if MySQL itself did nothing, I expect to see lots more storage engines over the next 6-18 months, just exploiting the run-time pluggable storage engine architecture in 5.1.
Want an engine optimised for storage in flash media, CD-ROM, for searching, for geospatial work, access to an old Oracle table, access to Access.. you name it, if someone has a need, they could use a storage engine if that would be the easiest way to integrate it. No reason for MySQL to do these things - it's easy enough that customers with the need can and do.
Would be interesting to look for patterns in what causes those problems on the master/application side. I don't actually expect replication to stop as you're describing, but there are ways (like filling the master disk and leaving no room for the binary log) that human error causes it. Human error is, by a large margin, the largest cause of replication pain I see... Not saying this applies to you though - you clearly know what you're doing, so your case involves more detective work.:)
The InnoDB Hot Backup tool is made and sold by Innobase and provides a revenue stream from those who purchase it. It's one way to pay for permanently employed developers who are making their living only from development, not spending time on support work.
MySQL is different from PostgreSQL and provides different ways of doing things, like ubiquitous replication under the same license as the server. So that tends to be the way to go with larger MySQL setups, those you can't just back up in a second or ten witout anybody noticing.
There's one difference: a cursor library for the mysql command line client, which provides somewhat better support for scrollback and such.
Beyond that, the differences in Certified and non-Certified are related to more extensive testing, including more extensive regression testing and leaving time for problems to be discovered in the public GPL version before certification.
If you believe that there are other differences, please let me know what you think they are so I can tell you specifically that each is wrong.
The cost of a commercial use license for MySQL is $0 - the GPL license applies to commercial use.
There is a cost for commercial redistribution outside your own company if the software relying on it is not open source. If it is GPL or one of the other open source licenses MySQL accepts, the cost of that redistribution license is $0 but you might as well talk to MySQL sales to see if you can come up with some other deal which is mutually beneficial.
Being a non-profit doesn't affect licensing, unless MySQL decides to make a donation of a license, which seems fairly unlikely because the non-profit can already use MySQL free of charge internally with the GPL license.
To get a consistend dump you'll need to use FLUSH TABLES WITH READ LOCK. That takes a lock which blocks all updates until the dump is complete and the lock is released. Please see manual page http://dev.mysql.com/doc/refman/5.0/en/backup.html .
Thanks. Already read some.:) Architecture was the reason he gave in his announcement, so who am I to disagree?:)
I will disagree on some things, like the outdated claim that RAM is cheap, when now it is CPU which is cheap and using a core or two for compression is a good deal.:)
The problem with InnoDB Hot Backup for enterprise use is that it adds lots of load to the server it's backing up and that's not so good for a mission-critical server. IMO it's usually better to back up from a slave instead, so the main server isn't affected.
That's not to say that InnoDB Hot Backup isn't useful - it certainly is in various situations. But it's not something I'd normally choose to use if I already had mission-critical systems with the three servers such systems really need for utmost availability.
I'm sure that for you it was the best choice to make.
Jim Starkey said that he'd been working on a new engine for the last six years but couldn't integrate it fully with Firebird because of architectual problems. MySQL has an architecture designed to accept pluggable storage engines, so MySQL might end up with what he thinks is the next great performance improvement after Firebird.
Maybe. The only estimate I've seen of total.org lookups per day is 390 million (6% of all root domain lookups) in 2002. I don't have any information on how many of those are served from caches before they hit the database server. Presumably they mostly fall into the very simple query for a very small amount of data category.
Last I looked the choice was between GPL (not BSD) replication or expensive proprietary(!) replication. Niether of them capable of the 400 plus server replication setups I've seen used with MySQL.
Do tell me more about "hosing the repo at serious loads". Remember I do use MySQL at serious loads for one of the top few sites in the world, with replication. My experience is that it doesn't get hosed at serious loads but instead just keeps on working and getting the job done.
MediaWiki is also not a single table application without transactions. Rather it's multiple tables and Wikipedia does a billion queries per day on five database servers with a master and four slaves and some 400GB of data on each of those servers.
Do you know of even one PostgreSQL site which is doing a billion queries per day?
Just two days ago MySQL announced that several companies, including SAP, Intel and Red Hat, had provided US$18.5 million in funding for MySQL. That's long after the InnoDB acquisition and well after the rumors of Oracle buying Sleepycat. Seems really unlikely that they would do that if they weren't confident that MySQL was in a good position anyway.
If you think MySQL is only for the low end you've probably been reading too many posts from those touting a certain other open source database who pop up and criticise MySQL whenever it's in the news.:)
MySQL's view is that within a company is not distribution and no license is needed for GPL software.
For software linked with a GPL library to connect to the server its view is also that within a company no license is needed.
For redistributing outside when linked with a GPL library, its view is that you can use GPL or lots of open source licenses and still pay nothing at all.
And if you don't want to be open source, its view is that that's OK also but it's going to charge you money so you contribute to open source in that way instead. And that helps to pay the wages of the few hundred people working for the company who are helping to improve MySQL for your benefit and that of everyone else.
Sorry, I wasn't the person who compiled that list and I don't know their licensing. Oracle only owns two of those copyrights.
I expect that many commercial distributors can still license the MySQL client libraries and use the GPL version of MySQL.
As far as too late goes, judging from the InnoDB reports, it's safe to expect that MySQL's contracts have a minimum of a year from notice of termination to end of ability to license. That's enough time to get some alternative in place. For InnoDB MySQL also said that all existing customers could continue indefinitely, if I recall correctly, suggesting that there's a grandfather clause in there for existing customers as well.
Since Oracle and MySQL just renewed that InnoDB contract there seems little reason to have major concerns about InnoDB for at least the next few years.
The description at the start was wrong. The Nerds were the MySQL plus IBM team and that's the team shown holding the trophy. I've had the pleasure of spending many hours with Brian Aker of MySQL and couldn't miss his classic look.
Just what needs to happen in the real world. :)
Your assertion is incorrect. They are going to block the mail which does not have this fee paid because their normal system routinely rejects legitimate bulk email. They also reduced the service by reducing the existing legitimate bulk mail whitelist system.
Your example should be that they first closed the bus and taxi lanes, then randomly reject 50% of busses and taxis unless they are paying a fee.
Now, it's no problem in theory to require AOL members to pay the fees AOL is imposing for bulk delivery to AOL members, so we'll see whether that happens.
How high should your AOL surcharge be to pay the fees being demanded? AOL wants to force people to pay the fees, so letting their customers know that it's necessary for them to pay an extra fee to get mail on AOL seems of value.
Sued for what? The problematic bits were found to be a joke with no harmful intent, so there's no libel there. Even if there had been, the person doing it resigning is likely more than ample penalty. And it's simply imposible to effectively sue Wikipedia or the Wikimedia Foundation or those who didn't write those versions, given US law on the subject.
Article histories contain two types of entry. First are the public ones. Those are distributed in dumps and availabel to anyone. Next are the "deleted" or hidden revisions, visible only to administrators. Those are not visible to the general public, are stored in different locations and are not made available in database dumps. The last time I checked there were several hundred of those hidden revisions for this article (some moved to a different title). The early versions of the article were removed from both, well after the fuss had largely died down. So who removed part of our history and why, since it didn't gain anything which hadn't already been achieved?
The events surrounding that article aren't minor or anything close to it. Results include stopping about 30% of all new page creations by blocking anonymous article creation and stimulating press coverage which roughly doubled traffic in a few weeks.
... Or correct it. The bit about Jimbo was added on 23 Feb with no discussion on that talk page for that page and is not long-standing policy of the Wikipedia authors and community. Here's the real long-standing policy in that area:
"Wikipedia is not an experiment in democracy. Its primary method of finding consensus is discussion, not voting. In difficult cases, straw polls may be conducted to help determine consensus, but are to be used with caution and not to be treated as binding votes. Suggestions that Wikipedia use the latest fancy transferable vote system for some election or another will likely be met with disdain, at best."
Of course, the views of Jimbo are treated with great respect and are very influential, but that's not quite the same thing.
Already happened. Someone removed the early edits in the Seigenthaler article so even administrators for the project can't see them. Wave goodbye to a key part of the history of Wikipedia.
I had a chance to chat about this with the head of MySQL's support group today and we're wondering whether this is with MyISAM or InnoDB? Also, how exactly does it break, with what errors? Wondering if there's a way it can be made to handle it more gracefully.
If you happen to have a MySQL support contract, can you open a support issue on this the next time it happens and link back to this discussion so it can be investigated that way? Could use a bug report but the support side helps the flow of things.
No reason MySQL can't be doing ten things simultaneously.
.. you name it, if someone has a need, they could use a storage engine if that would be the easiest way to integrate it. No reason for MySQL to do these things - it's easy enough that customers with the need can and do.
Even if MySQL itself did nothing, I expect to see lots more storage engines over the next 6-18 months, just exploiting the run-time pluggable storage engine architecture in 5.1.
Want an engine optimised for storage in flash media, CD-ROM, for searching, for geospatial work, access to an old Oracle table, access to Access
Would be interesting to look for patterns in what causes those problems on the master/application side. I don't actually expect replication to stop as you're describing, but there are ways (like filling the master disk and leaving no room for the binary log) that human error causes it. Human error is, by a large margin, the largest cause of replication pain I see... Not saying this applies to you though - you clearly know what you're doing, so your case involves more detective work. :)
The InnoDB Hot Backup tool is made and sold by Innobase and provides a revenue stream from those who purchase it. It's one way to pay for permanently employed developers who are making their living only from development, not spending time on support work.
MySQL is different from PostgreSQL and provides different ways of doing things, like ubiquitous replication under the same license as the server. So that tends to be the way to go with larger MySQL setups, those you can't just back up in a second or ten witout anybody noticing.
There's one difference: a cursor library for the mysql command line client, which provides somewhat better support for scrollback and such.
Beyond that, the differences in Certified and non-Certified are related to more extensive testing, including more extensive regression testing and leaving time for problems to be discovered in the public GPL version before certification.
If you believe that there are other differences, please let me know what you think they are so I can tell you specifically that each is wrong.
There is a cost for commercial redistribution outside your own company if the software relying on it is not open source. If it is GPL or one of the other open source licenses MySQL accepts, the cost of that redistribution license is $0 but you might as well talk to MySQL sales to see if you can come up with some other deal which is mutually beneficial.
Being a non-profit doesn't affect licensing, unless MySQL decides to make a donation of a license, which seems fairly unlikely because the non-profit can already use MySQL free of charge internally with the GPL license.
To get a consistend dump you'll need to use FLUSH TABLES WITH READ LOCK. That takes a lock which blocks all updates until the dump is complete and the lock is released. Please see manual page http://dev.mysql.com/doc/refman/5.0/en/backup.html .
Thanks. Already read some. :) Architecture was the reason he gave in his announcement, so who am I to disagree? :)
:)
I will disagree on some things, like the outdated claim that RAM is cheap, when now it is CPU which is cheap and using a core or two for compression is a good deal.
If you want a consistent backup, one locks the database for writes, the other doesn't. Both add lots of load to the server they are working with.
The problem with InnoDB Hot Backup for enterprise use is that it adds lots of load to the server it's backing up and that's not so good for a mission-critical server. IMO it's usually better to back up from a slave instead, so the main server isn't affected.
That's not to say that InnoDB Hot Backup isn't useful - it certainly is in various situations. But it's not something I'd normally choose to use if I already had mission-critical systems with the three servers such systems really need for utmost availability.
I'm sure that for you it was the best choice to make.
Jim Starkey said that he'd been working on a new engine for the last six years but couldn't integrate it fully with Firebird because of architectual problems. MySQL has an architecture designed to accept pluggable storage engines, so MySQL might end up with what he thinks is the next great performance improvement after Firebird.
Maybe. The only estimate I've seen of total .org lookups per day is 390 million (6% of all root domain lookups) in 2002. I don't have any information on how many of those are served from caches before they hit the database server. Presumably they mostly fall into the very simple query for a very small amount of data category.
Last I looked the choice was between GPL (not BSD) replication or expensive proprietary(!) replication. Niether of them capable of the 400 plus server replication setups I've seen used with MySQL.
Do tell me more about "hosing the repo at serious loads". Remember I do use MySQL at serious loads for one of the top few sites in the world, with replication. My experience is that it doesn't get hosed at serious loads but instead just keeps on working and getting the job done.
MediaWiki is also not a single table application without transactions. Rather it's multiple tables and Wikipedia does a billion queries per day on five database servers with a master and four slaves and some 400GB of data on each of those servers.
Do you know of even one PostgreSQL site which is doing a billion queries per day?
Just two days ago MySQL announced that several companies, including SAP, Intel and Red Hat, had provided US$18.5 million in funding for MySQL. That's long after the InnoDB acquisition and well after the rumors of Oracle buying Sleepycat. Seems really unlikely that they would do that if they weren't confident that MySQL was in a good position anyway.
:)
If you think MySQL is only for the low end you've probably been reading too many posts from those touting a certain other open source database who pop up and criticise MySQL whenever it's in the news.
MySQL's view is that within a company is not distribution and no license is needed for GPL software. For software linked with a GPL library to connect to the server its view is also that within a company no license is needed. For redistributing outside when linked with a GPL library, its view is that you can use GPL or lots of open source licenses and still pay nothing at all. And if you don't want to be open source, its view is that that's OK also but it's going to charge you money so you contribute to open source in that way instead. And that helps to pay the wages of the few hundred people working for the company who are helping to improve MySQL for your benefit and that of everyone else.
Sorry, I wasn't the person who compiled that list and I don't know their licensing. Oracle only owns two of those copyrights.
I expect that many commercial distributors can still license the MySQL client libraries and use the GPL version of MySQL.
As far as too late goes, judging from the InnoDB reports, it's safe to expect that MySQL's contracts have a minimum of a year from notice of termination to end of ability to license. That's enough time to get some alternative in place. For InnoDB MySQL also said that all existing customers could continue indefinitely, if I recall correctly, suggesting that there's a grandfather clause in there for existing customers as well.