News

News

Showing articles from http://www.planetmysql.org/rss20.xml External_link

[11397 total ]
Fixing a MariaDB package bug

Posted about 21 hours ago by Kristian Nielsen

One of the things that I am really happy about in MariaDB is that we have our
releases available as apt (and yum for Centos) repositories. This is
largely thanks to being able to build this on
the OurDelta package build ... [More] infrastructure
(which again builds on things like the Debian packaging scripts for MySQL).

Something like the Debian apt-get package system (which is also
used by Ubuntu) is one of the major innovations in the Free Software world in
my opinion. Debian has spent many years refining this system to where it is
today. Want to run the mysql client, but it isn't installed? Just try to run
it on your local Ubuntu host:

$ mysql
The program 'mysql' can be found in the following packages:
* mysql-client-5.0
* mysql-client-5.1
Try: sudo apt-get install <selected package>
-bash: mysql: command not found

Installing software does not get much easier than that!

Now, MariaDB is not in the distributions yet. However, it is easy to add
external repositories like OurDelta into your system, after which packages
from the external repositories are available fully integrated with the package
system:

wget -O- http://ourdelta.org/deb/ourdelta.gpg | sudo apt-key add -
sudo wget http://ourdelta.org/deb/sources/karmic-mariadb-ourdelta.list \
-O /etc/apt/sources.list.d/ourdelta.list

(there are also GUI ways to do this of course, for those who prefer that).
After this is done, installation is just a sudo apt-get install mariadb-server-5.1
away, security updates will appear automatically for MariaDB just like any
other package, etc. It will even upgrade an existing MySQL 5.0 installation
automatically (but do take a backup first).

In order to make all this work, there is a lot of work going on behind the
scenes in the scripts that make up the .deb packaging. I think most people
underestimate the amount of work and clever engineering that goes into making
a well-working .deb package. It is easy to laugh at how behind the latest
stable Debian release is on software versions (and I am happy to do this on
occasion as well). But Debian is still unique in the sheer amount of software
it contains and the level of integration of each package in the whole
system. And it is this work through the last more than 15 years that allows
something like Ubuntu to exists, with an upgrade system that allows it to do
6-month release cycles to provide up-to-date software to its users.

As an example of the kind of details that needs to be dealt with, I wanted to
explain a tricky packaging bug I fixed recently.

The bug was with installing MariaDB 5.1.39 on top of an existing MySQL 5.0
installation in Debian and Ubuntu. This is supposed to automatically run the
mysql_upgrade program to upgrade all tables from the 5.0 format to the 5.1
format. The symptoms were that the upgrade was not performed correctly, for
example the system tables in the mysql database were missing some
of the columns added in the 5.1 version.

What made this tricky was that the bug was quite elusive. It did not happen
always, and some platforms were ok while others (eg. Ubuntu Hardy amd64) seemed to
have it more or less repeatedly. Even worse, even when it did occur, it went
away by itself (this is because the .deb MariaDB and MySQL packages actually
check for the need to upgrade the database on every server start, and the
upgrade procedure always worked when the server was restarted after
installation).

After poking for this for some hours, I managed to get it reproducibly on a
KVM virtual machine containing Ubuntu Hardy. I then traced the problem into
the upgrade procedure, which happens in
the /etc/mysql/msyql_upgrade script which is run
from /etc/init.d/mysql start. Comparing the log from this (in
syslog) with the corresponding log from a successful installation showed that
the upgrade procedure seemed to be aborted half-way through, but with
absolutely no output (like an error message) to indicate any reason for this.

Now the fact that running the upgrade procedure (or just server start)
manually did not exhibit any problems made it quite puzzling to
figure out what was going on. Looking through the source code
of mysql_upgrade and mysqlcheck (which is called
from mysql_upgrade) did not reveal anything that would indicate a
problem like this. One step would be to start instrumenting the code with
printouts, but this would require building a full set of packages and
installing them inside a virtual machine for every iteration, which would have
been quite time-consuming.

A better approach turned out to be to install the package running
under strace -f. This generates a log (45 MByte of it!) of all
system calls made by the installation process, including child processes
like the mysql_upgrade invocation. Digging through this for a
while, I finally discovered that the upgrade process was being terminated
because it received a SIGHUP (hangup) signal!

Now why would it be killed with SIGHUP? Turns out it is due to this snippet
from the /etc/mysql/debian-start bash script:

(
upgrade_system_tables_if_necessary;
check_root_accounts;
check_for_crashed_tables;
) <&2 &

