If you push play, the video should scoot out to about the 14m40s mark where MySQLTuner appears on one of the slides. Thanks to Trent Hornibrook for letting me know!

MySQLTuner mentioned at the O'Reilly MySQL Conference is a post from: Major Hayden's Racker Hacker blog.

Thanks for following the blog via the RSS feed. Please don't copy my posts or quote portions of them without attribution.

pv allows a user to see the progress of data through a pipeline, by giving information such as time elapsed, percentage completed (with progress bar), current throughput rate, total data transferred, and ETA.

The usage certainly isn't complicated:

To use it, insert it in a pipeline between two processes, with the appropriate options. Its standard input will be passed through to its standard output and progress will be shown on standard error.

A great application of pv is when you're restoring large amounts of data into MySQL, especially if you're restoring data under duress due to an accidentally-dropped table or database. (Who hasn't been there before?) The standard way of restoring data is something we're all familiar with:

# mysql my_database < database_backup.sql

The downside of this method is that you have no idea how quickly your restore is working or when it might be done. You could always open another terminal to monitor the tables and databases as they're created, but that can be hard to follow.

Toss in pv and that problem is solved:

# pv database_backup.sql | mysql my_database
96.8MB 0:00:17 [5.51MB/s] [==>                                ] 11% ETA 0:02:10

When it comes to MySQL, your restore rate is going to be different based on some different factors, so the ETA might not be entirely accurate.

Monitor MySQL restore progress with pv is a post from: Major Hayden's Racker Hacker blog.

Thanks for following the blog via the RSS feed. Please don't copy my posts or quote portions of them without attribution.

The guide: Redundant Cloud Hosting Guide

As always, if you find anything in the guide that needs improvement, I'm all ears.

A simple guide to redundant cloud hosting is a post from: Major Hayden's Racker Hacker blog.

Thanks for following the blog via the RSS feed. Please don't copy my posts or quote portions of them without attribution.

Many cloud providers allow you access to a private network environment where you can exchange data with other instances or other services offered by the provider. The convenience of this access comes with a price: other instances can access your instance on the private network just as easily as they could on the public interface.

Here are some security tips for your private interfaces:

Disable the private interface
This one is pretty simple. If you have only one instance or server, and you don't need to communicate privately with any other instances, just disable the interface. Remember to configure your networking scripts to leave the interface disabled after reboots.

Use packet filtering
The actual mechanism will vary based on your operating system, but filtering packets is the one of the simplest ways to secure your private interface. You can take some different approaches with them, but I find the easiest method is to allow access from your other instances and reject all other traffic.

For additional security, you can limit access based on ports as well as source IP addresses. This could prevent an attacker from having easy access to your other instances if they're able to break into one of them.

Configure your daemons to listen on the appropriate interfaces
If there are services that don't need to be listening on the private network, don't allow them to listen on your private interface. For example, MySQL might need to listen on the private interface so the web server can talk to it, but apache won't need to listen on the private interface. This reduces the profile of your instance on the private network and makes it a less likely target for attack.

Use hosts.allow and hosts.deny
Many new systems administrators forget about how handy tcpwrappers can be for limiting access. If your firewall is down in error, host.allow and hosts.deny could be an extra layer of protection. It's important to ensure that the daemons you are attempting to control are build with tcpwrappers support. Daemons like sshd support it, but apache and MySQL do not.

Encrypt all traffic on the private network
Just because it's called a "private" network doesn't mean that your traffic can traverse the network privately. You should always err on the side of caution and encrypt all traffic traversing the private network. You can use ssh tunnels, stunnel, or the built-in SSL features found in most daemons.

This also brings up an important point: you should know how your provider's private network works. Are there safeguards to prevent sniffing? Could someone else possibly ARP spoof your instance's private IP addresses? Is your private network's subnet shared among many customers?

With all of that said, it's also very important to have proper change control policies so that administrators working after you are fully aware of the security measures in place and why they are important. This will ensure that all of the administrators on your instances will understand the security of the system and they should be able to make sensible adjustments later for future functionality.

Private network interfaces: the forgotten security hole is a post from: Major Hayden's Racker Hacker blog.

Thanks for following the blog via the RSS feed. Please don't copy my posts or quote portions of them without attribution.

ERROR 1206 (HY000): The total number of locks exceeds the lock table size

MySQL is trying to tell you that it doesn't have enough room to store all of the row locks that it would need to execute your query. The only way to fix it for sure is to adjust innodb_buffer_pool_size and restart MySQL. By default, this is set to only 8MB, which is too small for anyone who is using InnoDB to do anything.

If you need a temporary workaround, reduce the amount of rows you're manipulating in one query. For example, if you need to delete a million rows from a table, try to delete the records in chunks of 50,000 or 100,000 rows. If you're inserting many rows, try to insert portions of the data at a single time.

Further reading:

• MySQL Bug #15667 - The total number of locks exceeds the lock table size
• MySQL Error 1206 » Mike R's Blog

MySQL: The total number of locks exceeds the lock table size is a post from: Major Hayden's Racker Hacker blog.

Thanks for following the blog via the RSS feed. Please don't copy my posts or quote portions of them without attribution.

ERROR 1206 (HY000): The total number of locks exceeds the lock table size

InnoDB stores its lock tables in the main buffer pool. This means that the number of locks you can have at the same time is limited by the innodb_buffer_pool_size variable that was set when MySQL was started. By default, MySQL leaves this at 8MB, which is pretty useless if you're doing anything with InnoDB on your server.

Luckily, the fix for this issue is very easy: adjust innodb_buffer_pool_size to a more reasonable value. However, that fix does require a restart of the MySQL daemon. There's simply no way to adjust this variable on the fly (with the current stable MySQL versions as of this post's writing).

