This is the current (and supposed to be the last) MONyog release in the 5.5x series. Refer online documentation for details of changes in this and previous releases. The major scope of all releases in 5.5x series has been improving stability, performance and responsiveness under heavy load – such as large number of servers both registered and displayed at the same time, user activity by multiple users at the same time, ‘query sniffer’ running in the background etc. We have worked with a number of customers using MONyog in such demanding environments during the 5.5x development phase.
Changes in this 5.57 release (as compared to 5.56) include:
* The rendering of Monitors and Dashboard page was slow with large number of servers both registered and selected and when multiple users were connected simultaneously displaying the page. It could take one minute or more in some cases. It is now a matter of seconds.
* With a large number of servers registered, editing details for one was slow. Also this could take around 1 minute, and the improvement is in the same range as above.
* Event manager’s database (Events.data) is now moved from global level to server level in order to prevent locking problems with a large number of servers. MONyog will migrate data first time it starts after the upgrade.
* Fixed a multi-threading issue that in rare cases could crash MONyog while registering more than one server at the same time.
* Fixed a rare crash in MONyog while viewing replication tab.
* Fixed a rare crash in MONyog while resolving CSO’s (“Custom SQL Objects”).
* MONyog could fail to send mail alerts if a single mail contained alerts for more than one monitor.
* MONyog was showing errors in Query Analyzer, Realtime and Processlist pages when a query contained characters used for specifying HTML tags.
* If a registered server was not a slave but marked as such in Advanced Settings .. Replication, MONyog was leaking connections every time it was collecting data and finally connections (from MONyog as well as other clients) could fail due to ‘max_connections’ setting being exceeded.
* For MySQL InnoDB-related monitors were showing “(n/a)”. The reason was removal of the ‘have_innodb’ server variable in MySQL 5.6.