MySQL Deadlocks Test
A deadlock is a situation where different transactions are unable to proceed because each holds a lock that the other needs. Because both transactions are waiting for a resource to become available, neither ever release the locks it holds. A deadlock can occur when transactions lock rows in multiple tables (through statements such as UPDATE or SELECT ... FOR UPDATE), but in the opposite order. A deadlock can also occur when such statements lock ranges of index records and gaps, with each transaction acquiring some locks but not others due to a timing issue. When deadlock detection is enabled (the default) and a deadlock does occur, InnoDB (the default MySQL Storage engine) detects the condition and rolls back one of the transactions.
If deadlock detection is disabled, InnoDB relies on the innodb_lock_wait_timeout setting to roll back transactions in case of a deadlock. Though the transactions can be rolled back after the time specified against the innodb_lock_wait_timeout setting, administrators have to patiently wait for the roll back to happen. To avoid such wait time, administrators need to constantly keep a vigil on whether the deadlock detection is enabled or not. The MySQL Deadlocks test helps administrators in this regard!
This test reports whether/not the deadlock detection is enabled and reports the count of deadlocks that occurred on the target MySQL database server.
Target of the test : A MySQL server
Agent deploying the test : An internal/remote agent
Outputs of the test : One set of results for the target database server instance being monitored
Parameter | Description |
---|---|
Test Period |
How often should the test be executed. |
Host |
The IP address of the MySQL server. |
Port |
The port at which the specified host listens. |
Database |
Specify the name of a database on the target MySQL database server being monitored |
Username and Password |
The eG agent has to be configured with the credentials of a user who has server-wide Process and Select privileges on the monitored MySQL server. To know how to create such a user, refer to Pre-requisites for Monitoring the MySQL Server |
Confirm Password |
Confirm the password by retyping it here. |
Detailed Diagnosis |
To make diagnosis more efficient and accurate, the eG Enterprise embeds an optional detailed diagnostic capability. With this capability, the eG agents can be configured to run detailed, more elaborate tests as and when specific problems are detected. To enable the detailed diagnosis capability of this test for a particular server, choose the On option. To disable the capability, click on the Off option. The option to selectively enable/disable the detailed diagnosis capability will be available only if the following conditions are fulfilled:
|
Measurement | Description | Measurement Unit | Interpretation | ||||||
---|---|---|---|---|---|---|---|---|---|
Is deadlock enabled? |
Indicates whether/not deadlock detection is enabled on the database instance. |
|
The values reported by this measure and its numeric equivalents are mentioned in the table below:
Note: By default, this measure reports the Measure Values listed in the table above to indicate whether/not deadlock detection is enabled on this instance. The graph of this measure however, is represented using the numeric equivalents only i.e., 0 or 1. |
||||||
Deadlock count |
Indicates the number of deadlocks found in the target database instance. |
Number |
A deadlock may arise due to various situations including bad design of queries and deficient coding practices. A deadlock is a situation where both/all the lock requestors are in a mutual or a multi-way tie. Any deadlocks are detrimental to database application performance. The detailed diagnosis of this measure lists the Deadlock time, Waiting transaction ID, Waiting lock mode, Waiting SQL text, Blocking transaction ID, Blocking lock mode, Blocking SQL text and Rollback transactionID. |