Before you adjust the variable, make sure that your server can handle the additional memory usage. The innodb_buffer_pool_size variable is a server wide variable, not a per-thread variable, so it's shared between all of the connections to the MySQL server (like the query cache). If you set it to something like 1GB, MySQL won't use all of that up front. As MySQL finds more things to put in the buffer, the memory usage will gradually increase until it reaches 1GB. At that point, the oldest and least used data begins to get pruned when new data needs to be present.

So, you need a workaround without a MySQL restart?

If you're in a pinch, and you need a workaround, break up your statements into chunks. If you need to delete a million rows, try deleting 5-10% of those rows per transaction. This may allow you to sneak under the lock table size limitations and clear out some data without restarting MySQL.

To learn more about InnoDB's parameters, visit the MySQL documentation.

MySQL: The total number of locks exceeds the lock table size is a post from: Major Hayden's Racker Hacker blog.

Thanks for following the blog via the RSS feed. Please don't copy my posts or quote portions of them without attribution.

If you don't want to downgrade to PHPMyAdmin 2.x, just add the following line to the top of your config.inc.php file:

$cfg['InitialSlidersState'] = 'open';

This will cause the indexes to be displayed when you click Structure for a certain table. By default, they are hidden.

Sidenote: Some of you might be thinking: "Hey, you're a DBA, you should know MySQL queries without needing PHPMyAdmin." You're right. I do know how to get the job done without PHPMyAdmin, but I enjoy the way PHPMyAdmin allows me to visualize my table structures. Also, it's a handy way to present data to others very quickly.

PHPMyAdmin 3.x hides the table indexes is a post from: Major Hayden's Racker Hacker blog.

Thanks for following the blog via the RSS feed. Please don't copy my posts or quote portions of them without attribution.

While it won't include all situations, it will give ideas to those who are just starting down the path of MySQL optimization. If you find any corrections or if you have suggestions for improvements, please let me know!

UPDATE: I've received a lot of positive feedback via twitter and e-mail about the flow chart idea. I'll try to work on some more charts soon and get them onto the site. Let me know if there are specific topics that you're interested in.

MySQL performance flow chart is a post from: Major Hayden's Racker Hacker blog.

Thanks for following the blog via the RSS feed. Please don't copy my posts or quote portions of them without attribution.

As always, I'd like to personally thank everyone who has made this release possible. Your efforts have provided benefits from MySQL users worldwide, and they have shown me how rewarding it is to maintain open source software.

MySQLTuner 1.0.0 is now available is a post from: Major Hayden's Racker Hacker blog.

Thanks for following the blog via the RSS feed. Please don't copy my posts or quote portions of them without attribution.

PHPExcelReader - http://sourceforge.net/projects/phpexcelreader/
Spreadsheet_Excel_Writer - http://pear.php.net/package/Spreadsheet_Excel_Writer

