Page tree

Skip to end of metadata
Go to start of metadata
Product Name
MySQL Server
Publisher Page
Relational Database Management Systems
TKU 2020-Jul-1
More Information
Publisher Link

 Product Description

For TKU September 2020 Extended Discovery pattern was updated (DRDC1-14748). Database Detail node was updated to contain DB Server type (DRDC1-14748). Please be aware that this update may impact CMDB syncing.

Extended Discovery pattern which allows to model Database Detail Nodes managed by the MySQL Server is available for this product.


From TKU November 2017 onwards pattern will also discover Infobright Community Edition and Infobright Enterprise Edition For more information, see Infobright Product Page.


Oracle MySQL Server software is one of the most widely used relational database management systems that runs as a server providing multi-user access to a number of databases. It is available both in open source form as well as for commercial use, where several paid editions are available, and offer additional functionality.

Software Pattern Summary

Product ComponentOS TypeVersioningPattern Depth
DatabaseServerUnixCommand (Active), Package, PathInstance-based
WindowsCommand (Active), Registry, Package, Path

Platforms Supported by the Pattern

The patterns have been created in a manner that allows each of them to support Windows, Linux and Unix platforms from the same module.


Software Instance Triggers

OS TypeTrigger NodeAttributeConditionArgument


Simple Identification Mappings

The following components/processes are identified using simple identity mappings.

MySQL Database Serverregex'\bmysqld$'


MySQL Database Server Startup scriptregex'safe_mysqld\b'


Version information for the product is currently collected using one of four possible methods.

The methods are tried in an order of precedence based on likely success and/or accuracy of the information that can be gathered. Once a result is obtained, the methods lower in precedence are not attempted. In order of precedence the methods are:

  • Active Versioning

If the path to the trigger process is fully qualified, the pattern runs <trigger process> -V (e.g. /usr/sbin/mysqld -V).

If the path to the trigger process is not fully qualified the pattern gets the install root from the --basedir attribute in the trigger process arguments, then runs <install_root>/bin/<trigger process> -V

If the command fails, the pattern tries it with the privileged execution.

  • Registry Versioning

Windows only

The Registry Query functionality allows for a value to be pulled from the registry, given a valid registry path. This value will then be used as the version number for the product.

The pattern queries the Windows Registry to obtain the registry listing (giving version(s) installed) from the following registry path:


If the registry listing returns a single entry, then the pattern will perform a further Windows registry query to obtain the version information. The query performed is:



If more than one entry is returned, registry versioning will not be performed as Atrium Discovery cannot be certain to correctly assigned the version obtained from registry to the actual instance that has been discovered.

  • Package Versioning

Atrium Discovery executes a search for the installed packages and tries to match them against the following regular expressions in the following order:

  • ^(?i)MySQL$

  • ^MySQL[\-\s]Server
  • ^rh\-mysql\d+-mysql\-server

When it finds a match, it extracts the version for MySQL RDBMS from the package information. If more than one package matches, only the version information from the first is extracted.

  • Path Versioning

The Path Regex functionality allows a regular expression to be applied against the MySQL Database Server (mysqld) process command line to derive a version number from the command path or arguments.

The regular expression used is as follows: mysql-(?:max-|standard-|)(\d\.[\.d+\]*)

Additional Attributes

We can get additional attributes by parsing the trigger process arguments, the configuration file or the system variables.  The pattern tries them in that order

We obtain the configuration file from the –default-file option of the trigger process arguments.  If that doesn’t exist look in <install root>\\my.ini (on Windows) or /etc/my.cnf (on UNIX).  Install root is obtained from the path to the trigger process. Port, bind_address and datadir are all reported in this configuration file.

We can get a list of system variables from the command <install root>/mysqladmin variables or the command <install root>/mysqld –verbose --help.


How to obtain from trigger process arguments

How to obtain from configuration file

How to obtain from system variables


Generally it is the last argument in the trigger process arguments.  In certain cases check the –defaults-group-suffix argument instead




Yes – port argument or P argument

Yes – search for “port”

Yes – port variable


Yes – bind_address argument

Yes – search for “bind-address”

Yes – bind-address variable


Yes – datadir argument

Yes – search for “datadir”



Yes – socket argumemt






Yes – Check version-comment variable.  If the comment is “MySQL <edition value> Edition” then the edition is <edition value>

The pattern has the MySQL Database Server (mysqld, mysqld-max or mysqld\S*\.exe) as its trigger process.

If the trigger process is a child process with the same cmd as its parent, the pattern is immediately stopped; its body will be executed later when the parent trigger process is encountered.

Application Model Produced by Software

SI Depth

The pattern normally generates an instance-based Software Instance. If the data directory path is known, then the SI key is generated based on the hashed value of this path, combined with the SI type and the host key. If the data directory is not known but the port is known, then the key for the generated Software Instance is based on the port, the SI type and host key. If instance is known but not port and data directory, then the key for the generated Software Instance is based on instance, the SI type and host key. If none of these values have been discovered, then a grouped SI is created with the key_group being based on process cmd and full version.

The key is always constant but note that the name of the SI varies depending on how much information is necessary to uniquely identify the instance.

  • It always contains software instance type and host name
  • It always contains product version if it can be found
  • It contains instance only if it exists and is necessary to uniquely identical the MySQL instance on the host (i.e. there are several instances installed on the same host)
  • It contains a part of datadir only if there are several instances installed on the same host and datadir is the only way to distinguish between them.

Relationship Creation

If an instance based SI is created, then a number of relationships are also created on the UNIX/Linux platforms.

The pattern performs a search for all the trigger process' child processes running on the host, and then associates them, as child processes, with the Software Instance.

The pattern also performs a search for all the trigger process' parent processes running on the host. The arguments of any parent process matching the following regular expression are then associated, as parent processes, with the Software Instance:

  • (mysqld_safe|safe_mysqld)

Obtaining detailed MySQL Database and table information - Extended database discovery

A separate pattern has been created to query the MySQL Database Server in order to obtain database list and (optionally) database table details. For more information about this pattern, see the related relevant page

Subject Matter Expertise

We welcome any subject matter expert information which will help us improve our discovery of MySQL Server.


Testing has been performed against both a live installation on Linux and Windows and customer record data.

Information Sources

Open Issues