As you may know, MySQL has a dual-licensing model. You can get the source under the GPL version 2, or you can buy a commercial license.

I’ve recently been hearing a lot of confusion about when you have to buy a commercial license. People I’ve spoken to wrongly believe that they’re required to purchase a license if they’re going to use MySQL in anything but a not-for-profit business, for example. I don’t know how these notions get started, but they do.

So when are you required to buy a commercial license? It’s very simple: when you want to do something with MySQL that the GPL doesn’t permit.

I am not a lawyer, and you should do your own legal research, but misinterpretation of the GPL is rampant and I think I should try to counteract the misinformation about it if I can. Note that in this article I will …

There have been plenty of blog entries and writings about the MySQL Query Analyzer, for what I think are good reasons. Labeling it a potential Killer App, causing many MySQL users to become paying Sun customers, may be a daring thing. However, the Query Analyzer might very well have what it takes. The key benefit of it is that it identifies the source of performance bottlenecks. In that sense, one could perhaps instead call it a profiler, as it analyses the set of all queries going on, as opposed to an individual one. One person to whom I described it said “ah, so …

Progress on the Open Source enterprise grade MySQL monitoring system;  the schema for Monolith version 2 has been designed. Due to the many suggestions for features and the interest it has received I’ve put this on the front burner. That said, here is some more info on the next steps I’ll be taking.

• Monitored servers will use a command line agent (called remotely) to pull information from both MySQL and the OS.
• Historical information will include all values from global status and global variables, as well as CPU/Memory/IO/Disk usage.
• Standard graphing functions - the ones in the list from the previous post - will gather information from various view tables that contain historical data that is collected from the agent script. User defined graphing will allow you to look at historical values over time for any of the various global status or global variable settings (integer based ones anyway). …

What would you like to see in a free enterprise-grade monitoring system for your daily MySQL needs?I’m rewriting Monolith - MySQL DBA Console from the ground up. This will be version 2 and I would like to get some input from the global MySQL community.So far I am going with the following; comment with any improvements/additions.

• Variable interval polling of server statistics
• Over 50 different alerts (see list below)
• Graphing of various server statistics (see list below)
• Tuning recommendations with cnf file changes to apply to server
• Change control documents for recommended performance/security tuning
• Threshold based alerting with multiple alert groups: info,warn,critical
• Sorting/ordering of servers via groups. ie: client -> dev,stage,prod
• RSS feeds for each alert group
• XML export with user defined fields for external applications …

From a performance standpoint, sometimes even tightly tuned queries can cause a performance drag. The common problem here is not one of actual query performance, rather it is a function of:

- the velocity and frequency that a query is submiited for execution
- the total execution time of the aggregated executions

This could be symptomatic of an application not properly configured for caching (see Darren Oldag's blog on this!), or just overall poor design. Regardless of why, when or how we all know it happens. The trouble with this particular problem is that when a query is tuned, or very simple, it is usually not suspect for being a resource hog. Pulling aggregates for number of execs and total exec time for specific queries is a little tricky and labor intensive with the Slow Query Log, and not really a good …

One of the biggest problems I faced as a field DBA was defending my production databases against poorly performing SQL code. Talking to folks at the MySQL UC, during customer visits and trolling the MySQL forums/blogs confirms that this is a common problem and even more challenging when a performance problem pops up during times when no code promotions have taken place.

Traditional/popular way of finding bad SQL code
For MySQL DBAs the challenge to identify and isolate resource intensive SQL code is really two-fold; job #1 is to find the offending code (after that the chore becomes fixing it so it performs, but that is a topic for another post). Most MySQL DBAs have used the MySQL Slow Query Log ("SQ Log") at some point to help with job #1. For those not familiar, the SQ Log is enabled by starting MySQL with --log-slow-queries[=file_name] option. Once enabled the SQ Log captures queries that took longer than X seconds (user …

I have gotten a few questions around my 7/29 blog posting on agent vs client-side products and wanted to make it clear that our decision to go with a distributed agent architecture was a strategic decision that has paved the way for us to deliver on our overall "pain point" addressing roadmap. True, building a client-side app would have meant a faster go-to-market delivery, but that path would have imposed serious limitations on our ability to address and alleviate common pain points around the use and scaling of apps on MySQL.

So what does an agent really do for us from a strategic standpoint? Without revealing too many details (well, these things have already been openly discussed with customers and presented in our MySQL UC 2008 Product roadmap session), our agent-based architecture allows us to provide:
…

We are quickly approaching opening up the MySQL Query Analyzer for general beta and I wanted to pass along an open invite to the following related and informational events.

On 8/13, I will be doing a micro level presentation on MySQL Enterprise. Please attend and learn more about the database software, monitoring and advisor services and support solutions that make up a subscription. I plan to do a demo of the Enterprise Monitor and the new Query Analyzer; that alone makes attending worth the price of admission (in this case 45 minutes of your time!). Learn more and register here.

On 8/20, I will be doing a presentation on the new Query Analyzer. This will be a technical discussion around how DBAs monitor for bad queries now and how the Query Analyzer makes the job much easier. This will be a good time to learn about getting in …

As the Product Manager for MySQL Enterprise and the Enterprise Monitor I am constantly being asked questions from our Sales team, prospects, customers, etc. about how our products stack up against competing products. This is tough for a PM because competitive situations change with each new release cycle and ISVs (both free/open and commercial) with agile development practices can deliver new features in very short order. Further, getting into a feature-feature discussion is a no win situation because someone will ALWAYS have more check marks. Also, I tend to be more positive about competing products because a) healthy competition makes us all better and b) my competitors enable more people to use MySQL to build apps that will most likely need MySQL support and c) the best support for MySQL comes under a MySQL Enterprise subscription! With those things in mind you will *never* hear …

I’m attempting this is be as unbiased as possible, since I write the Monolith application. This will hopefully help one decide between a free MySQL server monitoring system and paying for a per-server based licensed product. Both have strengths and weaknesses that should be pointed out before making a decision. You can infer the weaknesses based on the strengths below. That said, let’s just get into it.

Strengths of each product over the other

Monolith - MySQL DBA Console

• presents overall database size, index size, data size, number of schema per server, and aggregate statistics for all monitored servers
• runs mysql server backups remotely and reports on backup state execution
• collects cnf files from each server during the talkback script execution for historical viewing
• built on the LAMP stack, no need for tomcat/jboss knowlege
• provides …