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

Configurable parameters for the test

Parameter

Description

Test Period

How often should the test be executed

Host

Specify Host name of the server for which the test is to be configured in this text box.

Port

Specify the port to which the specified host listens in this text box.

Database(DB)

Specify the name of a database on the target MySQL database server being monitored in the Database text box.

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 topic.

Confirm Password

Confirm the Password by retyping it in the Confirm Password text box.

Allow Public Key

By default, the Allow Public Key flag is set to No. But, if the specified USER is created with caching_sha2_password as the authentication plugin, then the eG agent can connect to the target database cluster using RSA public key. To this effect, you have to set Allow Public Key flag to Yes.

SSL

By default, the SSL flag is set to No, indicating that the target MySQL database server is not SSL-enabled by default. To enable the test to connect to an SSL-enabled MySQL database server , set the SSL flag to Yes.

Verify CA

If the eG agent is required to establish an encrypted connection with the target MySQL database server by authenticating the server's identity through verifying the server CA certificate, set Verify CA flag to Yes. By default, this flag is set to No.

Truststore Password

This parameter is applicable only if the Verify CA parameter is set to Yes. To verify the target server certificate, provide the password of the truststore file which contains the server CA certificate in the Truststore Password text box. By default, this parameter is set to none.

Confirm Password

Confirm the Password by retyping it in the Confirm Password text box.

Keystore Password

This parameter is applicable only if the Verify CA parameter is set to Yes. To establish a connection with the target MySQL database server , the eG agent needs to have access to the client certificate. For this provide the password of the keystore file which contains the client certificate in the Keystore Password text box. By default, this parameter is set to none.

Confirm Password

Confirm the Password by retyping it in the Confirm Password text box.
Measurements made by the test

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:

Measure Value Numeric Value
Yes 1
No 0

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.