Once you've downloaded both items, upload them to your server. Your directory listing on your server should have two directories: Excel (from PHPExcelReader) and Spreadsheet_Excel_Writer-x.x.x (from Spreadsheet_Excel_Writer). To work around a bug in PHPExcelReader, copy oleread.inc from the Excel directory into a new path:

Spreadsheet/Excel/Reader/OLERead.php

The PHPExcelReader code will expect OLERead.php to be in that specific location. Once that is complete, you're ready to use the PHPExcelReader class. I made an example Excel spreadsheet like this:

Name                Extension   Email
----------------------------------------------------
Jon Smith           2001        jsmith@domain.com
Clint Jones         2002        cjones@domain.com
Frank Peterson      2003        fpeterson@domain.com

After that, I created a PHP script to pick up the data and insert it into the database, row by row:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

require_once 'Excel/reader.php';
$data = new Spreadsheet_Excel_Reader();
$data->setOutputEncoding('CP1251');
$data->read('exceltestsheet.xls');
 
$conn = mysql_connect("hostname","username","password");
mysql_select_db("database",$conn);
 
for ($x = 2; $x < = count($data->sheets[0]["cells"]); $x++) {
    $name = $data->sheets[0]["cells"][$x][1];
    $extension = $data->sheets[0]["cells"][$x][2];
    $email = $data->sheets[0]["cells"][$x][3];
    $sql = "INSERT INTO mytable (name,extension,email) 
        VALUES ('$name',$extension,'$email')";
    echo $sql."\n";
    mysql_query($sql);
}

After the script ran, each row had been added to the database table successfully. If you have additional columns to insert, just repeat these lines, using an appropriate variable for each column:

$variable = $data->sheets[0]["cells"][$row_number][$column_number];

For more details, you can refer to a post in Zend's Developer Zone.

Importing Excel files into MySQL with PHP is a post from: Major Hayden's Racker Hacker blog.

Thanks for following the blog via the RSS feed. Please don't copy my posts or quote portions of them without attribution.

If you want to know when the latest releases are available, there are multiple options:

• Follow RackerHacker on Twitter
• Sign up for the MySQLTuner mailing list
• Use the --checkversion option when you run the script

MySQLTuner 0.9.9 is now available is a post from: Major Hayden's Racker Hacker blog.

Thanks for following the blog via the RSS feed. Please don't copy my posts or quote portions of them without attribution.

Easy download!
You can download it simply by running wget mysqltuner.pl. You will automatically be redirected to the script.

Access servers remotely
If you have multiple servers that you need to tune and monitor, simply download MySQLTuner onto one machine. You can run it against other servers by specifying a hostname, port, and login credentials. Two new options are available: --host and --port.

Pass login credentials on the command line
Two new options are available: --user and --pass. You can pass a username and password on the command line to log in quickly. This can be especially helpful in conjunction with cron.

Manually set the amount of RAM and swap memory installed
I've received a few bug reports where users on certain virtual environments saw incorrect memory calculations when they ran MySQLTuner. You can now set the current amount of RAM and swap memory installed with --forcemem and --forceswap respectively. (Thanks to Jason Gill for the patch and the bug report!)

Checking for updates is now optional
Some operating system distributions and environments can't allow for automatic update checking due to security concerns, so I've made update checks optional. The --skipversion option has been removed and it was replaced with --checkversion. As a side note, the only data that I collected was the version number being run and the IP from which the update originated. This data has only been used for aggregate statistical purposes.

As you might imagine, MySQLTuner 1.0 is just around the corner. I've been holding out for the MySQL 5.1 GA release, but I may release the script sooner. Don't worry - as soon as MySQL 5.1 becomes a GA release, I'll be hard at work to support any new optimization options which it provides.

MySQLTuner 0.9.8 is now available is a post from: Major Hayden's Racker Hacker blog.

Thanks for following the blog via the RSS feed. Please don't copy my posts or quote portions of them without attribution.

