A little more than a year ago, I was hired to implement row-based replication to the MySQL database server. Since the principles are easy enough, I thought this would be a straightforward task to be done in a few months, tops. As always, I quickly got punished for my hybris: getting a basic row-based replication up and running was relatively straightforward but as the saying goes, the devil is in the details. Row-based replication is now safely tucked away in MySQL 5.1 for anybody who wishes to use it, but the obvious question is then what does it give me and why should I use it?

When using statement based replication, the replication is accomplished by replicating the actual SQL statements to the slave server directly. That works fine for most statements, but in some situations, this does not work as expected. This time, we will only look into one such situation. Consider the following SQL statements:

UPDATE account
 SET …

I have recently seen a couple of posts on the MySQL forums with regard to debugging stored procedures in MySQL. The people asking have been Oracle developers who like most people developing stored procedures in Oracle have been using an Oracle built in package called DBMS_OUTPUT. The package essentially accepts text which is then inserted into a buffer which can be viewed after a procedure has been executed (or even during using the correct tools). It got me thinking how easy it would be to add a similar debug method to MySQL so I came up with the following.

I created a new database called debug, this isn't strictly necessary but I like the idea of having a set area for the debug constructs to reside. I then created a table to hold the output, to keep it simple I simply gave it an id column so we could use the debug across a number of procedures at once, a text column to hold out debug statements and an auto increment column so I could …

I'm sorry to report that the video of the last Boston MySQL meetup isn't going to see the light of day. The meetup was good, ~20 in attendance to listen to a presentation on MySQL cluster that I put together and have a discussion about the technology.

I spent some time fiddling with the video we shot, but the fact that we had no microphone or tripod, and were in a huge auditorium at MIT where the camera had to be set at the back to capture the slides on the mega-screen all add up to a dark video with unacceptable (many times inaudible) audio. There are chunks of time where the video is almost pure black while hearing comments from attendees. Next time will be better.

As always, thanks to MySQL AB for pizza and soda. Also to the group member who scrambled to find a new room when the room we were supposed to use was double-booked.

Not long now until LinuxWorld Boston gets underway.

This year I've been conned into helping at the Apress booth on Thursday afernoon for a bit and will be meeting up with Jay and Jason for lunch. In the past I've gone over for one afternoon just to check out the exhibits. This year I'm also going to head over on Tuesday at 4 for the Golden Penguin Bowl, which should be fun:

Back by popular demand, it's the Golden Penguin Bowl. Expect an epic battle this year, as we bring you the riveting spectacle of Oracle nerds vs. MySQL geeks. Find answers to age-old questions like "What is your name?", "What is your favorite color?", and "What is the terminal velocity of an unladen swallow?" This …

Finally found time to fix Bug#16365, which is a request to add a limit for the total number of prepared statements in the server. It turns out to be a pretty useful feature, at least I was able to find 4 statement leaks in the test suite with it. The patch adds server variables to limit and monitor the count of prepared statements:

mysql> show variables like '%stmt%';
 ------------------------- ------- 
| Variable_name           | Value |
 ------------------------- ------- 
| max_prepared_stmt_count | 16382 |
| prepared_stmt_count     | 0     |
 ------------------------- ------- 
2 rows in set (0.00 sec)

Notice that this is slightly different from the status information, as in the status we account for all prepares and executes, including unsuccessful ones:

mysql> prepare stmt from "select 1"; prepare stmt1 from "select 2";
mysql> prepare stmt2 from "select …

A momentous occasion, Planet MySQL now has a total of 100 feeds! That's only 8 months after we introduced the new software and put some extra attention into it.

The 100th feed submission happened to come from Taneli Otala. Excellent! Meanwhile Brian has been nudging David to blog also....

Open Source gurus, I need your assistance.

Should I Open Source Adoppt or not?

Will it be a good idea to make the code available. Are there any ways I can continue paying my bills with OS?

Can OS be restricted to personal use only?

--Frank

Not very subtle title?

But look at databases, and applications using databases...
You've got your databases, tables and columns. Exciting? Or yawn...

Think of data, not by columns and type, but rather how it lives.

- Some data participates in "business logic" — what to show, how to show, related to other tables, etc.
- Some data changes often, some is literally static
- Some data needs to remain static, try Sarbanes-Oxley?, or J-SOX the Japanese counterpart
- Some data is small, but some is large (music, movies, pics)
- Some tables need to be transactional, some you couldn't care less

So, what — just cram it all in a database...?

Consider this — for each of the examples above, there is a penalty you pay, either in storage or performance for your choice.

What if you …

MySQL — or, as I was frequently instructed, you spell it My-Ess-Que-Ell?...

Something everybody learns when starting at MySQL — though few as forcefully as I learned, when staying my first few weeks with Monty.

Ok, so I'm no spring chick anymore... it took me two weeks to learn the mantra, and now I have been assimilated.
But, look at it from the lighter perspective — if that was the hardest part — then the rest is really easy.

If you can handle more Monty stories, check out the interview:
 http://dev.mysql.com/tech-resources/interviews/taneli-otala-mysql.html

But, what I really want to write about in this blog is about databases, or data management — future trends, how to make some entirely new and efficient applicatiions without changing too much. It's all about understanding the nature of data, not …

Not very subtle title?

But look at databases, and applications using databases...
You've got your databases, tables and columns. Exciting? Or yawn...

Think of data, not by columns and type, but rather how it lives.

- Some data participates in "business logic" — what to show, how to show, related to other tables, etc.
- Some data changes often, some is literally static
- Some data needs to remain static, try Sarbanes-Oxley?, or J-SOX the Japanese counterpart
- Some data is small, but some is large (music, movies, pics)
- Some tables need to be transactional, some you couldn't care less

So, what — just cram it all in a database...?

Consider this — for each of the examples above, there is a penalty you pay, either in storage or performance for your choice.

What if you …