MySQL Enterprise Monitor is available as part of the MySQL Enterprise subscription, learn more at https://www.mysql.com/products/.
C.1: If I upgrade to 3.1, what happens to the users defined in earlier versions?
Questions and Answers
All users defined in earlier versions are mapped to the default roles introduced in Access Control Lists in MySQL Enterprise Monitor 3.1. The user names are retained but their permissions are defined separately in default roles. All pre-existing users are automatically mapped to the default roles.
For example, if User1 is defined as a dba in MySQL Enterprise Monitor 3.0.x,
User1 is created in MySQL Enterprise Monitor 3.1, but assigned to the
dba Role. If User1 is defined as a dba, and
granted both Query Analyzer permissions in 3.0.x, it is assigned
to the default dba Role, and both Query Analyzer roles in 3.1.
C.1: How do I find
IgnoredMySQL Instances? And how to I show them again?
C.2: Using MySQL Enterprise Service Manager 3.2 with older agents, why am I seeing warning messages like the following in the agent logs?
WARN [HttpPollingJobFetcher-thread-0:com.mysql.etools.agent.ManagedOrder] bean order property CoalescedCollectionRunner.collections is a collection and contains a class not available on the agent. This element of the collection will be ignored. Upgrading the agent to a version at least the same as the service manager may solve this problem. java.lang.RuntimeException: java.lang.ClassNotFoundException: com.mysql.etools.inventory.model.mysql.XXXXXXX
C.3: In 2.3, the
agent-mgmt-hostnamecontained the string "heartbeat" as the URLs path. Did this change?
C.4: How do I change the name of a server?
C.5: Does Query Analyzer work with all versions of MySQL and the MySQL Client Libraries?
C.6: Why does the file
apache-tomcat/logs/tomcat.logshow error messages saying
This is very likely to create a memory leak.? Is that anything to be concerned about?
C.7: Why does monitoring a MySQL instance with FEDERATED tables cause extra connections, and decreased performance?
Questions and Answers
From the MySQL Instances page, open the Unmonitored Instances panel and enable the Ignored Instance filter parameter and execute the search. This lists the ignored MySQL Instances.
To change the status of an ignored MySQL Instance, choose Show Instance from the context-menu for a specific MySQL Instance, or check the ignored MySQL Instance(s) and click the button.
bean order property CoalescedCollectionRunner.collections is a collection
and contains a class not available on the agent. This element of the collection
will be ignored. Upgrading the agent to a version at least the same as the service
manager may solve this problem.
MySQL Enterprise Monitor 3.2 introduced support for multi-source replication.
Some of the functionality introduced in the 3.2 agents is not
available in the earlier agents.
represents one of the classes unavailable in the earlier agent.
These warnings do not imply anything is wrong with your installation or any data is missing from the collections. However, it is strongly recommended that you upgrade your agents to the same version as your MySQL Enterprise Service Manager.
Yes, this is no longer required and is ignored as of MySQL Enterprise Monitor 3.0.0.
Open the MySQL Instances dashboard, and choose from the instance menu. Alternatively, toggle the checkbox for one instance and click .
Renaming the server in this way will override all other server naming, including changes to the agent configuration.
MySQL 5.1 or later is supported.
Analyzing Performance Schema results requires MySQL Server 5.6.14 and above.
This message is sometimes produced by underlying components of the web stack on web application reload or shutdown, and is not a cause for concern. It is not practical to shut off these spurious messages within Tomcat.
When the agent starts, it executes a discovery process that performs a number of INFORMATION_SCHEMA queries that gather table information for rules. These INFORMATION_SCHEMA queries can be costly on instances with many tables, particularly with large numbers of FEDERATED tables to another instance, as each table has a new session opened for it on the target machine.
C.1: What are the features and related benefits of the MySQL Enterprise Monitor?
C.2: What are the immediate benefits of implementing the MySQL Enterprise Monitor?
C.3: What are the long-term benefits of the MySQL Enterprise Monitor?
C.4: How is the MySQL Enterprise Monitor installed and deployed?
C.5: How is the Enterprise Monitor web application architected?
C.6: What makes MySQL Enterprise unique?
C.7: What versions of MySQL are supported by the MySQL Enterprise Monitor?
C.8: What operating system platforms are supported by the MySQL Enterprise Monitor?
C.9: How are subscribers notified about the availability of new or updated MySQL Enterprise Monitor, MySQL Enterprise Advisors and Advisor Rules?
Questions and Answers
The MySQL Enterprise Monitor is like having a "Virtual DBA Assistant" at your side to recommend best practices to eliminate security vulnerabilities, improve replication, and optimize performance. For the complete features and benefits, visit the http://www.mysql.com/products/enterprise/monitor-features.html.
Often MySQL installations are implemented with default settings that may not be best suited for specific applications or usage patterns. The MySQL Advisors go to work immediately in these environments to identify potential problems and proactively notify and advise DBAs on key MySQL settings that can be tuned to improve availability, tighten security, and increase the throughput of their existing MySQL servers
Over time, the task of managing even medium-scale MySQL server farms becomes exponentially more complicated, especially as the load of users, connections, application queries, and objects on each MySQL server increases. The Enterprise Monitor continually monitors the dynamic security, performance, replication and schema relevant metrics of all MySQL servers, so as the number of MySQL continues to grow, DBAs are kept up to date on potential problems and proactive measures that can be implemented to ensure each server continues to operate at the highest levels of security, performance and reliability.
The Enterprise Monitor is powered by a distributed web application that is installed and deployed within the confines of the corporate firewall.
The Enterprise Monitor web application comprises three components:
Monitor Agent: A lightweight Java program that is installed on each of the monitored hosts. Its purpose is to collect MySQL SQL and operating system metrics that allow the DBA to monitor the overall health, availability and performance of the MySQL server and host. The Monitor Agent is the only component within the application that touches or connects to the MySQL Server. It reports the data it collects via XML over HTTP to the centralized Service Manager.
Service Manager: The main server of the application. The Service Manager manages and stores the data collections that come in from each monitor agent. It analyzes these collections using MySQL provided best practice Advisor rules to determine the health, security, availability and performance of each of the monitored MySQL Servers. The Service Manager also provides the content for the Enterprise User Interface which serves as the client user interface for the distributed web application.
Repository: A MySQL database that is used to stored data collections and application-level configuration data.
Of the products on the market that monitor MySQL, SQL code and OS specific metrics, the MySQL Enterprise Monitor is the only solution that is built and supported by the engineers at MySQL. Unlike other solutions that report on raw MySQL and OS level metrics, the MySQL Enterprise Monitor is designed to optimize the use of MySQL by proactively monitoring MySQL instances and providing notifications and 'MySQL DBA expertise in a box' advice on corrective measures DBAs can take before problems occur.
The MySQL Enterprise Monitor supports MySQL versions 5.1 and above.
The Enterprise Monitor Service Manager is fully supported on
most current versions of Linux, Windows, and Windows Server
Editions. The Monitor Agent supports any platform supported by
the MySQL Enterprise server. For the complete list of MySQL
Enterprise supported operating systems and CPUs, visit
Supported Platforms and select
Customers receive email notifications of new and updated MySQL Enterprise Monitor versions.
C.1: What is the MySQL Query Analyzer?
C.2: How is the MySQL Query Analyzer installed and enabled?
C.3: What overhead can I expect if the MySQL Query Analyzer is enabled?
C.4: What are the main features and benefits of the MySQL Query Analyzer?
C.5: What are the typical use cases of the MySQL Query Analyzer?
C.6: What makes the MySQL Query Analyzer unique?
C.7: How can I get the MySQL Query Analyzer?
C.8: Does Query Analyzer work with MySQL Cluster?
C.9: Does Query Analyzer enable me to monitor the disk reads and writes during a query?
C.10: Does Query Analyzer handler prepared statements?
C.11: Will the Query Analyzer work without any special setup?
Questions and Answers
The MySQL Query Analyzer allows DBAs, developers and system administrators to improve application performance by collecting, monitoring, and analyzing queries as they run on their MySQL servers. http://www.mysql.com/products/enterprise/query.html
Using MySQL 5.6, or higher, with Performance Schema enabled, there is no appreciable overhead.
For the complete features and benefits, see MySQL Enterprise Monitor Features and Benefits.
The typical use cases for developers, DBAs and system administrators are:
Developers – Monitor and tune application queries during development before they are promoted to production.
DBAs and System Administrators – Identify problem SQL code as it runs in production and advise development teams on how to tune. This use case benefits the most from regular sampling of queries as they are running, most often during non-peak hours.
Other products (free, open source and commercial) that provide MySQL query monitoring are dependent on the MySQL Slow Query Log being enabled and available for sampling. While this provides some time savings over the DBA collecting and parsing the Log, the Slow Query Log comes with overhead and does not capture sub millisecond executions. The log data also grows very large very quickly.
The MySQL Query Analyzer collects queries and execution statistics with no dependence on the SQL Query Log, it captures all SQL statements sent to the MySQL server and provides an aggregated view into the most expensive queries in number of executions and total execution time. It is also fully supported as part of the MySQL Enterprise subscription.
The MySQL Query Analyzer is built into the MySQL Enterprise Monitor.
To experience the MySQL Enterprise Monitor for 30 days, visit the http://www.mysql.com/trials/
Yes, providing that exact node is monitored with an agent and query analyzer has been enabled for that node. Note that you must be accessing your cluster data through a standard MySQL node for this to work.
No, that information is not available to the query analyzer, but many Advisors and graphs do handle this information. An Agent monitors the host, which includes monitoring of the CPU, Disk, and Memory.
At this time, the query analyzer does not track server-side prepared statements. However the default configurations for most client-side libraries for MySQL don't use them, they emulate them client-side, and those will be tracked by the query analyzer.
With MySQL Server 5.6.14 and greater, Query Analyzer data is automatically (by default) collected and displayed using the Performance Schema Statement Digests MySQL Server feature. If you are monitoring an earlier MySQL Server version, then you can continue to use alternative methods of providing query data to the Query Analyzer.
For information about the different methods of retrieving query data, see Section 31.1, “Providing Query Analyzer Data”.