MySQL 5.1.24-rc ships with a EXAMPLE storage engine which is basically a dummy storage engine and serves as a useful source to start writing your own custom storage engine.

However, it is not available for use, by default. You can verify this as follows:

mysql> show engines;

+------------+---------+-----------------------------------------------------------+--------------+----+------------+ | Engine     | Support | Comment                                                   | Transactions | XA | Savepoints | +------------+---------+-----------------------------------------------------------+--------------+----+------------+ | …

I sometimes encounter the issue where a replication slave is behind the master, while happily connected and in state of "waiting for binlog event". Clearly it somehow didn't get the memo that new stuff was available. I know others have seen this too, but for lack of reproducibility it's not yet a bug report.
Mark Barger of ANYwebcam has been kind enough to tweak a script so Nagios can alert on this problem, see the Nagios Scripts page in the Resources/Tools section of the OQ website. See the page itself for further details on monitoring and dealing with the problem.

Tracking MySQL replication status in general is important anyway, as basically a master doesn't "care" whether a slave is connected or not (the system is slave driven) and a slave can quite validly not be connected or replicating at any point in time (stopped to take a backup …

Hearing from Brian that UDFs might be slower than native functions in MySQL, I did a small benchmark.

mysql> select benchmark(1e9,abs(1));
+-----------------------+
| benchmark(1e9,abs(1)) |
+-----------------------+
|                     0 | 
+-----------------------+
1 row in set (27.15 sec)

mysql> select benchmark(1e9,udf_abs(1));
+---------------------------+
| benchmark(1e9,udf_abs(1)) |
+---------------------------+
|                         0 | 
+---------------------------+
1 row in set (43.04 sec)

The numbers were taken on my MacBook (Core 2 Duo @ 2GHz, OS X 10.4.11) running the official binary version of MySQL 5.1.25-rc for 32-bit arch. So the overhead of UDFs compared to native functions seems to be about 30 clocks per each call.

So the question is whether it would matter on an actual application. I created a 100k row heap table and performed …

The Boston MySQL User Group was lucky enough to get Keith Murphy to speak at the June User Group meeting, about backups.

Direct play the video at:
http://technocation.org/node/559/play

Direct download the video (351 MB) at:
http://technocation.org/node/559/download

Links referred to in the presentation:

MyLVMBackup by Lenz Grimmer
http://lenz.homelinux.org/mylvmbackup/

InnoDB Hot Backup:
Prices are at:
http://www.innodb.com/hot-backup/order/
and at the time of this writing are:
1-Year License ? 390 USD$ 605 per server
…

The Boston MySQL User Group was lucky enough to get Keith Murphy to speak at the June User Group meeting, about backups.

Links referred to in the presentation:

MyLVMBackup by Lenz Grimmer
http://lenz.homelinux.org/mylvmbackup/

InnoDB Hot Backup:
Prices are at:
http://www.innodb.com/hot-backup/order/
and at the time of this writing are:
1-Year License ? 390 USD$ 605 per server
Perpetual License ? 990 USD$ 1540 per server

read more

I’ve had to accept the “practice what you preach” pill recently due to a disaster at my hosting provider. See Learning from a Disaster.

While it was my own personal site on a dedicated server in question and not a business generating review I found that my MySQL Backup Strategy was incomplete ( It is also based on code 4 years old). I found that I had not tested my Disaster Recovery Plan adequately. I have used my backup and recovery approach in the past for various controlled situations and testing successfully.

So what mistakes did I make. There were two.

1. I was using a cold backup approach. That is specifically copying the entire MySQL Database in a controlled manner at the file system level. These were also copied to an alternate shared hosting server for storage. This works fine when you backup server supports a …

I’m happy to say that the market response to our launch continues to be positive. So far we have had nearly 30 postings on the leading blogs in the MySQL world as well as close to 20 articles published in traditional media. Our press releases were picked up and published on over 30 sites. We had about 400 people stop by our booth at the MySQL conference and we continue to get a significant number of prospective customers and partners contacting us every week who want to know more about the company and our product.

Though the response has been very enthusiastic there has also been some healthy skepticism about how well the product would perform in real customer environments. In this post I’d like to briefly describe the results we are seeing at one of our beta customers.

The customer in question is a publicly traded company that manages the online forums for large media and web businesses. They use MySQL extensively today …

As I indicated in my previous post on MySQL performance, we have been doing some performance work using an internally developed web2.0 application. Akara and I will be presenting this app publicly to a large audience for the first time at the upcoming Velocity Conference in Burlingame, CA on June 23, 24. Check out our abstract.  Most of our work uses Cool Stack so a lot of the results we will be presenting will be based on that. If you're struggling with performance issues, this conference may be worth checking out.
If you will be attending the conference, please stop by and say hello. It's always good to see people whom we only know through blogs and forums.

This rocks. It’s not complete, but Pyshards is the closest thing I’ve seen to a real attempt at making a more or less generic sharding toolkit, written in Python. This is not just great because it’s written in Python or because it helps people who need sharding capabilities in MySQL. It’s great because having a toolkit to use for this benefits the community by creating a point of reference for how to get things done, and can help unite those who are treading into this territory and help them all get a leg up on this beast that is “sharding”.

I, for one, have found ways (so far) to avoid having to do this. It’s a good bit of complexity for data that would otherwise be very simple, and an infrastructure architecture that would otherwise also be simple (by design). But one of the things that makes sharding seem complex is that there aren’t any …