It means MySQL servers. You may install as many instances of SQL DM for MySQL as you like as long as the total number of MySQL servers monitored does not exceed your license.
MySQL servers, SQL DM for MySQL server(s) and Clients (browser) can be installed independently everywhere where a TCP connection (like an Internet/Intranet connection) is available. Available TCP connections is all that is required. Regarding installing SQL DM for MySQL on the same host as MySQL then SQL DM for MySQL Connects to/Monitors MySQL running on any platform.
Currently we support Windows (do not support Windows 2003) and Linux operating systems. Those are the Operating Systems where SQL DM for MySQL itself needs to be installed in. The SQL DM for MySQL client functionalities only require an Internet browser and any platform (including platforms for handheld devices like mobile phone, PDA, tablet PC, etc.). There are also no restriction as regards the platforms the MySQL servers that SQL DM for MySQL connects to - it can be any. Additionally, SQL DM for MySQL is able to retrieve OS data from Linux Operation Systems.
This is actually a license-related question and a technical question as well.
Every new release adds features, fixes bugs, improves performance, stability, the GUI interface etc. Why should you NOT upgrade? Refer to Version History for details.
What you installed was the MONyog(SQL DM for MySQL) service. This service is basically a webserver program. You connect to the service with an Internet browser by specifying the host where it is installed and the port that was specified when installing.
SQL DM for MySQL queries the MySQL servers about almost anything the server 'knows' except for data stored on those servers. The MySQL servers themselves store and maintain records of server configuration, users, history and much more. SQL DM for MySQL retrieves this information, organizes it, calculates on it and reports.
This depends on the Operating system.
- Windows 2008:
MONyog.ini + MONyog.log + preferences.config are in:
- Windows Vista:
MONyog.ini + MONyog.log + preferences.config are in:>
- Linux RPM build:
Data folder: The connection configuration and collected data are kept here. You can find directories named like 0001, 0002, 0003, etc.
- Linux .gz archive:
If you have extracted SQL DM for MySQL package in a directory called MONyog the data stored is in:
Data folder: The connection configuration and collected data are kept here. You can find directories named like 0001, 0002, 0003, etc.
The data folder specified above is the default settings only. You can store in any position on any mapped/mounted drive that is writable.
Except for two plain text files: the MONyog.log file and a very small .ini file (that contains information about the port on which SQL DM for MySQL listens, The SQL DM for MySQL administrator password and the path to the data folder), everything is kept in high-performance database files (SQLite format).
Yes. Just install SQL DM for MySQL on the 2nd machine. After install, stop the running MONyog(SQL DM for MySQL) service and copy the ..\MONyog\Data folder from the old installation. You may also copy the MONyog.log if you want. All the connection configuration and the data is located in 'data' directory. The error log is MONyog.log and settings are stored in 'MONyog.ini' and 'preferences.config'. If you have made any changes to monitors they are stored in 'Counters.def' and for CSO's in 'udo.def'. Copy all of them from your old installation onto new PC. After that start the service again.
Yes, at least with Apache this is possible. In your Apache configuration file (httpd.conf) add something like this (where 'ip1.ip2.ip3.ip4' is the IP address you reserve for SQL DM for MySQL).
And run the following command on the machine running Apache server:
After changing the configuration, restart the Apache server.
We can also access SQL DM for MySQL using Apache proxy. You need to follow these simple steps to configure your Apache server to support proxy.
Here, we can setup Proxy in system A and we assume that SQL DM for MySQL is installed in system B, now you can access SQL DM for MySQL using, "http:///monyog/".
Configurations on system-A:
You need to load the following modules, so add the following entries in [/etc/httpd/conf/httpd.conf].
You can also access SQL DM for MySQL using nginx proxy. You need to follow these simple steps to configure your nginx server to support proxy. Here, we can setup Proxy in system A and we assume that SQL DM for MySQL is installed in system B, now you can access SQL DM for MySQL both over HTTP("http://") and HTTPS("https://").
Configuration of System A:
A sample nginx.conf would like the following:
4. Put your SSL certificates in /etc/nginx/conf/
5. Create a monyog.conf file inside /etc/nginx/conf.d/ and add the following:
Yes, you can access SQL DM for MySQL using "https", you may acquire a certificate from a certificate authority, such as Verisign or you may use the OpenSSL package to create your own certificate and configure your Apache webserver for "https".
Here are the steps you may follow to setup "https" in your Apache webserver.
Create a directory
Now protect the directory,
Create two sub-directories
Create a database to keep track of each certificate
Create a custom config file for OpenSSL to use similar to openssl.cnf in your /etc/pki/tls folder.
Create a root certificate. All other certificates you create will be based of this. Since this is not a commercial certificate software may complain when they use your certificates. You may give people the "public" certificate and your certificate works like the commercial ones when they import it. To create, while in the 'sslcert' directory type:
You will be prompted for information and a password. Do not lose this password, make sure it is a secure one and back-up the two files that are created.
The two files that are created are cacert.pem, which is the one you can give to others for import in their browsers, and cakey.pem, which will be in the private directory.
Create a key and signing request
You will be prompted for information. The critical part is the "Common Name". This must be the server's hostname, such as mail.your.domain or the IP address. If you want to cover all subdomains you can enter *.your.domain. Use the "Organizational Unit" to remind you what the certificate is for, such as "Web Server". This generates two files:
name-req.pem - the request
name-key.pem - the private key in the private directory
Sign the request. This generates the certificate:
You will be prompted for the password used when creating the root certificate. Two files are created:
Copy to the correct location For Apache 2.x on Red Hat using the default location, the directory is:
For the name-key.pem:
For the certificate:
Create a Virtual Host
Configure proxy in Apache described in FAQ 13 and restart Apache.
Edit the Hosts file [/etc/hosts]
They have similarities (in which they both differ from server-side scripts used for monitoring): they both make use of a HTTP service, a database and both use a web-browser for reporting. However, important differences are:
SQL DM for MySQL is developed by the Webyog Softworks that also created the most popular GUI for data management with the MySQL server - SQLyog Enterprise. We have more than 10 years of experience with designing MySQL related software. We have expanded our team with highly qualified developers ever since we started. We are devoted to constantly extending our knowledge and understanding of MySQL internals.
SQL DM for MySQL uses the most proved and most efficient way of connecting: the native MariaDB Connector/C that is compiled into SQL DM for MySQL. Nothing else required: no separate client instance, no database abstraction layer (like ODBC/JDBC/ADO/.NET) and no webserver extensions (like PHP). Additionally, the connection can be 'wrapped' in a SSH tunnel. Also, SQL DM for MySQL implementation for this does not involve any other program (like Putty) running.
This can happen on some versions of Windows (Vista and higher) if you install a recent version of SQL DM for MySQL on top of an older version. The reason for this is that recent versions of Windows include a software called "Program Compatibility Assistant" (PCA) which tries to detect if an installer is running. It warns the user that the software might not have been correctly installed if the installer does not register a new uninstaller. The PCA is unable to detect changes made to an existing, registered uninstaller, which is what the new SQL DM for MySQL installers do. And thus, the warning is displayed. You can safely ignore this warning, but if it bothers you, you may just uninstall SQL DM for MySQL before upgrading to 3.5+. All collected data in the SQL DM for MySQL's data folder is still available after reinstall. However, you should:
Yes, SSH support can be installed on Windows. You may install a complete Cygwin (Unix command line implementation for Windows). Alternatively, there are small packages available that support only a small subset of Cygwin (like SSH packages). Installation details depends on the exact Windows version.
Please go through Error when trying to connect to MySQL. The same applies to SQL DM for MySQL as the client code is exactly the same in both programs. Observe however that everything related to HTTP-tunneling with SQLyog is not relevant for SQL DM for MySQL.
Ensure that the host specified resolves to an IP-address. This error occurs with some Linux distributions (most important Debian) when specifying 'localhost'. The system maps this to a Unix SOCKET file. SQL DM for MySQL connects through TCP and not to SOCKET. Try the IP '127.0.0.1' instead.
You may have noticed that, while using the PROCESSLIST-based sniffer, SQL DM for MySQL increases the load on the CPU as well as the I/O subsystem of the system on which it is installed - even when the MySQL server is idle. Do not panic: it is normal. When using the PROCESSLIST-based sniffer, SQL DM for MySQL continually queries the MySQL server at the end of each time interval, which you can specify. It then retrieves the results and stores them in an internal sniffer database before displaying the results back to you. Now, if you set a short time interval, one that almost approaches 0, then SQL DM for MySQL can get stuck in an infinite loop! Consequently, the load on the CPU and I/O subsystem increases exponentially. We generally recommend an interval of not more than 0.1 seconds times the number of servers for which Processlist-based sniffers are enabled. However, if you are worried that you may miss out on some important queries running on the MySQL server, use the Performance Schem or MySQL Proxy mode. The LUA script supplied with SQL DM for MySQL should handle the task for MySQL proxy. For more information review MySQL Proxy.
When using Query Analyzer feature, you may notice that sometimes queries displayed in output are incomplete. This may be due to one of the two known causes:
Check if the server is filtered based on a particular state, change your server filter to All Servers and now you can see your server between the servers if you had successfully registered it. You can also use the search bar next to the server filter to search for your server name or tag name to get to your server.
No, the SQL DM for MySQL authentication system will ensure that only those people that should have access have.
For every registered server SQL DM for MySQL collects data independently. That is also the case when a server has been registered twice. Even if they were registered at the same time and even if the chosen sample interval is the same too, the connection and the server have some latency and data is not retrieved simultaneously. For that reason SQL DM for MySQL may retrieve and store slightly different values for each connection. This is most visible in the 'Delta' timeframe and least visible in the 'Current/all' timeframe. For GROUPING with 'History/Trends' the difference for each GROUP depends on the selected grouping interval. Due to laws of statistics the difference is less the longer the time interval (theoretically/statistically they converge more and more the closer time interval and/or the number of samples comes to infinity). Practically, you rarely need more than 20 samples in a GROUP for the difference to be negligible.
It does not affect on real 'live' servers. The queries sent by SQL DM for MySQL use almost no resources. We do not query data stored on disk and what we do query is stored in memory on the server. However if you are testing SQL DM for MySQL using a server instance that does almost nothing else and if you retrieve data at very short intervals the impact of SQL DM for MySQL may be slightly observable. The special Processlist feature (unique) may take a little more resources if there are lots of processes/client threads running. But SQL DM for MySQL only sends queries related to this when the corresponding SQL DM for MySQL client interface (the SQL DM for MySQL 'processlist' page) is open. Switching to another page or closing the browser stops sending the queries populating the SQL DM for MySQL processlist.
SQL DM for MySQL is a client. When it connects, the MySQL server starts a connection thread. And that connection is reported by SQL DM for MySQL. That cannot be avoided. The processlist feature has an option to 'filter out' SQL DM for MySQL connection - as well as other connections from other clients if you want - using a simple SELECT statement.
Yes, you can choose to get notifications (Email, SNMP traps, Slack, Pagerduty and Syslog) independently for every server and you can define your own warning levels and select what counters should raise an alert.
By default MONyog(SQL DM for MySQL) service runs under Local System Account. If you are having Slow query or General query log in a Mapped Network Drive, SQL DM for MySQL is not be able to reach it. If SQL DM for MySQL has to access the file present in a Mapped Network Drive, you have to convert the path into shared path (accessed with UNC notation: \system\share) and then follow these steps:
Click the Start menu, then click Run and then type,
After the Services window pops up with a list of all the services running in your system.
The shared path should be accessed with UNC notation (\system\share). SQL DM for MySQL cannot identify if destination of the log file is on a Mapped Network Drive (this is a restriction with services on Windows and not with SQL DM for MySQL).
You get this error if SQL DM for MySQL cannot resolve the hostname of a MySQL server. Ensure that other programs like ping, telnet, MySQL shell client are able to resolve the hostname to an IP-address. If yes, check "/etc/nsswitch.conf" of SQL DM for MySQL host. If the hosts section reads "files mdns4_minimal [NOTFOUND=return] dns mdns4", please change it to "files mdns4_minimal dns mdns4" or "files dns". This is introduced in some current Linux distribution. If other programs are not able to resolve the hostname, please check if host to IP resolution is properly defined inside "/etc/host" or in DNS server.
SQL DM for MySQL can fetch the queries from the Slow Query log and General query log on Amazon RDS instance using the RDS REST APIs. SQL DM for MySQL requires the AWS access keys to fetch the file-based logs. Go to the Edit Server->Advanced->MySQL Query log and enable the option of "Monitor MySQL Query Log". Click the Fetch logs(down arrow) button and provide the AWS access key and secret access key to enable SQL DM for MySQL to monitor the log files.
SQL DM for MySQL is an important product for us. We plan to add new features as well as to 'refine' existing features. With the latest release we have completed what we originally planned for SQL DM for MySQL.
These features have all been requested by users. SQL DM for MySQL development has always been and continues to be very attentive to user requests. We update information here when plans for future developments have been decided.
SQL DM for MySQL does not support the key generated from PuTTY for SSH connection. However, you can convert the private key generated from "PuTTY key generator" into an open SSH key, and then use this key in SQL DM for MySQL to connect to the server. Here are the steps to follow:
Users can make use of the "MONyog" script shipped with the Monyog(SQL DM for MySQL) package to auto-start MONyog(SQL DM for MySQL) service with OS reboot. The SQL DM for MySQL script is located at " /MONyog/bin/". Please follow the steps below:
The SQL DM for MySQL binaries are shipped in 3 packages: .tar, .rpm and .exe. The upgrade process is simple and depends on your package. Follow the steps below to upgrade to the latest version of SQL DM for MySQL:
For .rpm package :
This command installs the latest build on top of your current installation.
For .tar package:
Please untar the package in the directory where the ‘MONyog(SQL DM for MySQL)’ package was untarred for the previous version to make sure that all your data and settings are intact.
For Windows (.exe) package:
Executing the file installs SQL DM for MySQL on top of the current installation.
All SQL DM for MySQL data and the configuration files are stored in a SQLite repository. In some of the SQL DM for MySQL GA releases, we modify/change the monitor definition in the SQLite files due to some bug or enhancements. In such cases, on upgrading, all the local changes made by the user in the previous version get replaced with the default shipped value and these local changes are shown as a conflict. You can see the conflicts as a notification on the top right-hand corner.
To resolve conflict
You can resolve these conflicts from the “Settings -> Manage changes” page, herein you get 2 options for all the listed conflicts: Use your changes/Discard your changes. 1- Use your changes, restores the local modifications which you had made in the previous version. 2- Discard your changes, replaces your changes with the default values.
Monit tool monitors the server process and can be used to maintain HA for SQL DM for MySQL.
Use the below commands to install monit:
Once monit is installed, you can add programs and processes to the configuration file:
Uncomment the below lines in the file to enable web interface. You can login to the web interface using the username ‘admin’ and password ‘monit’.
Also add the below lines in the configuration file to enable the monitoring of MONyog(SQL DM for MySQL) service:
Once the above configuration changes are made, please use the below command to reload monit: