What does FLUSH STATUS do? We all know that it will simply reset all status variables (except for ‘uptime’) to same values as immediately after a server restart. Just google it and you will find that behaviour statet on hundreds of sites on the Internet.

But NO – it is not true! Not anymore. MySQL documentation:
http://dev.mysql.com/doc/refman/5.5/en/flush.html

“This option adds the current thread’s session status variable values to the global values and resets the session values to zero. It also resets the counters for key caches (default and named) to zero and sets Max_used_connections to the current number of open connections.”

This bug report …

I have for the first time been spending some time trying to understand the performance_schema. It is not easy to understand everything unless you are very well-versed in server internals (what I am not) and much information available here is probably more useful for server developers and testers than for ordinary users. But anyway some of the P_S tables are reasonable simple and useful. For instance the ‘accounts’ and ‘hosts’ tables (introduced in MySQL 5.6x) are immensely useful for everybody.

The reason why I spent time with this now was (I am totally egoistic, of course) that we just released the first beta in a new MONyog release cycle where you may expose P_S contents for monitoring. Please refer this Blog.

However I have two …

Introduction:

If you have been using MONyog you will know that any metrics/counters may be identified with either of the ‘states’ STABLE, WARNING and CRITICAL. For those metric where it is relevant MONyog ships with settings for this that are (to the extend possible) commonly agreed ‘best practices’ by MySQL DBA’s. Metrics in a WARNING or CRITICAL state display with a (yellow or red) ‘marker’ indicating that this metric is not in a STABLE state. For metrics in a CRITICAL state further an alert can be sent (as a mail alert and/or a SNMP trap).

If the ‘best practices’ we have implemented in MONyog do not fit your environment or use case, it can easily be customized. Open the MONyog ‘Monitors/Advisor’ page, click on the name of the metric you want to adjust (it is a link). A small popup opens. As an example let us take the ‘Connection usage’ in the ‘Current connections’ group. In the popup …

We are pleased to announce the release of MONyog 4.7 GA. Below is a brief on new features:

Dashboard

The world is moving towards tablets (I agree iPad in the title is a misnomer) and most of them don’t support Adobe Flash. As you know MONyog dashboard charts were on Flash and did not work on tablets. With this release we have switched to HTML5 charts. Not only do they work on all Smartphones and Tablets, they are faster than Flash charts. Hence, desktop users also gain from this release.

Flash charts used elsewhere in MONyog are also changed to slick HTML5 charts.

Embedded in this post are screen-shots with relevant section zoomed-in on an iPad.

…

We are often asked by users deploying MONyog what hardware system they should plan for it. Typically they have been evaluating and testing with a few MySQL servers only. Now after evaluation they are planning the deployment and  users that want to monitor a large number of (local/LAN-based, remote/hosted and Cloud-based) MySQL servers from a single dedicated MONyog machine will often ask us questions like

* How many MySQL severs can be handled by a single MONyog instance?
* How powerful should the CPU be? Any specific model(s) recommendation?
* Is MONyog multithreaded and will it take advange of multi-core architectures?
* How much memory is required?
* Are there any requirements or recommendations for the storage system?
* Will MONyog do better with advanced storage systems (SAN, RAID setups, solid state storage systems)?

With this release we further enhance the ease of MONyog customization. This includes:

* This release ships  with a bunch of useful Dashboard charts which can be enabled/disabled from the ‘manage dashboard charts’ in the Dashboard page. Users will not need to write any Javascript to enable those.
*  Dashboard charts can now be reordered. User will be able to place those most important for him on top.
*  Added an option to copy/duplicate advisors. This can be used as a template to make a new Monitor/Advisor.

See the new interface for Dashboard configuration interface here:

Further we added an option to alert on server configuration change and fixed a few minor bugs.

Downloads: …

Please note that when upgrading from a version previous to 4.5  to this one, it is required that MONyog detects the replication topology of registered servers before the ‘registered servers’ page can display. This may take a few minutes with a large number of registered servers. Please be patient for as long. Note that this delay will only happen once.

Changes (as compared to 4.5) include:

Features:
* This release focuses on improving performance of the MONyog built-in HTTP daemon. You will find up to 10 times performance improvements for most MONyog pages. This has been achieved by internal code optimizations, use of compression (if browser supports) and minification/optimization of HTML, Javascript, CSS and graphics.

Bug fixes:
* Prepared statements were not handled properly by the Query Analyzer.
* Events (as …

Hi,

We are delighted to announce the release of MONyog 4.5. Listed below are some noteworthy features:

• You did get to know about what needs attention in Monitors/Advisors, but how about looking at all the alerts that need attention grouped on their severity for a certain period? This is what event is all about. An event occurs when the status of a counter changes. Keep your events tab open & you see MONyog alerting you – may it be “server availability” or “replication failure” or many other umpteen things that need attention.
• Many a times, MONyog shows an alert to bring your attention, but you are OK with that & don’t want to fix it. Just close the event & it will appear only when it becomes alert-able again. This is a nice way to accept & dismiss events, so that you can start with a clean slate with a baseline for normal acitivity for that instance.
  …

Cloud, cloud, cloud. Cloud computing has become the phrase du jour, says one analyst from Gartner. But with many moving to cloud for its obvious benefits, it can no longer be ignored. An offshoot of cloud computing is utility computing. What interests us here is Database-as-a-Service, in particular MySQL on cloud.

Coming back to our original question – Is your MySQL monitoring tool cloud ready? Well, many monitoring tools need agents on server to be monitored. For obvious reasons database-on-cloud vendors don’t allow one to install anything on the servers. With Amazon launching RDS (which is nothing but MySQL instance on cloud) there is a pressing need for tools that …

The highlights of this release are:

* A brand new helper function interface: We have implemented an easy-form based interface for customizing helper functions. Any customization of helper functions or user defined functions being used with earlier versions have to be migrated manually to this version. From this version and onwards a GUI-’conflict resolver’ will guide the users very similar to how it works for customized counters.

* Apply settings to all servers of a specific tag: MONyog now has an option to apply a group of settings to all the servers with a specific tag. (Please note: New servers registered later with the same tag are not considered)

* Enhanced readability of MONyog logs: MONyog logs from now on contain the server name along with error making it easy to backtrack.

* Earlier multiple alerts for same issue would be sent …