It is not quite true. Any user can “SHOW GRANTS [FOR himself]” with no privileges at all. But more important: SELECT priviege is requried on database-level,  Privilege to the privileges tables is not enough.  See

SHOW GRANTS;
/*returns

Grants for me@%
—————————————————–
GRANT USAGE ON *.* TO ‘me’@'%’
GRANT SELECT ON `mysql`.`user` TO ‘me’@'%’
GRANT SELECT ON `mysql`.`tables_priv` TO ‘me’@'%’
GRANT SELECT ON `mysql`.`procs_priv` TO ‘me’@'%’
GRANT SELECT ON `mysql`.`db` TO ‘me’@'%’
GRANT SELECT ON `mysql`.`columns_priv` TO ‘me’@'%’*/

SHOW GRANTS FOR root@localhost;
/*returns

Error Code: 1044
Access denied for user ‘me’@'%’ to database ‘mysql’ */

Anybody having SELECT privilege to the mysql database can read logs if you use log tables. And unlike when logging to files (where you can specify logfile paths)  there is no option to specify another database for the log tables.

I think it is a serious security flaw. The reason is that a log may contain data. That may be private data (email addresses, bank account numbers .. you name it). Consider a statement like

UPDATE `identity`SET  `bank_account_no` =  ….. WHERE social_security_id = ….. ;

You should have SELECT privilege to the `identity` table to see those data. But if you can read logs you need not.

I don’t claim all applications would send such statements (but I believe that some will do).  You can avoid it to some extent by using user variables, hashes, or by writing complex statements with JOINs and SUBQUERIES so that you don’t need to ‘ping-pong’ data from the server to the application and back (but it may conflict with performance in particular if SUBQUERIES are used).

So you should be careful with logging to tables. Not only is performance not good, but there are security concerns. Who should be allowed to see the logs? (but still log tables may be convenient for a test/development scenario though.)

I posted this bug report: http://bugs.mysql.com/bug.php?id=64215

Bug Fix:
* If multiple databases with same name existed only differing in lettercase SQLyog would generate certain statements using the ‘mostly lowercased’ database name. This bug was introduced in 9.5.

Downloads: http://webyog.com/en/downloads.php
Purchase: http://webyog.com/en/buy.php

The last one I came across is ‘skip-character-set-client-handshake’.  MySQL documentation http://dev.mysql.com/doc/refman/5.5/en/server-options.html says “To ignore client information and use the default server character set, use –skip-character-set-client-handshake; this makes MySQL behave like MySQL 4.0.”

Now what is the idea in having a recent server ‘behave like MySQL 4.0′ ?  There could have been some compatibility concerns in early 4.1/5.0 releases, but now (after 8 years) is it stilll relevant to have? I don’t think so.

The ‘chain breaks’ in the case where a client (we are talking about clients compiled with the C-API or a connector having similar functionalities as mysql_options() in the C-API – what means that it is not PHP we are talking about!) requires character_set_client to be utf8.  The client will execute “SET NAMES UTF8;” after connection just in case the server has a non-utf8 default charset.  It works fine.  SET NAMES works as expected. So far so good. Futher the client is using the ‘reconnect flag’.  Reconnects may take place after connection was lost  in several cases (client was idle for longer than wait_timeout, some tunnel system server (SSH tunnel, VPN tunnel) disconnected client and server, intermittent hardware or networking failures etc.).  The important point to note here is that reconnect is handled by the API transparently for the ‘parent code’ where it is linked. Thus the client cannot know  when to execute “SET NAMES UTF8;” again (as a regular SQL statement).  The client will instead set the connection charset to utf8 in mysql_options() so that utf8 also will also be character set for the connection after a reconnect.  But with the ‘skip-character-set-client-handshake’ -option set, it simply has no efffect (the option is intended to work like this).

As a consequense there is no way not to have non-ASCII characters garble in the client after automatic reconnection in such environment as far as I can see.

We had such report recently. It took some time to figure out the reason. There is also an old related bug here http://bugs.mysql.com/bug.php?id=11972 btw, but this is fixed long ago even though I first thought it might have found its way back to PerconaServer (what was used in this particular case), it was not the case.

