MySQL Cluster Locks Test

The locking activity of a database server must be monitored carefully because an application holding a specific lock for a long time could cause a number of other transactions relying on the same lock to fail. This test monitors the locking activity of various transactions supported by each node on the target MySQL Cluster database server.

Target of the test : A MySQL Cluster

Agent deploying the test : A remote agent

Outputs of the test : One set of results for each node in the target cluster being monitored

Configurable parameters for the test
Parameter Description

Test Period

How often should the test be executed.

Host

The host for which the test is to be configured.

Port

The port at which the specified host listens.

Database

Specify the name of a database on the target MySQL Cluster 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 Cluster database server. To know how to create such a user, refer to Pre-requisites for Monitoring the MySQL Cluster Database Server topic.

Confirm Password

Confirm the password by retyping it here.

Measurements made by the test
Measurement Description Measurement Unit Interpretation

Lock waits

Indicates the percentage of lock requests that could not be satisfied immediately and hence, required the caller to wait before being granted the lock.

Percent

A value close to 100 for this measure can have an adverse impact on application performance. Possible reasons for this behavior could be:

  • inadequate number of locks available in the database,

  • unusually high locking behavior of applications accessing the database,

  • improper database application design, etc.

Table lock waits

Indicates the number of times in the last measurement period a table lock could not be acquired immediately and a wait was needed.

Number

If the number of waits is high, application performance could suffer. You should first optimize your queries, and then either split your table(s) or use replication.