Changes (as compared to 4.62) include:

Features:
* Added a MySQL replication overview page. Here MONyog shows the replication topology of all registered MySQL servers, as well as SLAVE STATUS and MASTER STATUS where it applies. The display gets updated at user-specified interval. Note that this is available only in Ultimate version of MONyog.

Bug fixes:
* Fixed an issue where MONyog did not logout user successfully.

Miscellaneous:
* Instructions to setup MySQL Proxy was added to MONyog interface.

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

Comments(0)

We have released SQLyog 9.2 GA with enhancements to the Data Search feature (and more).

Since we introduced the Data Search feature in SQLyog 9.1 we had a lot of positive responses – but also a few critical remarks that using the feature could cause unnecessary server load as well as unnecessarily long response times. Such scenario could arise when searching for a string in a BLOB column used for storing media files for instance. Or when searching all tables of a database when there was only need to search a few tables.

We have addressed this concern by adding filter options that let the user restrict the search to specific data types and to a subset of databases of a server, a subset of tables of a database or a subset of columns of a table.

Also we have added “+” and “-” operators for inclusive and exclusive exact match.

I would like to elaborate a little more on Data Search:

Data Search does not replace SQL, of course. It is a supplementing feature. It is in particular useful when your are searching for something you don’t know what exactly is and don’t know exactly where to find. And when you are just too lazy to write a long SQL statement. As we have posted here before you could consider the Data Search feature as a tool to ‘google your database’ (as google ‘advanced search’ operators are used). But a database has a hierachy and has datatypes what a document has not. So this filtering option is a logical database-related enhancement to the google ‘advanced search’ syntax used for documents.

Let us take an example: Suppose you want to find all instances of email addresses with a specific domain name in all your networked systems (on the Internet as well as Intranet). We have 3 such public systems (our Forums, Blog and FAQ) for our MySQL-related products alone  that are ‘standard applications’ that we did not code ourselves and thus do not know internals about very well. In all those systems people may comment or contact us. Add to this our non-public systems – like our CRM system and our support ticket system (based on our own web application IssueBurner that aggregates everything sent from and received to our contact email addresses to a database). As all the mentioned systems use a MySQL backend we will now easily be able to answer the question “Who have ever contacted us with a @like.this email address, when did it happen and what was the subject/matter?”. Simply because we can find the data in all systems. And anybody in our organization can do (provided that they have access) without knowing details about how and where the different applications store the information.

When we introduced Data Search in 9.1 I actually expected some comments that “this is a feature for amateurs and I do not intend to use it as I am familiar with SQL”. We did not get such comments till now! I think users already found out that it saves a lot of time.

Also in this release we are following up on the ‘Foreign Key lookup’ introduced in 9.0. This is now also functional from the RESULT tab in SQLyog.

And finally In this realease we added a ‘date picker’ GUI for managing DATE, DATETIME and TIMESTAMP columns as well as an option to clone a connection. Both were popular user requests for some time and have now been implemented.

See all details for this and other recent releases here.

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

Comments(1)

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)?

Here we will concentrate on one deployment scenario:  the scenario where the user want to monitor a large number of MySQL servers from a single MONyog instance on a dedicated machine (running MONyog alone or shared with other utilities such as network monitoring systems) placed in their Intranet environment.  Note that this is not the only deployment scenario however – in particular we have noticed that an increasing number on users deploy MONyog on the Cloud. This includes an Amazon EC2 micro-instance (free for 1 year, and then $14/month) from where you may monitor a handfull of MySQL instances. But let us concentrate here on the ‘traditional’ scenario: monitoring a large number of MySQL servers from a single MONyog instance.

The short answer is “Just relax.  MONyog handles monitoring hundreds of MySQL servers from a single instance using a cheap ‘state of the art commodity system of today’”.

The longer answer (aggregated from a few replies to users in our support ticket system over the last months) could be this:

* General system considerations: You can safely monitor 200+ servers on a ‘state-of-the-art commodity machine’. This may maybe not quite be understood as ‘a machine you buy in the supermarket around the corner for 500 $’, but so-called ‘dedicated server hardware systems’ are not requried at all.  MONyog simply does not need it due to its lightweight design.  Look for a good quality ‘workstation machine’ or similar simply. We have actually been able to monitor 500 MySQL servers with a sample interval as low as 1 second from a Dual Core 3 Ghz machine. However the load (CPU and I/O) will of course depend what requests the users sitting in front of their browsers send to Monyog.  There are some functionalities/reporting modules that take more resources than others. Thus the ‘conservative’ statement that “You can safely monitor 200+ servers on a ‘state-of-the-art commodity machine’.” (but you may very well be able to do more, actually!)