# cat /etc/fedora-release
Fedora release 9 (Sulphur)
# yum info mysqltuner
Loaded plugins: fastestmirror, priorities, refresh-packagekit
Loading mirror speeds from cached hostfile
* updates: mirrors.usc.edu
* fedora: mirror.unl.edu
* livna: mirrors.tummy.com
Available Packages
Name : mysqltuner
Arch : noarch
Version : 0.9.1
Release : 4
Size : 11 k
Repo : updates
Summary : MySQL high performance tuning script
URL : http://mysqltuner.com/
License : GPLv3+
Description: MySQLTuner is a MySQL high performance tuning script written in perl that will provide you with a snapshot of a MySQL server's health. Based
: on the statistics gathered, specific recommendations will be provided that will increase a MySQL server's efficiency and performance. The
: script gives you automated MySQL tuning that is on the level of what you would receive from a MySQL DBA.

In addition to Ville, I'd like to thank Jason Tibbitts for reviewing and approving the new package.

MySQLTuner is now a Fedora 9 package! is a post from: Major Hayden's Racker Hacker blog.

Thanks for following the blog via the RSS feed. Please don't copy my posts or quote portions of them without attribution.

# mysql
ERROR 1040: Too many connections

MySQL is telling you that it is handling the maximum connections that you have configured it to handle. By default, MySQL will handle 100 connections simultaneously. This is very similar to the situation when Apache reaches the MaxClients setting. You won't even be able to connect to MySQL to find out what is causing the connections to be used up, so you will be forced to restart the MySQL daemon to troubleshoot the issue.

What causes MySQL to run out of connections? Here's a list of reasons that may cause MySQL to run out of available connections, listed in order of what you should check:

Bad MySQL configuration
Verify that you have set MySQL's buffers and caches to appropriate levels for the type of data you're storing and the types of queries that you are running. One quick way to check this information is via MySQLTuner. The script will tell you how well your server is performing along with the corrections you should make. Running the script only takes a few moments and it doesn't require a DBA to decipher the results.

Data storage techniques
Remember that MySQL works best when moving vertically, not horizontally. If you have a table with 20 columns, breaking it into two tables with 10 columns each will improve performance. Even if you need to join the two tables together to get your data, it will still perform at a higher level. Also, use the right data types for the right data. If you're storing an integer only, don't use a CHAR or VARCHAR data type. If your integer will be small, then use something like a TINYINT or SMALLINT rather than INT. This means MySQL will use less memory, pull less data from the disk, and have higher performing joins.

Slow queries
These are generally pretty easy to fix. If you have queries that don't use indexes, or if queries run slowly with indexes in place, you need to rethink how you're pulling your data. Should your data be split into multiple tables? Are you pulling more data than you need? Keep these questions in mind, enable the slow query log, and re-work your queries to find where the bottlenecks occur.

Division of labor
Most people who use MySQL have a dynamic site written in a scripting language, like PHP, Perl or Python. It's obvious that your server will need to do some work to parse the scripts, send data back to the client, and communicate with MySQL. If you find that your server is overworked, consider moving MySQL to its own dedicated hardware. Among many other things, this will reduce your disk I/O, allow you to better utilize memory, and it will help you when you need to scale even further. Be sure to keep your MySQL server close to your web servers, however, as increased latency will only make your performance problem first.

Right hardware
Do you have the right hardware for the job? Depending on your budget, you may need to make the move for hardware that gives you better I/O throughput and more useable cores. MySQL is a multi-threaded application, so it can utilize multiple cores to serve data quickly. Also, writing logs, reading tables, and adjusting indexes are disk-intensive tasks that need fast drives to perform well. When you look for a dedicated server for MySQL, be sure to choose multiple-core machines with low latency RAM, fast drives (SCSI/SAS), and a reliable network interface.

By reviewing these bottlenecks, you can reduce the load on your MySQL server without increasing your maximum connections. Simply increasing the maximum connections is a very bad idea. This can cause MySQL to consume unnecessary resources on your server and it may lead to an unstable system (crash!).

MySQL: ERROR 1040: Too many connections is a post from: Major Hayden's Racker Hacker blog.

Thanks for following the blog via the RSS feed. Please don't copy my posts or quote portions of them without attribution.

MySQLTuner 0.9.1 available for Mandriva users is a post from: Major Hayden's Racker Hacker blog.

Thanks for following the blog via the RSS feed. Please don't copy my posts or quote portions of them without attribution.

MySQLTuner now checks for fragmented tables
When deletes or updates are made on tables, MySQL will often leave holes behind that it hopes to fill in later. If the size and quantity keep climbing, the holes can cause performance degradation for writes and reads. Fragmentation can be corrected with OPTIMIZE TABLE, and the script recommends it if needed.

