MySQL is an open source, object-relational database built with speed and reliability in mind. Its large and active developer community has created many third-party applications, tools, and libraries that expand MySQL’s functionality.
DigitalOcean Managed Databases include metrics visualizations so you can monitor performance and health of your database cluster. There are two kinds of metrics:
Cluster metrics monitor the performance of the nodes in a database cluster. Cluster metrics cover primary and standby nodes; metrics for each read-only node are displayed independently. This data can help guide capacity planning and optimization. You can also set up alerting on cluster metrics.
Database metrics monitor the performance of the database itself. This data can help assess the health of the database, pinpoint performance bottlenecks, and identify unusual use patterns that may indicate an application bug or security breach.
There are two groups of MySQL metrics: master server metrics, which are metrics on all databases in the cluster, and database metrics, which are metrics on individual database performance.
To view performance metrics for a MySQL database cluster, click the name of the database to go to its Overview page, then click the Insights tab.
The Select object drop-down menu lists the cluster itself and all of the databases in the cluster. Choose the database to view its metrics.
In the Select Period drop-down menu, you can choose a time frame for the x-axis of the graphs, ranging from 1 hour to 30 days. Each line in the graphs will display about 300 data points.
By default, the summary to the right shows the most recent metrics values. If you hover over a different time in a graph, the summary will display the values from that time instead.
If you recently provisioned the cluster or changed its configuration, it may take a few minutes for the metrics data to finish processing before you see it on the Insights page.
MySQL-specific master server metrics include:
Connection status: the number of threads created, connected, and running in relation to the connection limit.
Index vs. sequential reads: The reads using an index as a proportion of the total reads across all databases on the server.
Operations throughput: Throughput of fetch, insert, update and delete operations across all databases on the server.
Master server metrics are displayed in the same view as cluster performance metrics.
The connection status plot displays:
This plot also displays the database’s connection limit as a dashed line.
If the number of connected threads regularly approaches or exceeds the connection limit, consider implementing client-side connection pooling or upgrading your database plan to increase your connection limit.
The index vs. sequential reads plot presents the proportion of reads that use an index over the total number of reads across all databases (schemas) on the master server.
In general, queries across large tables can be optimized through the use of an index. Use the MySQL query statistics on the Logs & Queries tab and the EXPLAIN statement to identify slow queries that may benefit from the addition of an index.
The operations throughput plot displays the rate of fetch, insert, update and delete operations per second across all databases (schemas) on the master server.
You can compare this plot with node performance metrics to identify potential resource constraints. For more insights, look at the individual database-level metrics and the query statistics on the Logs & Queries page.
MySQL databases have the following metrics:
The throughput plot shows the rate of fetches, inserts, updates, and deletes in rows per second.
If you observe bottlenecks, look for slow queries in the query statistics on the Logs & Queries page, then use the EXPLAIN statement to explore opportunities for query optimization.
The latency plot shows the average time, in seconds, of fetches, inserts, updates, and deletes.
If you observe bottlenecks, use the EXPLAIN statement for optimization recommendations.