eG Monitoring  

Measures reported by MySQLBinLogTest

The binary log is a set of log files that contain information about data modifications made to a MySQL server instance. The binary log contains all statements that update data. It also contains statements that potentially could have updated it (for example, a DELETE which matched no rows), unless row-based logging is used. Statements are stored in the form of "events" that describe the modifications. The binary log also contains information about how long each statement took that updated data.

The binary log also contains some other metadata, including:

  • Information about the state of the server that is needed to reproduce statements correctly.

  • Error codes

  • Metadata needed for the maintenance of the binary log itself (for example, rotate events)

The binary log has two important purposes:

  • For replication, the binary log is used on master replication servers as a record of the statements to be sent to slave servers. Many details of binary log format and handling are specific to this purpose. The master server sends the events contained in its binary log to its slaves, which execute those events to make the same data changes that were made on the master. A slave stores events received from the master in its relay log until they can be executed. The relay log has the same format as the binary log.

  • Certain data recovery operations require use of the binary log. After a backup file has been restored, the events in the binary log that were recorded after the backup are re-executed. These events bring databases up to date from the point of the backup.

If the server is unable to write to the binary log, flush binary log files, or synchronize the binary log to disk, the binary log on the replication source server can become inconsistent and replicas can lose synchronization with the source. This may result in outdated data in the replicas and sometimes, data loss too may occur if the source server fails/crashes before synchronization with the replicas. To avoid such eventualities, it is essential to keep track on the growth of the binary log. At the same time, it is also essential for the administrators to keep track on any abnormalities noticed in the size and growth of the binary log. The MySQLBinLogTest helps administrators in this regard!

This test reports the number of log files in the binary log and tracks the total size of the binary log. This test also periodically reports the growth of the binary log. Using this test, administrators can figure out abnormal growth patterns of the binary log and analyze the reason behind the same. Detailed Diagnostics reveal the exact name of the log files that have been modified recently.

This test reports whether/not the deadlock detection is enabled and reports the count of deadlocks that occurred on the target MySQL database server.

Outputs of the test : One set of results for the target database server instance being monitored.

The measures made by this test are as follows:

Measurement Description Measurement Unit Interpretation
binLogFileCount Indicates the number of log files in the binary log. Number  
totalSize Indicates the total size of the binary log. MB  
growthRate Indicates the rate at which the binary log file had grown during the last measurement period. MB/sec A high value for this measure or a consistent increase in its value indicates that the binary log is rapidly growing and may end up occupying too much space on the disk.

The detailed diagnosis of this measure lists the name of the log file, the size of the log file and the rate at which each log file had grown.