The upgrade procedure is run in the background (as it may take a long time,
and since this is run on every server restart, it could also happen eg. during
host boot, which we do not want to block for long periods of time). But there
is no protection against the controlling terminal going away! My guess is
that apt-get in some cases will allocate a pseudo-tty to deal
with package configuration input, and this is closed when installation is
done, causing the background upgrade procedure to be killed with SIGHUP.

Now finally the problem is understood, and the fix is a one-liner: just add
this before starting the background job:

trap "" SIGHUP

Problem solved!

[Incidentally, if you installed MariaDB 5.1.39 .debs and experienced this
problem, there is an easy workaround for this bug: just restart the MariaDB
server once after installation (sudo /etc/init.d/mysql restart).
This will make the upgrade procedure go through if it did not already. This
fix will be included in the upcoming MariaDB 5.1.41 release.] [Less]

Using mysqld_multi on Karmic

Posted 1 day ago by Mats Kindahl

I wanted to set up several servers on my machine using the Ubuntu
distribution and control them using mysqld_multi: the
typical way to manage several servers on your machine. However, I also
wanted to use MySQL 5.1 and not 5.0, which is ... [More] the default on Jaunty
(Ubuntu 9.04).

About a month ago, I upgraded to Karmic Koala and one of the reasons
were that MySQL 5.1 is used by default. Even though I could install
the latest revision all the time, I usually want to use the real
distributions for my private projects for a number of reasons.

I actually tried to upgrade to MySQL 5.1 on Ubuntu 9.04, but I
discovered that all kinds of applications had dependencies on MySQL
5.0, so I avoided to upgrade at that time.

Anyway, the procedure for installing multiple servers on the same
machine is this:

Shut down the running server.

This is, strictly speaking, not necessary unless you are going
to edit the options for the running server, but I do this as a
precaution.

Edit your my.cnf configuration file and add
sections for mysqld_multi and the new servers.

I wanted to add four servers to play with, not counting the one
that is already installed and running, so I added sections
mysqld1 to mysqld4. Also add a section
for mysqld_multi

Create server directories and database files using
mysql_install_db

The new servers need to be bootstrapped so that they have all
the necessary databases and tables set up.

Optionally: install an init.d script that uses mysqld_multi.

