Over in Maatkit-land, Daniel Nichter and I practice test-first programming, AKA test-driven development. That is, we write tests for each new feature or to catch regressions on each bug we fix. And – this is crucial – we write the tests before we write the code.* The tests should initially fail, which is a validation that the new code actually works and the tests actually verify this. If we don’t first write a failing testcase, then our code lacks a very important guarantee: “if you break this code, then the test case will tell you so.” (A test that doesn’t fail when the code fails isn’t worth writing.)

This is the second post in the weekly series "Last Week in Drizzle" where we summarize the efforts of various folks in the Drizzle community over the past week. This edition encapsulates the work and conversations taking place over the past two weeks as both a vacation and procrastination took their toll on getting the weekly edition done. As with the week before, a number of developers and community advocates continue to refactor the code base, come together in discussions on the mailing list, and brainstorm on how to solve the tough problems that Drizzle is trying to address. Mark Schoonover and myself are now collaborating on the Last Week in Drizzle series. Thanks Mark!

Growth in the Drizzle Community

The week before last, we had 148 subscribers to the …

If your blog is anything like mine, the vast majority of comments are spam. Most blogs have at least a 50% ratio of spam-to-valid comments, and Pablowe has a 99.4% ratio (which is probably why there are so many Anti-Spam plugins for WordPress). One of the most oft-executed queries (based on the [...]

For those that have been using Planet MySQL to follow the progress of Drizzle, we now have our own Planet Drizzle.

You can also get a RSS feed directly from http://feeds.feedburner.com/drizzle

Well, after I talked about the Blue Screen of Death during the Olympics, arstechnica mentioned it.
































The more important point though, is the discussion in the comments.
Here are the theories as to why the BSOD happened:
1) Hard disk failure
2) Pirated copy of Windows with not all the right updates
3) …

Should you use memcached? Should you just shard mysql more?
Memcached's popularity is expanding its use into some odd places. It's becoming an authoritative datastore for some large sites, and almost more importantly it's sneaking into the lowly web startup. This is causing some discussion.

Most of whom seem to be missing the point. In this post I attempt to explain my point of view for how memcached should really influence your bouncing baby startups, and even give some pointers to the big guys who might have trouble seeing the forest through the trees.

Using memcached does not scale your website! …

Should you use memcached? Should you just shard mysql more?
Memcached's popularity is expanding its use into some odd places. It's becoming an authoritative datastore for some large sites, and almost more importantly it's sneaking into the lowly web startup. This is causing some discussion.

Most of whom seem to be missing the point. In this post I attempt to explain my point of view for how memcached should really influence your bouncing baby startups, and even give some pointers to the big guys who might have trouble seeing the forest through the trees.

Using memcached does not scale your website! …

So, I wrote about the begining of our wild database issues. Since then, I have been fighting a cold, coaching little league football and trying to help out in getting our backup solutions working in top shape.  That does not leave much time for blogging.

Never again will we have ONLY a cold backup of anything.  We were moving nightly full database dumps and hourly backups of critical tables over to that box all day long.  Well, when the filesystem fails on both the primary database server and your cold backup server, you question everything.  A day after my marathon drive to fix the backup server and get it up and running, the backup mysql server died again with RAID errors.  I guess that was the problem all along.  In the end, we had to have a whole new RAID subsystem in our backup database server.  So, my …

I had a long flight from Sydney to Edinburgh this weekend, and wanted to answer a common training question - how fast/slow is the stored proc language in MySQL. To do this, I started by stealing an example exercise we have in one of our exercises:


DELIMITER //
CREATE FUNCTION fibonacci(n INT)
RETURNS DOUBLE
NO SQL
BEGIN
DECLARE f1, result DOUBLE DEFAULT 0.0;
DECLARE f2 DOUBLE DEFAULT 1.0;
DECLARE cnt INT DEFAULT 1;
WHILE cnt <= n DO
SET result = f1 + f2;
SET f1 = f2;
SET f2 = result;
SET cnt = cnt + 1;
END WHILE;
RETURN result;
END //


If I run this a few times, here are the results:

mysql> select benchmark(100, fibonacci(40000));
+----------------------------------+
| benchmark(100, …

I had a long flight from Sydney to Edinburgh this weekend, and wanted to answer a common training question - how fast/slow is the stored proc language in MySQL. To do this, I started by stealing an example exercise we have in one of our exercises:


DELIMITER //
CREATE FUNCTION fibonacci(n INT)
RETURNS DOUBLE
NO SQL
BEGIN
DECLARE f1, result DOUBLE DEFAULT 0.0;
DECLARE f2 DOUBLE DEFAULT 1.0;
DECLARE cnt INT DEFAULT 1;
WHILE cnt <= n DO
SET result = f1 + f2;
SET f1 = f2;
SET f2 = result;
SET cnt = cnt + 1;
END WHILE;
RETURN result;
END //


If I run this a few times, here are the results:

mysql> select benchmark(100, fibonacci(40000));
+----------------------------------+
| benchmark(100, …