* Multithreading: MONyog is very much multithreaded. For every MySQL server monitored a seperate thread will run. If you enable OS monitoring one more will run for each. One more for slave monitoring if you use it. Other threads handle I/O from and to SQLite, serve HTTP-requests, send mail alerts etc. With 200 MySQL servers you will likely have 500-1000 active threads inside the MONyog process. But this is not much related to number of CPU cores. You can have multithreaded systems running on a single core system. Multithreading is a software concept – not a hardware concept. Actually we primarily stress-test MONyog  on a 3 Ghz CoreDuo machine running 64 bit (CentOS) Linux. We have other systems  – including a 4-5 year old 32 bit Pentium 4  (single core) machine used for testing with 32 bit Linux and Windows. The test systems all  have plain 7200 RPM ATA/SATA harddisks and no more than 4 GB of memory (some have 2 GB only). So Monyog does not require a lot of CPU cores to run smoothly. But as it is heavily multithreaded  it will use multiple cores efficiently if running on a recent OS that does.

* Memory: The only component of MONyog that may use considerable memory is SQLite due to its caching mechanism. The way we have linked the SQLite library in our code restricts the SQLite cache not to grow beyond 2 GB. Of course the MONyog built-in HTTP daemon etc. will also use a little memory, and also the OS will, but you will in most scenarios not harvest any significant performance gain on a dedicated MONyog machine adding more memory than 4 GB. If you want to be on the safe side to avoid swapping and want to analyze very large (slow or general) query log files in particular you could consider 8 GB memory for your dedicated MONyog machine.

* CPU: With MONyog running on this ‘commodity machine’  with 200 servers registered you should expect an average CPU load just around 10-20% with a (for monitoring) reasonable sample interval (minutes, not seconds) as long as MONyog just collects data and a single client (browser) is connected watching the MONyog Dashboard page, Processlist page or the Monitors/Advisors page. It also depends on how much you use SSH-tunnel to your MySQL servers and if the ‘query sniffer’ is running for the MySQL servers monitored or not. However the user may send some specific requests to MONyog that will require extensive calculations. For instance (slow or general) log analysis with large log chunks does and  history/trend analysis with GROUP BY option does if you have selected a large time interval for analysis. If some user requests such, MONyog will use as much free CPU as the OS allows a single process to do until the calculation has been completed -  and then obviously the more powerful the CPU is, the faster the calculation will be performed and the sooner the user will see the result. However for normal use a ‘state-of-the-art’ consumer dual- or quad-core 2-3 Ghz CPU is fully sufficient.

* Storage systems: Don’t think about SAN, expensive external RAID racks of whatever of the kind. But ‘a little faster than normal disk system’  (like a 10K RPM disk, some small RAID system etc.) could be used with advantage – in particular if you monitor your servers with a short collection interval (say less than 15 seconds) where I/O could be the first ‘bottleneck’ encountered.  Also we have not done any specific optimizations for solid-state disk systems in MONyog simply because we consider it un-necessarily expensive ‘overkill’ to use such with MONyog. However a major part of what I/O operations MONyog does is handled by the SQLite library and SQLite is used extensively on systems with solid-state storage and handles it very well – so if you want you can use it.

Download the MONyog whitepaper: http://www.webyog.com/en/whitepapers/MONyogWhitePaper.pdf
Read the MONyog documentation online: http://www.webyog.com/doc/index.php
Download MONyog TRIAL: http://webyog.com/en/downloads.php
Purchase MONyog: http://webyog.com/en/buy.php

Comments(3)

I wanted to download MySQL Proxy 0.72 (the latest stable to my best knowledge) but I found ..

1) This page: http://www.mysql.com/downloads/ does not list MySQL proxy at all.

2) Anyway all versions up to 0.81 are available from FTP mirrors (like ftp://ftp.easynet.be/mysql/Downloads/MySQL-Proxy/) so I was able to get my hands on it.

Accidentially I found shortly after that ..

3) This page: http://dev.mysql.com/downloads/ (only) has 0.81 ALPHA listed.

4) Here http://bugs.mysql.com/bug.php?id=61474 MySQL supporter references a version 0.9 that is nowhere referenced on mysql.com nor dev.mysql.com but seems available from Launchpad.

