MySQL Table Lock Waits Test

A lock is a mechanism associated with a table used to restrict the unauthorized access of the data in a table. MySQL allows a client session to acquire a table lock explicitly to cooperate with other sessions to access the table's data. MySQL also allows table locking to prevent it from unauthorized modification into the same table during a specific period.

A session in MySQL can acquire or release locks on the table only for itself. Therefore, one session cannot acquire or release table locks for other sessions. It is to note that we must have a TABLE LOCK and SELECT privileges for table locking.

Table Locking in MySQL is mainly used to solve concurrency problems. It will be used while running a transaction, i.e., first read a value from a table (database) and then write it into the table (database).

MySQL provides two types of locks onto the table, which are:

• READ LOCK: This lock allows a user to only read the data from a table.

• WRITE LOCK: This lock allows a user to do both reading and writing into a table.

Table locking enables many sessions to read from a table at the same time, but if a session wants to write to a table, it must first get exclusive access, meaning it might have to wait for other sessions to finish with the table first. During the update, all other sessions that want to access this particular table must wait until the update is done. Table locking causes problems when a session is waiting because the disk is full and free space needs to become available before the session can proceed. In this case, all sessions that want to access the problem table are also put in a waiting state until more disk space is made available. if the number of lock waits grows over time, it will consequently increase the length of the pending requests queue; a long request queue may not only cause the unnecessary erosion of valuable server resources, it may also choke the database server, thereby significantly impacting the quality of the user experience with the server. It is therefore imperative that the lock wait events are monitored, and issues related to such events immediately brought to the attention of administrators.

This test monitors the table lock wait events, and promptly alerts administrators to a sudden/ steady increase in the number and duration of such events.

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 MySQL database server being monitored

Configurable parameters for the test

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 topic. For the MySQL Bin Log test to run, the user should additionally possess the following privileges. To configure the above-mentioned user with the specific privileges, issue the commands given below: GRANT REPLICATION CLIENT on *.* to '<username>'@'<IP_address_of_eG_agent>'; GRANT REPLICATION SLAVE on *.* to '<username>'@'<IP_address_of_eG_agent>'; GRANT EXECUTE on *.* to '<username>'@'<IP_address_of_eG_agent>';
Confirm Password	Confirm the password by retyping it here.
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.
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: The eG manager license should allow the detailed diagnosis capability Both the normal and abnormal frequencies configured for the detailed diagnosis measures should not be 0.

Measurements made by the test

Measurement	Description	Measurement Unit	Interpretation
Session waiting	Indicates the number of sessions waiting for the lock during the last measurement period.	Number
Maximum wait time for table lock	Indicates the maximum time spent by a query while waiting for a table lock.	Seconds	If the value of this measure is high, there may be an impact on the performance of the database server. To improve the performance, administrators need to optimize the queries, either split one / more tables or use replication. The detailed diagnosis of this measure lists Thread ID, Statement ID, Schema name, Query duration, Table lock wait time (Seconds), Temp disk tables created, Temp tables created, Rows sent, Rows examined, Select scan, Sort scan and SQL text.