Fixed a bug where zero-length passwords cause authentication to repeat
The script will now allow you to have a zero-length password, and it won't re-prompt for the password over and over again.

Fixed a wget 1.11 timestamp bug
This can cause the version check to fail if the .wgetrc has timestamps enabled.

Corrected a math error in the temporary table calculation
The script should now be able to more accurately determine the relative quantity of temporary tables created on disk.

Fixed an error when the status variable Open_tables returned zero
The divide by zero error has been corrected.

Added table cache changes in preparation for MySQL 6
It's still in the early stages, but MySQLTuner should have full support for MySQL 6 by the time it reaches RC status.

Thanks for the contributions!
This update would not have been possible without help from Ville Skytta, Trent Hornibrook and Luuk Vosslamber.

To download the latest copy, visit the MySQLTuner page.

MySQLTuner v0.9.1 is now available is a post from: Major Hayden's Racker Hacker blog.

Thanks for following the blog via the RSS feed. Please don't copy my posts or quote portions of them without attribution.

I made a MySQL 3.23 compatible dump with --compatible=mysql323, but the dump came out with backticks around the database names. This works with some 3.23 versions, but it doesn't work with others. Apparently RHEL 3's MySQL 3.23 is one of those versions where it simply won't work.

This sed line came in handy to strip the backticks from the USE lines in the dump:

sed -e "s/^USE \`\(.*\)\`/USE \1/g"

Remove backticks from MySQL dumps is a post from: Major Hayden's Racker Hacker blog.

Thanks for following the blog via the RSS feed. Please don't copy my posts or quote portions of them without attribution.

At this point, I'm opening it up to you - what would you like to learn? Of course, I'm still planning to make a full set of screencasts for the MySQL DBA certification, but that will come later.

Screencast topic requests? is a post from: Major Hayden's Racker Hacker blog.

Thanks for following the blog via the RSS feed. Please don't copy my posts or quote portions of them without attribution.

mysql> DROP USER 'forums'@'db1.myserver.com';
ERROR 1268 (HY000): Can't drop one or more of the requested users

Naturally, I was quite interested to know why MySQL wasn't going to allow me to remove this user. There was nothing special about the user, but then again, this wasn't a server that I personally managed, so I wasn't sure what kind of configuration was in place.

It's always a good idea to get your bearings, so I checked the current grants:

mysql> SHOW GRANTS FOR 'forums'@'db1.myserver.com';
+----------------------------------------------------------------------+
| Grants for forums@db1.myserver.com                                   |
+----------------------------------------------------------------------+
| GRANT USAGE ON *.* TO 'forums'@'db1.myserver.com' WITH GRANT OPTION  |
+----------------------------------------------------------------------+
1 row in set (0.00 sec)

The GRANT OPTION was causing my grief. It was the only privilege that the user had on the server. I revoked the privilege and attempted to drop the user yet again:

mysql> REVOKE GRANT OPTION ON *.* FROM 'forums'@'db1.myserver.com';
Query OK, 0 rows affected (0.00 sec)

mysql> DROP USER 'forums'@'db1.myserver.com';
Query OK, 0 rows affected (0.00 sec)

It's key to remember that revoking the GRANT OPTION is a completely separate process. Revoking ALL PRIVILEGES doesn't include GRANT OPTION, so be sure to specify it separately:

mysql> REVOKE ALL PRIVILEGES, GRANT OPTION ON *.* FROM 'user'@'host';

MySQL: Can't drop one or more of the requested users is a post from: Major Hayden's Racker Hacker blog.

Thanks for following the blog via the RSS feed. Please don't copy my posts or quote portions of them without attribution.

The article goes over installing the Net::Amazon::S3 Perl module via WHM (which is handy for the cPanel users). However, if you're not a cPanel user, you can install it via CPAN:

# perl -MCPAN -e 'install Net::Amazon::S3'

If you'd rather install it through Webmin, go to the 'Others' section, and click 'Perl Modules'.

Also, Tim mentions configuring a Firefox extension for accessing S3 that works very well. However, I find myself using Safari most often, so I prefer to use Jungle Disk or Transmit on my Mac.

Overall, it's a great post, and I'm glad Tim told me about it!

Backing up MySQL to Amazon's S3 is a post from: Major Hayden's Racker Hacker blog.

Thanks for following the blog via the RSS feed. Please don't copy my posts or quote portions of them without attribution.