It is fair enough to have compability options with older servers for some time.  But is it still after 8 years? Also in a case like this where it breaks the way a client and the server is intended to ‘negotiate’  multiple charsets?

More old options to get rid of?  I am a collector of such!

First of all this release of MONyog gives a brand new look to MONyog’s user interface and improves navigation in the MONyog pages.

As a consequence of this some controls and some information has been re-arranged – including:
* Introduced a left panel that contains the list of servers registered in MONyog, ‘Tools’ & ‘Customize’. The ‘List of servers’ page has been removed. Users can now select/unselect servers from this panel.
* Previously available icons for Edit server/Duplicate server/Diagnostic reports etc now appear as a drop down menu next to each server.
* Previously the ‘Customization’ page appeared under ‘Tools’, now it appears as ‘Customize’ on the left panel.
* ‘Manage Custom SQL Objects’ are now available under ‘Manage changes’ under ‘Customize’.
* The global notifications come on the top right hand corner before the help button.
* Pagination added in Query Analyzer page. This removes the previous limitation of 200 queries in the result set.
* The “Global Notifications” come on the top right hand corner next to log-out button.

Enhancement:
* Enhanced browser level caching.

Miscellaneous:
* The MONyog API responses are now in the following JSON format: {“STATUS”: “SUCCESS/FAILURE”, “RESPONSE” : “<Response text>”}.
* Query Analyzer will now display query text up to 5000 characters (before it was 2000).
* We have stopped supporting IE-7 (Internet explorer) from this version.

Please note that the documentation updates are in progress, but not complete with this beta release.

Downloads: http://webyog.com/en/downloads.php
Purchase: http://webyog.com/en/buy.php

Features:
* When performing CREATE/ALTER TABLE operation from inside the Schema Designer now a dialog with a tabbed interface similar to the CREATE/ALTER TABLE tab will open.

Bug fixes:
* In Data Sync a low setting of  ’max_allowed_packet’ on source server could result in CONCAT_WS() used for checksums’ calculation returning NULL . We did not consider this and as a consequence rows could fail to sync without warning.  We will now abort the job with an error message (if user has selected to ‘abort on error’) or print an error to the sja.log file and the console (if user has selected not  to ‘abort on error’ ) informing that some rows may have been skippped in such cases.
* The fix for empty string defaults in 9.51 was not complete. It was (unlike 9.5) possible to create such default but it did not display as ” after creation in ALTER TABLE.

Downloads: http://webyog.com/en/downloads.php
Purchase: http://webyog.com/en/buy.php

Bug fixes:
* Custom SQL Objects (CSO) with a large result set could fail to display content in Monitors/Advisors page.
* Specifying the “Key Column” field has now been made mandatory while adding a new CSO. If not specified the CSO will not save.
* Small UI fixes.

Downloads: http://webyog.com/en/downloads.php
Purchase: http://webyog.com/en/buy.php

Features:
* The active database context is now highlighted in Object Browser using a bold font.

Bug fixes:
* Drop-downs in the DATA and RESULT tab grid (used by SET and ENUM columns) could ‘drop down’ where they should ‘drop up’ instead.
* Specifying empty string defaults for strings columns was broken in 9.5.
* Fixed a rare crash caused by an undoumented behavior from the Windows API resulting in division by zero. Crash is now avoided by adding an additional condition check.
* Fixed a painting issue in the Foreign Key tab in the new (from 9.5) tabbed interface for CREATE/ALTER TABLE that could render the interface here unusable on some systems.
* Other minor fixes with same tabbed interface.

Downloads: http://webyog.com/en/downloads.php
Purchase: http://webyog.com/en/buy.php

This is due to both server ‘forks‘ as well as various plugins and 3rd party storage engines available.   Each of those will often add  information that can be fetched from the server – typically in the form of additional Information_Schema tables. This content can now also be utilized for monitoring MySQL servers with MONyog. MONyog 4.8  implements monitoring based on Custom SQL Objects.  It is basically just a SQL query. Any query returning a result set can be used for monitoring.  MONyog will collect results from the query and you may define counters on it exactly as you want.

