I'm working on an update to my myq_gadgets package for 5.1, particularly the innodb stats tracker.  I'm liking the additional stats that are in SHOW STATUS now for Innodb, particularly because I don't need to parse SHOW INNODB STATUS anymore.  I'm in love with being able to compare logical to physical I/Os for the buffer pool.  

I'm a bit confused, however, as some of my numbers don't quite line up.  Here's what I've got so far:

| Innodb Engine       Buffer Pool                        Data                     Log       Lock
Time         read  ins  upd  del  new read %phy wrte %phy %dirt wait read      wrte      fsyc wrte fsyc wait time
02/22-10:06  3.8k    0    0    0    0 9.8k  259 15.0  0.1   0.0    0  351 6.6M  0.9 2.6K  0.9  0.7  0.8    0    0
02/22-10:07  5.6k    0    0    0    0  14k  344 21.8  0.1   0.0    0  461 8.7M  1.3 3.9K  1.3  1.0  1.1    0    0

…

I’ve been coding a couple of scripts that run on 5 minute intervals to grab RSS/Atom feed data from http://mysql-dba.com and import that into a MySQL database. It idea is to create a search function for the site that will look at all past data from the aggregated feeds. Since there are multiple pollers running at different intervals I decided to use Innodb for the read/write nature of the poller/processing scripts.

This is very simple so far - and as such I felt it should be documented from the start unlike many of my other projects. Here’s the feed table that is storing the information from the RSS feeds.


mysql> show create table feed_items\G
*************************** 1. row ***************************
Table: feed_items
Create Table: CREATE TABLE `feed_items` (
`id` bigint(20) NOT NULL auto_increment,
`rss_site_id` int(11) …

This is the english translation of another article in my german language blog.

How are transactions organized physically

When InnoDB creates a new transaction it is not yet committed. The database has not yet made any promises to the application and so we do not really have to make anything persistent so far.

To be fast InnoDB tries to assemble the transaction in a memory buffer, the innodb_log_buffer. It should be sufficiently large that you actually can assemble such a transaction in memory without needing to write it out in part into the redo log. A size of 1M to 8M is normal.

Once a transaction is to be committed InnoDB has to read the page from disk which contains the image of the row that is being changed. It then has to actually make that change in memory. The changed page is …

This is an english translation of the second part of an article in my german language blog.

Transactions - An InnoDB tutorial

InnoDB does transactions. Meaning: It collects statements working on InnoDB tables and applies them on COMMIT to all tables "at once". Either all of these statements inside one transaction succeed ("commit") or all of them fail ("rollback"), changing nothing.

By default, the database is in AUTOCOMMIT mode. Meaning: The server sees a virtual COMMIT command after each statement. You can disable autocommit completely, or you are starting an explicit transaction inside autocommit using the BEGIN statement.

Continue reading "Transactions - An InnoDB …

MySQL offers a variety of storage engines giving you a lot of flexibility in managing your storage and data access needs. Still I encounter customers who are not using this flexibility when they should, because they lack information about the advantages of Non-MyISAM storage engines or which are using storage engines like InnoDB as if they were using MyISAM.

This is the introductory article in a series of texts that will hopefully once become an InnoDB tutorial. A german version of this article is available in my german language blog.

An InnoDB Tutorial

The InnoDB storage engine is an engine that can be operated ACID compliant, does transactions and foreign key constraints. It is useful for all applications that do online transaction processing or have a high rate of concurrent write accesses for other …

I'm pleased to announce that Tag1 Consulting has partnered up with MySQL AB to offer an online presentation titled "Achieving Optimal MySQL Performance For Drupal". Aiming to provide a better understanding of how to properly monitor and tune your MySQL database, the online Webinar will take place on Thursday, January 31st, 2008, at 16:00 UTC (11:00 am EST). The presentation will last 45 minutes, followed by 15 minutes for questions and answers.

read more

Went to the MySQL Performance Tuning Class last week. I would highly recommend it to any DBA new to MySQL, or any MySQL DBA looking to boost their tuning skills and understanding of some of the various features as they relate to performance.The next few posts will have to do with information I gleaned from that class...It's always good to understand what's happening underneath the covers when it

InnoDB is a transaction-safe, ACID compliant MySQL storage engine. It has commit, rollback, and crash recovery capabilities, and offers row level locking. The engine's overview page explains, “InnoDB has been designed for maximum performance when processing large data volumes. Its CPU efficiency is probably not matched by any other disk-based relational database engine.”

read more

We recommend two open source tools to help with the regular tuning and monitoring of your MySQL database: mysqlreport and mysqlsla. Your website is made from many complex systems. Rapid growth, changes to your site, and other systems can change the load on your MySQL database. It is important that your internal staff become familiar with using these tools and implement routine maintenance. An initial review often leads to significant improvements, and will also help you to implement a monitoring solution for your ongoing performance efforts.

read more

I've written before about how to figure out which connection is holding the InnoDB locks for which other connections are waiting. In other words, how to figure out who's blocking you from getting work done. The short and sweet: turn on the InnoDB lock monitor and use innotop to look at the locks held and waited-for. This has some disadvantages, so I made a patch to solve the issue the way I like it. The result is significantly more ability to find and solve InnoDB lock wait issues.