I don’t understand why stable versions are not available from mysql.com any more.  I think I know/understand  that there were some securtity concerns with pre-0.8x (but they do not affect me with my environment so I am happy with 0.72). In any case I find it very confusing that a GA/stable version is withdrawn once published without even a note about why it happened.  I cannot know of course if this is a deliberate choice or maybe just a mistake by the MySQL web team. But as said: I find it very confusing that a GA version suddenly is not available where it used to be. If it has so serious issues that they/Oracle do not want to distribute it, then http://www.mysql.com/downloads/ should have a note about why it was removed and tell about 0.81/0.9 version(s) download options (from dev …).

I tried to ask about this in the above-mentioned bug report. The supporter here was not in a position to reply (what I understand and accept – and I probably should not have asked there).  But the problem is that I don’t know where else I could ask.

Please tell: was the removal of 0.72 from http://www.mysql.com/downloads/ a deliberate choice (and if so, why?) or a simple mistake (if so, please fix it!). And if there is a 0.9 (development) version that can be considered good enough for ordinary users posting a bug report to test with, then why is it then not available on http://dev.mysql.com ?

Comments(5)

Mark Callaghan blogged this: http://www.facebook.com/note.php?note_id=10150236650815933

He refers a bug report that has now  been marked as private for some reason. I have been subscribed to it from the beginning (and thus have all details in my inbox) and I think Mark misses the point raised by the bug reporter here.  Mark has another and equally important point.  What they have in common is that there are situations where a statement longer than max_allowed_packet is written to the binlog.  If the host where it happens is a replication master there are scenarios where this will break replication where it should not.

The ‘how to repeat’ section of the original report (that was verified by inspection of the binlog) reads:

1) Make sure the max_allowed_packet variable is set to 16777216 in MySQL.
2) Make sure binary logging is enabled
3) Send an UPDATE query that is slightly less than 16777216 bytes long. This update query has a large amount of text including many tab characters (\x0a).
4) MySQL writes a binlog event that is 16784830 bytes long.

(except for that I will respect Oracle’s decision and not reveal more details of the discussion – even though the ‘privatization’ here seems ‘overkill’ to me.  But maybe they know more than what I do)

I understand this case like the UPDATE actually succeeds (on the the machine where it executes that happens to be a master)  but next fail to replicate (due to the fact that the event binlogged is longer than the original statement and exceeds max_allowed_packet).  Here the client actually does respect the max_allowed_packet setting. Mark’s concern seems to be another (where the client does not respect the max_allowed_packet setting).  Correct me and enlighten me if I am wrong!

Actually I think it is not possible for a client to know whether a server is a replication master or not. It should be safe to execute statments up to max_allowed_packet setting. Or at least what ‘safe margin’ is required should be documented (but just documenting seems to be not satisfactory).

(and BTW: I am not replying raising this discussion in Mark’s post because it would require me to to have a Facebook account what I do not have and do not want to have)

Comments(1)

Changes (as compared to beta 1) include:

Features:
* Added a filtering option in Data Search. You may select to search specific data types only and/or a subset of databases in a connection, a subset of tables in a database or a subset of columns in a table.

Bug fixes:
* ALTER VIEW could fail to open the view definition in MySQL 5.1+ if an underlying table was ALTERed after creation of the VIEW. This is a server bug due to which SHOW CREATE TABLE failed. SQLyog now works around this bug by fetching the VIEW definition from information_schema if SHOW CREATE TABLE fails. One limitation of this is that the ALGORITHM clause will not necessarily be the exact one specified while creating the view as Information_Schema has no record of the ALGORITHM clause.
* Execute SQL Script will now show data transfered in percentage rather than the size. Once the execution/import is succesfull it will show the total size.
* Removed extra whitespace in query when displayed in the message tab due to an error.
* The execution time displayed for a query is now formatted for better readability.
* SJA could fail to send mails when using a SMTP server on localhost.

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

Comments(0)

Changes (as compared to 4.61) include:

Bug fixes:
* The counter for ‘thread cache hit rate’ could display incorrect values.
* Authentication with the admin password could fail in some cases on Windows. This bug was introduced in 4.61.

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

Comments(0)

Changes (as compared to 4.6) include:

Bug fixes:
* MONyog now writes default data into MONyog.ini file on all platforms when MONyog starts for the first time. Before this release MONyog for Linux did not write default data into MONyog.ini file.
* In the Dashboard & Monitors/Advisors page, the Delta & All-time/Current charts were showing some incorrect values when values were plotted per second. This was introduced in MONyog 4.51.
* While connecting using SSH with key based authentication in Windows, the temporary file which contains the SSH private key was not being deleted. Before this release, the temporary files could run out of names which made it impossible to create new temporary files and hence the SSH tunnel was not being created.
* Fixed a crash occurring when there was no data directory path defined in the MONyog.ini file.

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

Comments(0)