This is currently not very well-supported in Debian (there is
actually a comment saying that it is not supported), so I skipped
this step. If you feel adventerous, you can always copy the
/usr/share/mysql/mysqld_multi.server as
/etc/init.d/mysql.server as they suggest in the file,
but I will not do it, nor recommend it (because I haven't tried it).

Start the installed server(s).
Well, not much to say here.

So, on my way, I edited the /etc/mysql/my.cnf and added
the sections necessary. (You can see a diff of that below.)

The important options to add are server-id so that each
server gets a unique server id (I'm going to replicate between them),
port and socket so that you can connect to each of
them both when you're on the local machine and from another machine,
and pid-file to give each server a unique pid file name (this
is important, since the default will not work at all).

Next step is to install the data directories for the servers, which
should be trivial:

$ sudo mysql_install_db --user=mysql --datadir=/var/lib/mysqlfoo --basedir=/usr
Installing MySQL system tables...
091120 9:40:23 [Warning] Can't create test file /var/lib/mysqlfoo/romeo.lower-test
091120 9:40:23 [Warning] Can't create test file /var/lib/mysqlfoo/romeo.lower-test
ERROR: 1005 Can't create table 'db' (errno: 13)
091120 9:40:23 [ERROR] Aborting

091120 9:40:23 [Warning] Forcing shutdown of 2 plugins
091120 9:40:23 [Note] /usr/sbin/mysqld: Shutdown complete

Installation of system tables failed! Examine the logs in
/var/lib/mysqlfoo for more information.
.
.
.

OK, the warning is a warning, but it seems I forgot the permissions on
the directory. Checking the write permissions, no
problems. Hmmm... checking that I can create the directories and files
manually as the mysql user, no problems(!)

What on earth is going on?

After some digging around, I found bug
#201799 which quite clearly explains that what I thought was a
permission problem is actually AppArmor doing
its job.

So updating the AppArmor configuration file
/etc/apparmor.d/usr.sbin.mysqld with this solved the
problem and I could get on with installing the servers.

diff --git a/apparmor.d/usr.sbin.mysqld b/apparmor.d/usr.sbin.mysqld
index f9f1a37..7a94861 100644
--- a/apparmor.d/usr.sbin.mysqld
+++ b/apparmor.d/usr.sbin.mysqld
@@ -21,10 +25,20 @@
/etc/mysql/my.cnf r,
/usr/sbin/mysqld mr,
/usr/share/mysql/** r,
/var/log/mysql.log rw,
/var/log/mysql.err rw,
+ /var/log/mysql[1-9].log rw,
+ /var/log/mysql[1-9].err rw,
/var/lib/mysql/ r,
/var/lib/mysql/** rwk,
+ /var/lib/mysql[1-9]/ r,
+ /var/lib/mysql[1-9]/** rwk,
/var/log/mysql/ r,
/var/log/mysql/* rw,
+ /var/log/mysql[1-9]/ r,
+ /var/log/mysql[1-9]/* rw,
/var/run/mysqld/mysqld.pid w,
/var/run/mysqld/mysqld.sock w,
+ /var/run/mysqld/mysqld[1-9].pid w,
+ /var/run/mysqld/mysqld[1-9].sock w,
}

Changes to /etc/mysql/my.cnf

Here is a unified diff of the changes I made to
/etc/mysql/my.cnf to add some more servers.

$ git diff mysql/my.cnf
--- a/mysql/my.cnf
+++ b/mysql/my.cnf
@@ -111,7 +111,46 @@ max_binlog_size = 100M
# ssl-cert=/etc/mysql/server-cert.pem
# ssl-key=/etc/mysql/server-key.pem

+[mysqld_multi]
+mysqld = /usr/bin/mysqld_safe
+mysqladmin = /usr/bin/mysqladmin
+user = root

+[mysqld1]
+server-id = 1
+pid-file = /var/run/mysqld/mysqld1.pid
+socket = /var/run/mysqld/mysqld1.sock
+port = 3307
+datadir = /var/lib/mysql1
+log-bin = /var/lib/mysql1/mysqld1-bin.log
+log-bin-index = /var/lib/mysql1/mysqld1-bin.index
+
+[mysqld2]
+server-id = 2
+pid-file = /var/run/mysqld/mysqld2.pid
+socket = /var/run/mysqld/mysqld2.sock
+port = 3308
+datadir = /var/lib/mysql2
+log-bin = /var/lib/mysql2/mysqld2-bin.log
+log-bin-index = /var/lib/mysql2/mysqld2-bin.index
+
+[mysqld3]
+server-id = 3
+pid-file = /var/run/mysqld/mysqld3.pid
+socket = /var/run/mysqld/mysqld3.sock
+port = 3309
+datadir = /var/lib/mysql3
+log-bin = /var/lib/mysql3/mysqld3-bin.log
+log-bin-index = /var/lib/mysql3/mysqld3-bin.log
+
+[mysqld4]
+server-id = 4
+pid-file = /var/run/mysqld/mysqld4.pid
+socket = /var/run/mysqld/mysqld4.sock
+port = 3310
+datadir = /var/lib/mysql4
+log-bin = /var/lib/mysql4/mysqld3-bin.log
+log-bin-index = /var/lib/mysql4/mysqld3-bin.log

[mysqldump]
quick [Less]

51 Weeks since my book writing adventure began

Posted 1 day ago by Daniel Schneller

In one week, on December 24th, it will be exactly one year since I was first contacted by Packt Publishing. After reading several posts from this blog they asked me if I’d be interested in writing a MySQL administration cookbook with hands-on ... [More] recipes for those among us who have to make sure the MySQL servers are kept running and in good shape. Funny thing, I almost deleted their email, because [Less]

New GPL suits and an open source imbalance

Posted 1 day ago by The 451 Group

A new round of GPL-based BusyBox suits has been filed, targeting big names in electronics and IT. We’ve long covered these series of GPL-based suits and settlements, but this latest round comes at an interesting time for open source software ... [More] and its licensing.
First, we have the backdrop of the Oracle-Sun-MySQL acquisition, with opponents arguing to the world and the European Commission, which is reviewing the proposed merger before approving it, in part that the GPL is, ironically, granting too much power to its user, in this case Oracle. I’ve been quoted in the press and honestly agree with Eben Moglen that we the industry, as well as oversight organizations, should trust in the GPL and open source software. It seems to have worked sufficiently to encourage, rather than discourage, competition in the past, so it is logical to assume this will continue, particularly given the commitments and scrutiny thus far. I would also point out that Oracle is going much further in outlining its plans and commitment to MySQL than Sun Microsystems ever had to when it acquired the open source database company and code.
Back to the GPL suits, these represent the ongoing effort of the SFLC to highlight both the workings and legitimacy of open source software licenses. Given the settlements so far and the relatively reasonable tone and approach of the SFLC, I would say these efforts are effectively raising awareness. Furthermore, given incidents such as Microsoft’s recent GPL gaffe, it seems clear that open source license violations are likely widespread, whether they are intentional or not.
Our recent survey of open source software customers and users also reinforces a lack of awareness, given that more than 57% of respondents track open source in development projects, but fewer than 32% have guidelines or policies for contributing to open source. Our survey indicates that while cost is important and serves as a primary driver of open source adoption and open source is delivering cost savings more than 87% of the time, far fewer open source users are truly focused on giving back. Nevertheless, the 31.8% of users that did have guidelines or policy for contributing to open source amounts to nearly one-third of our 1,700 respondents, and this could easily be viewed as a glass half-full scenario for open source supporters.
The GPL BusyBox suits, however, have also served to create some skepticism and scorn for those who are bringing suit. Part of this is based on the idea that backers of openness and transparency aren’t entirely comfortable with the unspecified monetary payments included in previous settlements. Now even some BusyBox developers are questioning the moves.
This again highlights the difficult balance in free and open source software between the philosophy and business aspects of open source, both of which can be integral and symbiotic to the other, but both of which remain a dichotomy as well. [Less]

Kontrollkit 1.02 revision 10 available for download

Posted 1 day ago by Matt Reid

A new version of Kontrollkit is available. Changes are as follows:

added innodb_io_capacity to cnf files
addressed version > 5.1.24 issue with innodb_flush_method
fixed host dash missing in daily optimize
changed ’show ... [More] processlist’ to ’show full processlist’
added utf8 as the default collation and character set on all cnf files
commented out slow log – prod servers should only need it [...] [Less]

New and noteworthy in mycheckpoint (rev. 57)

Posted 1 day ago by Shlomi Noach

Rev. 57 of mycheckpoint has been released and is available for download.
New and updated in this revision:

Remote host monitoring
Improved charting
Flexible charting
Fix to questions vs. queries issues

Remote host ... [More] monitoring
It is now possible to monitor one host, while writing into another. Either or both could be remote hosts:

mycheckpoint --host=localhost --monitored-host=192.168.10.178

The above monitors the MySQL server on 192.168.10.178, and writes down to localhost (to be queried later)

mycheckpoint --monitored-host=127.0.0.1 --host=192.168.10.178

The above monitors the MySQL server on 127.0.0.1, and writes down to 192.168.10.178.
As result of the above addition, binary logging for monitoring statements are now enabled by default. The previous solution, in which binary logging were disabled by default and the same schema was utilized by different servers was far from being a clean solution. [Read more on Remote & multiple hosts monitoring]

Improved charting
The google charts reports have been improved significantly. Here’s how:

Before on left (or above), After on right (or below)
And

Before on left (or above), After on right (or below)
Recap: the charts are not stored anywhere; they are being calculated and generated by SQL queries & views, based on the raw data. For example, to generate the above, I do:

SELECT innodb_estimated_log_mb_written_per_hour FROM sv_report_chart_sample\G
*************************** 1. row ***************************
innodb_estimated_log_mb_written_per_hour: http://chart.apis.google.com/chart?cht=lc&chs=400x200&chts=303030,12&chtt=Latest+24+hours:+Dec+8,+08:20++-++Dec+9,+08:20&chdl=innodb_estimated_log_mb_written_per_hour&chdlp=b&chco=ff8c00&chd=s:OQOTSPPQPSROUQMTRSQTPSURQTQQPSOSRTRRUTRRTSRRRSRSTRRQSURSUVRRXQTVRUTTVUTOYTXSYTTSYUSUTWUPRRPQSQRQTPPSPQMPPQOQMQPMOMOLQORNNPNRNNOPQOOMQQPNRNMNORQMSTQQPTPRUQVQTTVSURUVVVSSSVWQVUSTVSWSSUURWRVRTWdotpQNROPQRPQQMPLRO9PWNRPNNNPXUMLNNPQQPSONPLLNWXZTQROSQMOONQPLJNOOQQKMPSMMPLfPSSSRTUQSORSSRSPNRSQSQ&chxt=x,y&chxr=1,0,2708.0&chxl=0:|09:00||||13:00||||17:00||||21:00||||01:00||||05:00||||&chxs=0,505050,10&chg=4.17,25,1,3,2.78,0&chxp=0,2.78,6.95,11.12,15.29,19.46,23.63,27.80,31.97,36.14,40.31,44.48,48.65,52.82,56.99,61.16,65.33,69.50,73.67,77.84,82.01,86.18,90.35,94.52,98.69

If you thought I was going over the edge in Auto scaling, scaled SQL graphs concluded or SQL pie chart, allow me to assure you: generation of the above charts using SQL & views is SQL blasphemy. While cool, the Google Charts API does not do too much on its own, and expects the caller to do the math for putting in the grids, scales and labels (and though all of them are tightly related, they must all be explicitly specified). I’ll write a later post on this.

Flexible charting
A new table, called charts_api, is introduced. It contains one row, which lists charting configuration.

SELECT * FROM charts_api;
+-------------+--------------+----------------------------------------------------------------+------------------------------------+
| chart_width | chart_height | simple_encoding                                                | service_url                        |
+-------------+--------------+----------------------------------------------------------------+------------------------------------+
|         400 |          200 | ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789 | http://chart.apis.google.com/chart |
+-------------+--------------+----------------------------------------------------------------+------------------------------------+

To change generated charts dimensions, simply update chart_width or chart_height.
To use other chart APIs, update service_url. I’ve tried out Eastwood Charts, a Java-based service, which implements the Google Charts API. There’s still some stuff missing, such as the positioning of labels and grids; and it’s slightly less polished (but configurable). But if you’re concerned about sending requests to Google, it’s a viable alternative.
So, drop the WAR file into your Tomcat / JBoss / other j2ee server, then follow http://127.0.0.1/eastwood/chart?…

Fix to questions vs. queries issues
mycheckpoint now correctly identifies whether to use questions or queries when analyzing DML queries. If you got some 570% for com_update out of total queries and wondered about it, it should now be resolved to normal values.
On upgrading your current installation

Download & install via debian or python installers
Issue mycheckpoint once with “deploy” as argument
Done

Future plans
I’m working on 24×7 charting; minimal operating system monitoring; auto-detection and auto-deploy on version upgrade; and more.
Stay tuned! [Less]

Understanding installing MySQL rpm versions

Posted 1 day ago by Ronald Bradford

I have a problem with an easy way to install MySQL via rpm without resorting to specifying the exact point release of MySQL. Presently my local yum repository has versions of 5.0, 5.1,5.4 and 5.5.
If I want to install MySQL Sever, I can just ... [More] run:

$ sudo yum install -y MySQL-server
Setting up Install Process
Package MySQL-server-community-5.5.0-1.rhel5.x86_64 already installed and latest version
Nothing to do

The issue here is the most current version is installed. If I want to install the most current version of 5.1 for example, I have found no way to specify MySQL-server-5.1, or MySQL-server-community-5.1, I have to specify the point release MySQL-server-community-5.1.40
I suspect there is some internal aliasing that may be possible within rpm’s to support this. I’m seeking help from any rpm experts and would appreciate any feedback.
My current products include:

$ sudo yum list MySQL-server-community
Installed Packages
MySQL-server-community.x86_64 5.5.0-1.rhel5 installed
Available Packages
MySQL-server-community.x86_64 5.0.82-0.rhel5 mydb-rhel5-server-x86_64
MySQL-server-community.x86_64 5.0.82-0.rhel5 mydb-rhel5-x86_64
MySQL-server-community.x86_64 5.1.40-0.rhel5 mydb-rhel5-server-x86_64
MySQL-server-community.x86_64 5.1.40-0.rhel5 mydb-rhel5-x86_64
MySQL-server-community.x86_64 5.4.3-0.rhel5 mydb-rhel5-server-x86_64
MySQL-server-community.x86_64 5.4.3-0.rhel5 mydb-rhel5-x86_64
MySQL-server-community.x86_64 5.5.0-1.rhel5 mydb-rhel5-server-x86_64
MySQL-server-community.x86_64 5.5.0-1.rhel5 mydb-rhel5-x86_64 [Less]

Recovery Time for TokuDB

Posted 1 day ago by Tokuview Blog

Last week Tokutek released version 3.0.0 of TokuDB, adding ACID transactions to its list of features. This post discusses an experiment we ran to measure recovery time following a system crash.
In summary, while actively inserting records into a ... [More] MySQL database using iiBench, we compared the time to recover from a power-cord pull for both InnoDB and TokuDB.

Storage Engine
Recovery Time

TokuDB
501s (8 min, 21 sec)

InnoDB
18505s (5 hours, 8 min, 25 sec)

This is by no means an exhaustive look at recovery performance, but does illustrate the benefits of Tokutek’s approach.
The experiment
We ran iiBench on the following server:

Sunfire x4150
Dual socket quad core Xeon 3.1GHz
16GiB memory
2 SAS 146GB
6 SAS 146GB hardware RAID 0 256KiB stripe
CentOS 5.1
Ext3 file system

The disks and RAID controller were configured with the write-caches OFF using arcconf. (Note: an experiment with the RAID controller write-cache ON resulted in a non-recoverable database, as you should expect)
We ran an insert-only iiBench test. After inserting about 250M rows and while actively inserting more, we manually pulled the plugs (2 on a Sunfire x4150). We then powered up the server and timed how long it took to start mysqld.
The results for InnoDB are not surprising – they are in line with results reported elsewhere. During recovery, InnoDB reported 1 transaction to be rolled back or cleaned up, and 68 row operations to undo.
The results for TokuDB are encouraging, in that they indicate recovery can be performed in minutes instead of hours. In this experiment, rebooting the server almost took as long as recovering the TokuDB database.
The primary reason for TokuDB’s quick recovery time is the use of regular, automatic checkpoints. This feature (introduced in version 2.0.0) ensures that work is completed and written to disk (including the necessary fsync) on a regular basis. Recovery is limited to processing uncommitted transactions and work since the last checkpoint. When not pushing performance to the absolute max we find recovery times typically take less than a minute. [Less]

A MySQL Community Member Opinion of Oracle Buying Sun

Posted 1 day ago by Sheeri K. Cabral

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 ... [More] — 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. [Less]

MySQL Performance: Breaking limits with XtraDB !

Posted 1 day ago by Dimitri Kravtchuk

I've just finished my benchmark report about InnoDB current
hottest internal contentions on the dbSTRESS workload. Since
InnoDB-plugin-1.0.4 there is an excellent feature was added by Innobase
team to monitor internal ... [More] mutex lock waits: a compact output of "SHOW
MUTEX STATUS" become much more useful then before! and helps greatly to
understand InnoDB limits!

I've integrated innodbMUTEX stats within dim_STAT monitoring and was
able to see performance limits from completely different axes!

Initial results

Initially I've retested again:

MySQL Perf-build5

MySQL 5.4

InnoDB-plugin-1.0.4

XtraDB-8

on the same workload and using X4450 server (Intel CPU, 16cores, 16GB
RAM (unfortunately all more powerful servers were busy :-)) as well it
was sad for me that I've not used the updated XtraDB-8 code during my latest
tests (there was something wrong with uploaded sources during
announces, and I've discovered it only after discussion with Yasufumi)..

And obtained results are looking like this now:

placing XtraDB-8 in the #1 position!

NOTE: lock waits stats are not available for MySQL 5.4 and build5, but
you may compare plugin-1.0.4 and XtraDB-8 profilings - they are very
different the one from other! And observing their lock waits levels you
may easily understand why XtraDB today out-performs all others!..

Going further with XtraDB

And then I continued my investigations mainly with XtraDB, because:

Because it has already combined together all most important
improvements from MySQL 5.4 and InnoDB-plugin!

And it has already several "ongoing" improvements integrated! :-)

And it has its own valuable ideas! :-)

It even has now a separated
purge thread feature implemented! (it was not announced in the list
of features for XtraDB-8, but you may find a new configuration
parameter innodb_use_purge_thread
(=0/1))

It already implements buffer mutex split (and that's why we did not
observe buffer lock waits!)

It already implements extended rollback segments!

And it already implements some fixes for dictionary locks!

So, until all these features are not shipped "officially" - it's very
easy to validate their impact on your workload with XtraDB, and I'm
pretty sure - more cases will be tested, better MySQL/InnoDB will be in
the future! Don't wait! :-)

I'll avoid to copy & paste my report to the blog post, and will just say
you that I was able to improve performance by 37% (!) again by
using available in XtraDB features!

All details you may find within my benchmark report: http://dimitrik.free.fr/db_STRESS_XtraDB-8_Performance_Dec2009.html

Any comments ate welcome! And I'll be happy if you may share any lock
waits observations regarding your own workloads (production or testing -
doesn't matter)!

As the last word I want just to say: kudos Percona! :-) XtraDB once
again become the performance #1 and going ahead of the all
today's available InnoDB engine implementations, and it's great to see
such a kind of positioning few days before of incoming XtraDB
anniversary! :-) [Less]