| eG Monitoring |
|---|
|
Measures reported by MySQLIndbIOTest The redo log is a disk-based data structure used during crash recovery to correct data written by incomplete transactions. During normal operations, the redo log encodes requests to change table data that result from SQL statements or low-level API calls. Modifications that did not finish updating the data files before an unexpected shutdown are replayed automatically during initialization, and before connections are accepted. By default, the redo log is physically represented on disk by two files named ib_logfile0 and ib_logfile1. MySQL writes to the redo log files in a circular fashion. Data in the redo log is encoded in terms of records affected; this data is collectively referred to as redo. If InnoDB detects that the innodb_log_file_size differs from the redo log file size, it writes a log checkpoint, closes and removes the old log files, creates new log files at the requested size, and opens the new log files. When InnoDB has written the redo log files full, it must write the modified contents of the buffer pool to disk in a checkpoint. Small redo log files cause many unnecessary disk writes. Although historically big redo log files caused lengthy recovery times, recovery is now much faster and you can confidently use large redo log files. If too much of data is pending to be written/read from the InnoDB tables, then, data will be catered directly from the disks which is an expensive operation. To reduce such expensive disk reads and to improve the redo logs and buffer pool usage, the InnoDB tables should be populated with the data that is frequently accessed. This is why, it is important that the InnoDB tables are updated frequently with the data. Any delay in such reads/writes to the redo log files or the buffer pool of the InnoDB tables will have a significant impact in the disk I/O of the database server. It is therefore imperative that administrators are promptly notified if any slowness is observed in reads from disk to redo log files/buffer pool or writes from redo log files/buffer pool to disk. The MySQLIndbIOTest provides these useful alerts to administrators! This test monitors reads from the redo log files and writes to disk. Using this test, administrators canfigure out which type of operations is pending frequently on the redo logs - is it reads? or writes? or fsync() operations? In the process, the test proactively alerts administrators to potential latencies in reading from and/or writing to disk. Outputs of the test : One set of results for the MySQL server being monitored The measures made by this test are as follows:
|