It is really very simple.  In this example we will utilize the `accounts` table that was added to the `performance_schema` database in MySQL 5.6.3 (but you could also use the ‘user statistics plugin’ originally published as a Google patch and now distributed with MariaDB) . Basically only two steps are required:

First step: Navigate to TOOLs tab .. Customization .. Manage Custom SQL Objects .. Add/Edit Custom SQL Objects and here enter the query. Note that you must also define a unique column (or a unique set of columns).

Also define the sample interval and the retention timeframe for this particular query and on what MySQL servers the query should be executed.  MONyog will now start collecting the data as you have specified.

Second step: Navigate to Monitors/Advisors tab .. Add new Monitor/Advisor. The result of the query you defined in first step is exposed as a javascript array to the MONyog javascript engine. Enter the  javascript defining the content, display, formatting etc. of the new counter in order to make it display as you want. Add an advisor text as well  if you want.

You have now created a Custom SQL Counter based on the Custom SQL Object Object that was defined in first step. You may create a new counter group for the new counter what we have done here:

.. but in this particular case it would also make perfect sense to add the new counter to the existing ‘current connections’ group. Also note that if you want to define WARNING and CRITICAL thresholds on a counter and alert on it, the SQL and/or javascript must be framed in such a way that the counter returns a plain number.

We would like to hear your feedback – and not at least how you use this in your environment. What are you monitoring now that you did not before?

Downloads: http://webyog.com/en/downloads.php
Purchase: http://webyog.com/en/buy.php

The year of 2011 has been a terrific year for us.  But first let us have a look at where we started 10 years ago. The first version of SQLyog was released in the spring of 2002 – what will mark our 10 year anniversary as a company early next year. In the period since then we have seen quite a lot of other MySQL clients come and go. We are happy to see most of our existing customers upgrade regularly, to see our user base increase, and we are happy to do our best to provide the solutions requested by users and to keep pace with MySQL development.

And also 4½ years ago we added MONyog to our portfolio. So there will be another important anniversary to celebrate in 2012 as well. MONyog has also proved to be robust and long-lived.

We are continuing to develop both programs aggressively in interaction with users and partners. And the combination of SQLyog and MONyog under one hood has enabled us to achieve important strategical partnerships across the MySQL ecosystem.

And don’t forget that Webyog is not only tools for MySQL. Also Visifire has now become a very respected charting solution for Silverlight, WPF and Windows Phone. Several benchmarks and reviews list Visifire as the most efficient and most competitive solution. Our IssueBurner application provides an integrated issue-tracking and helpdesk solution in a single and very competitive package. And add to this CloudMagic that in a second finds various information from Cloud-based services and presents it all in a unified interface.

The diversity of the different solutions that Webyog now offer is important not only for us as a company but also for users, because it ensures robustness of our company and guarantees continued support for all customers also if one of the ecosystems where we operate should face a slowdown or setback for a period. We have the robustness to continue developing what we want and what we have planned in a turbulent world.

We have more in our bag that we will share with you soon, Stay tuned!

The above diagram shows how Monitors & Advisors (MySQL Counters) are populated. MONyog has a repository of SQL Queries which are executed in regular interval of time & the results are stored in SQLite database of MONyog. These results are exposed as JavaScript objects and are referenced to populate Monitors and Advisors (MySQL Counters).

With CSO, you can add your own SQL queries to this repository & customise counters based on that. Discussed below are some cases on how useful CSOs can be.

• Maintenance statements, for eg. CHECK TABLE, REPAIR TABLE etc.
• You could query on Information Schema to monitor the size of a table. You can also configure it to alert when it crosses a threshold.
• Keep yourself updated with the worst performing indexes.
• Third party MySQL forks have some non standard tables. For eg. you can query on Statistics table of Percona MySQL fork to fetch information about unused index.
• You can monitor MySQL clusters too, by querying Ndbinfo Schema.

Refer the following posts for detailed release notes:

• MONyog 4.8 Beta 2 Released
• MONyog 4.8 Beta 1 Released

MONyog customers can download the latest installer from Webyog’s Customer Portal.

To evaluate MONyog, please download the 30-day trial.

We are very excited about this release, and hope you like it. We would love to hear from you.

Regards,
Team MONyog