- Discover with BMC Discovery
- What is this?
- This is a product information page, containing details of the information that BMC Discovery gathers about a product and how it is obtained.
- Product Name
- Publisher Page
- Relational Database Management Systems
- TKU 2017-Jun-1
- Change History
- Oracle MySQL Server - Change History
- Reports & Attributes
- Oracle MySQL Server - Reports & Attributes
- Publisher Link
Extended Discovery pattern which allows to model Database Detail Nodes being managed by the MySQL Server is available for this product.
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 Component||OS Type||Versioning||Pattern Depth|
|DatabaseServer||Unix||Command (Active), Package, Path||Instance-based|
|Windows||Command (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 Type||Trigger Node||Attribute||Condition||Argument|
Simple Identification Mappings
The following components/processes are identified using simple identity mappings.
|MySQL Database Server||regex'\bmysqld$'|
|MySQL Database Server Startup script||regex'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:
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 privileged execution
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
Atrium Dsicovery executes a search for the installed packages and tries to match them against the following regular expressions in the order in which they are presented below:
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.
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:
Application Model Produced by Software Pattern
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.
Additional Attributes of the Software Instance created
On all platforms the pattern initially attempts to discover the database listening port information from the trigger process command line arguments by parsing against the following regular expressions in turn:
On all platforms the pattern then attempts to discover the database listening port information from the configuration (my.cnf or my.ini) file.
The process command's arguments are parsed using one of the following regular expressions to obtain the full path to this file:
--defaults-file=(\[Oracle MySQL Server^"s\]+)
--defaults-file="(\[Oracle MySQL Server^"\]+)"
On WIndows, if the argument, --defaults-file, is not present in the command line's arguments, the process command is parsed using the following regular expression to obtain the directory of my.ini: * (?i)(\w:.+)\\binOnce located and downloaded, the configuration file is parsed using one of the following regular expressions (dependant on whether instance is known or not) to obtain the port information:
On UNIX platforms, a secondary method to obtain the listening port information may be used if the pattern determines that the Atrium Discovery user is not root (having executed the 'whoami' command to confirm this).
The pattern executes the following command:
Version 4.1.1 or greater
<abs. path to the trigger process binary>/mysqld --verbose --help | grep port
Versions older than 4.1.1
<abs. path to the trigger process binary>/mysqld --help | grep port
(for details of how we obtain the absolute path to the trigger process please see the documentation on active versioning)
The output is parsed using the following regular expression: \nport\W*(\d+)
On all platforms the pattern attempts to obtain the bind address from the configuration (my.cnf or my.ini) file.
Once the file is obtained (as described above in the port information section), it is parsed using the following regular expression:
On UNIX platforms, a secondary method to obtain the bind address information may be used if the pattern determines that the Atrium Discovery user is not root (having executed the 'whoami' command to confirm this).
The pattern executes the following command:
<abs. path to the trigger process binary>/mysqld --verbose --help | grep bind-address
The output is parsed using the following regular expression:
bind address is given for information only. The pattern is only able to directly query a database if it has the same IP address as the host
The pattern tries to establish what socket the application is connected to by applying the command line arguments against one of the following regular expressions (the first for Unix and the second for Windows): * socket=(\S+) * socket=(.+)\s
The pattern tries to establish the data directory by applying the following regular expression(s) against the command line arguments:
UNIX * datadir=(\S+)If datadir cannot be established by the above methods on the UNIX platform, and the pattern was able to access the configuration file (when obtaining port / bind_address information), the configuration file is parsed using the following regular expression: * ^datadir=(\S+)Windows
If datadir cannot be established by the above methods on the Windows platform, and the pattern was able to access the configuration file (when obtaining port / bind_address information), the configuration file is parsed using the following regular expression: * (?i)^datadir="?(.+?)["\r]The information obtained is assigned to the db_path attribute on the SI created
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.
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:
The instance name is extracted from the very end of the trigger process command line arguments using the following regular expressions:
followed by a third:
An attempt is made to extract an ipv4 or ipv6 bind address from the trigger process command line argument by parsing against the following regular expression:
or from the config file using one of the following regular expressions dependant upon whether instance is known or not:
The edition of the product is derived from either an active command or from its package name.
The output from executing the "<trigger_process_cmd> -V" command is parsed against the following regular expression:
or failing this, from the name of the package by parsing it against the following regular expression:
A mapping table is then utilised to change them into a consistent format.
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, please refer to the 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