Database Performance

DB Growth

Provides a summary of your database and table growth on daily basis for the last 30 days. On the first line of the Top 25 Largest Databases grid, you should notice the actual size of the MySQL data directory (with a folder icon). This is useful to determine whether any other files that exist in the data directory may consume huge spaces e.g binary log, error log or MySQL general log.

Field	Description
DB growth	A summary of your database and table growth daily.
Top largest tables	A summary of the largest tables per database daily.
Update data in controller	Triggers a job to re-calculate the database size.
Actions → View	Shows the details per database on table count, row count,
	data size, index size, and database size.

Click on a database listed for further details on growth summary per table.

DB Status

Provides a comprehensive overview of your database’s current state. It offers insights into various aspects of the database, such as connection status, data usage, and server performance. This feature is particularly useful for database administrators and developers as it allows them to monitor the health and performance of the database, identify potential issues, and make informed decisions to ensure optimal database operation.

By default, ClusterControl performs status collection every 30 seconds. This is configurable using the db_stats_collection_interval parameter inside the controller’s configuration file.

Field	Description
Show differences	Shows a list of status and values that are not identical among each node (highlighted in red).
Filter Server	Specify the database server you want to view. Multiple values accepted.
Search	Filter the results.

DB Variables

Provides detailed information about the configuration of your database. It allows you to view and manage various parameters that control the behavior of your database system. These variables can include settings related to memory allocation, data storage, query optimization, and more. This feature is particularly beneficial for database administrators and developers, enabling them to customize the database environment to best suit their specific needs and application requirements.

By default, ClusterControl performs variable collection every 30 seconds. This is configurable using the db_stats_collection_interval parameter inside the controller’s configuration file.

Field	Description
Show differences	Shows a list of variables and values that are not identical among each node (highlighted in red).
Filter Server	Specify the database server you want to view. Multiple values accepted.
Search	Filter the results.

Advisors

Lists of scheduled advisors’ results created in Manage → Advisors and Manage → Scripts using ClusterControl DSL. You can think of it as a ‘scheduled mini-program’ that executes a script created inside ClusterControl and produces a result containing status, advice, and justification. You can get detailed schedules by rolling over to the Advisor’s name.

Field	Description
Manage advisors	Opens the Manage → Advisors for advisor’s management.

Schema Analyzer

Analyze your database schemas for missing primary keys, redundant indexes, and tables using the MyISAM storage engine. Galera Cluster needs an explicitly defined primary key on each table (unique key does not count). MyISAM tables are not recommended in Galera. ClusterControl will periodically check the schemas for these (default every 8 hours or every CMON restart), and raise an alert if necessary.

Field	Description
Tables without Primary Keys	List of tables without primary keys. A primary key is important in Galera. The DELETE operations are unsupported on tables without a primary key. Also, rows in tables without a primary key may appear in a different order on different nodes.
My ISAM Tables	MyISAM does not support transactions. However, the DMLs for MyISAM should also work but it’s still experimental in Galera.
Redundant Indexes	Having duplicate keys in schemas can hurt the performance of the database:
	* They make the optimizer phase slower because MySQL needs to examine more query plans.
	* The storage engine needs to maintain, calculate and update more index statistics.
	* DML and even read queries can be slower because MySQL needs to update and fetch more data to Buffer Pool for the same load.
	* Data needs more disk space so the backups will be bigger and slower.

Transaction Deadlocks

Available for: MySQL-based clusters and MariaDB-based clusters

Lists out long-running transactions and deadlocks across database clusters where you can easily view what transactions are causing the deadlocks. The default query time threshold is 30 seconds. This is configurable in the CMON configuration file under db_long_query_time_alarm configuration option.

Click on the listed query to see the output of InnoDB status for detailed debugging.

Field	Description
Deadlock check interval	How often to check for deadlocks in seconds.
	0 means disabled (default).
	Deadlock detection will affect CPU usage on database nodes.

Running Operations

Available for: MongoDB-based clusters

Provides a view of current running operations similar to db.currentOp() command.