When running InnoDB you are able to dig into the engine internals, look at
various gauges and counters, see past deadlocks and the list of all open
transactions. This is in your reach with one simple command -
SHOW ENGINE INNODB STATUS
. On most occasions it works beautifully. The problems appear when you have a
large spike in number of connections to MySQL, which often happens when several
transactions kill the database performance resulting in very long execution
times for even simplest queries, or a huge deadlock.
In such rare cases
SHOW ENGINE INNODB STATUS
often fails to provide the necessary information. The reason is that its
output is limited to 64000 bytes, so a long list of transactions or a large
deadlock dump may easily exhaust the limit. MySQL in such situation truncates
the output so it fits the required size and obviously this is not good since you
may lose some valuable information from your sight.
With large deadlocks you can actually deal by
intentionally creating a new tiny deadlock which will replace the previous one
in the output thus reducing the space occupied by that section of InnoDB
status. Baron once wrote an article on how to do this.
There is not such easy way for the long transaction list, but fortunately
there are some alternatives to the limited MySQL command output.
First one is that you can have
innodb-status-file option set in your my.cnf. This will
make InnoDB to write the full status output into
innodb_status.<PID>
file located in MySQL data directory. Unfortunately this is a startup time
parameter, so unless you set it early, it will not be available in an emergency
situation.
Other possibility is to create a special InnoDB table called
innodb_monitor
CREATE TABLE innodb_monitor(a INT) ENGINE=innodb;
Creating it causes the full status to be
periodically printed into MySQL error log. You can later disable logging by
simply dropping the table. The problem I faced many times is that people do not
configure their error log at all, so the messages disappear into nothingness. So
what then?
I discovered that InnoDB will still create the status file on disk even if
you do not specify innodb-status-file option. The file is actually used for
every
SHOW ENGINE INNODB STATUS
call, so whenever someone runs the command,
InnoDB writes the output to that file first and then the stored information is
read back to user. To make things more difficult, MySQL keeps the file deleted,
so it is not possible access it with a simple catfilename or any other command through the file system. However
on many systems such as Linux or Solaris, but possibly also others, there is a
relatively simple way to access deleted but not-yet-closed files (file is
physically removed only after it is no longer open by any process).
First be sure to run
SHOW ENGINE INNODB STATUS
at least once. Then see what MySQL process ID is:
garfield ~ # ps ax | grep [m]ysqld
11886 ? Ssl 0:01 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf
In my case the process ID is 11886, so I will
be using it in the examples, but you should of course use whatever
PS returned to you.
Now you can use /proc to see all the file descriptors that are being
kept open by the process. So go to /proc/<PID> and list all the files
that were deleted.
garfield ~ # cd /proc/11886/fd
garfield fd # ls -l | grep deleted
lrwx------ 1 root root 64 Oct 31 18:26 12 -> /tmp/iblnLBhO (deleted)
lrwx------ 1 root root 64 Oct 31 18:26 5 -> /tmp/ibuQBSgo (deleted)
lrwx------ 1 root root 64 Oct 31 18:26 6 -> /tmp/ibLVtBuZ (deleted)
lrwx------ 1 root root 64 Oct 31 18:26 7 -> /tmp/ibsMzkIA (deleted)
lrwx------ 1 root root 64 Oct 31 18:26 8 -> /tmp/ibj08Rkc (deleted)
The entries are presented as symbolic links from file descriptor number to a
real path as in
12 -> /tmp/iblnLBhO
One of these entries is what you are looking
for, it’s often (always?) the file with the lowest file descriptor number, so in
my case it should be 5. But of course you can try reading a few first bytes
from every such file to discover where InnoDB status is. You can also help
yourself with lsof
tool available for many platforms:
garfield fd # lsof -c mysqld | grep deleted
mysqld 11886 mysql 5u REG 253,10 130932 12 /tmp/ibuQBSgo (deleted)
mysqld 11886 mysql 6u REG 253,10 0 13 /tmp/ibLVtBuZ (deleted)
mysqld 11886 mysql 7u REG 253,10 0 14 /tmp/ibsMzkIA (deleted)
mysqld 11886 mysql 8u REG 253,10 0 15 /tmp/ibj08Rkc (deleted)
mysqld 11886 mysql 12u REG 253,10 0 16 /tmp/iblnLBhO (deleted)
The 4th column contains file descriptor
numbers and in the 7th column there are the file sizes. This makes it obvious
that InnoDB status has to be under file descriptor 5 since it’s the only
non-zero length file.
So while you are still in /proc/<PID> directory, you can try
looking into that file:
garfield fd # cat 5
=====================================
081031 17:57:08 INNODB MONITOR OUTPUT
=====================================
Per second averages calculated from the last 33 seconds
----------
SEMAPHORES
----------
... snip ...
Keep in mind the file will only be refreshed when you run
SHOW ENGINE INNODB STATUS
command.
参考：http://www.mysqlperformanceblog.com/2008/10/31/full-innodb-status/
A quest for the full InnoDB status,码迷,mamicode.com