Fixed a bug in the enumeration/sizing of tables in MySQL 5
In MySQL 5 on some distributions, a NULL is returned for the storage engine and data length. Luuk Vosslamber quickly e-mailed me about the bug yesterday and it has been fixed.

MySQLTuner version checking
MySQLTuner will now check to see if a new version is available when the script runs. You can disable the check with the --skipversion option if you do not wish to perform the check.

The version check does not submit any information about the server, the MySQL installation, or any of your MySQL data. It simply queries a page on mysqltuner.com with the version number of your currently running script. Based on the value returned by the page, MySQLTuner will alert you if a new version is available.

To download the new version right now, please go to the project page and use the download links.

MySQLTuner v0.9.0 is now available is a post from: Major Hayden's Racker Hacker blog.

Thanks for following the blog via the RSS feed. Please don't copy my posts or quote portions of them without attribution.

Table enumeration and sizing can now be skipped
I've received reports that MySQLTuner will stall while enumerating tables on servers that contain a lot of tables or a lot of large tables.  You can now use the --skipsize option to skip over the table enumeration process and let the script finish.  However, you will not be able to receive some recommendations since the script was unable to determine which storage engines are enabled.

New table enumeration and sizing method for MySQL 5
The script now uses information_schema to enumerate tables and their sizes for MySQL 5 servers.  This has provided a drastic improvement in performance.

Readability improvements
The recommendations for query_cache_limit and max_heap_table_size/tmp_table_size have been improved.

As always, I welcome your suggestions, bug reports, and questions!  Please feel free to drop a comment on this blog posting or send me an e-mail (it's in the script).  Also, don't forget to sign up for the MySQLTuner version announcement list.

MySQLTuner v0.8.9 is now available is a post from: Major Hayden's Racker Hacker blog.

Thanks for following the blog via the RSS feed. Please don't copy my posts or quote portions of them without attribution.

ERROR 1118 (42000) at line 1686: Row size too large. The maximum row size for the used table type, not counting BLOBs, is 65535. You have to change some columns to TEXT or BLOBs

You really don't have any options in this situation. You'll need to adjust your table on the 64-bit server for good and then make a new dump file, or you will just have to live with the fact that it can't be imported into a 32-bit instance of MySQL.

Importing MySQL dumps made on 64-bit servers is a post from: Major Hayden's Racker Hacker blog.

Thanks for following the blog via the RSS feed. Please don't copy my posts or quote portions of them without attribution.

Newlines are placed between the sections for increased readability
Each section now contains extra lines to set the sections apart. It makes the output a little longer, but easier to read as well.

Storage engine status color bug
Even if the --nocolor option was passed, the storage engine statuses were being shown in color.

Excluded information_schema from storage engine calculations
The information_schema database was causing extra MEMORY tables to show up in the calculations. They're now excluded when the calculations are being made.

Shawn Ashlee has also been added as a contributor as he's been a constant help for the project. He's recommended implementation ideas and he has worked to create internal MySQLTuner RPM's for use at Rackspace. Thanks, Shawn!

MySQLTuner v0.8.6 is now available is a post from: Major Hayden's Racker Hacker blog.

Thanks for following the blog via the RSS feed. Please don't copy my posts or quote portions of them without attribution.

Fixed a copy/paste bug
There was a bug in 0.8.0 that displayed "OK" in red rather than showing "!!". It affected the informational "--" outputs as well. Thanks to Nils Breunese for pointing out that confusing bug!

Fixed a data length calculation bug with MySQL 4.0
If the script was run against MySQL 4.0 servers, it would return the Max_data_length rather than Data_length, and this was returning some horribly incorrect results for the size of tables in use with certain storage engines.

Fixed a key buffer calculation bug with MySQL 4.0
It's not possible to ask a MySQL 4.0 server about how much of the key buffer is in use, so the functionality for MySQL 4.0 now matches 3.23 for key buffer calculations.

Added a notification for well-optimized servers
For situations where MySQLTuner can't make any recommendations for performance increases, it actually says so now.

Version bump to 0.8.5
It's getting close to a full 1.0 release!

MySQLTuner v0.8.5 is now available is a post from: Major Hayden's Racker Hacker blog.

Thanks for following the blog via the RSS feed. Please don't copy my posts or quote portions of them without attribution.