Changes (as compared to 8.22) include:

Features:
* Added an option to define a ‘color code’ for a connection. The color will be used as background color in the Object Browser.
* A Query Builder session can now be saved and resumed.
* In Query Builder a table alias can be defined for any table by double-clicking the title bar of the table symbol.
* In RESULT tab results can now be retrieved page-wise. This is ON as default with this build with a defined LIMIT of 1000 rows. For a specific query user can change and for this specific query the setting is persistent across sessions. Also read ‘miscellaneous’ paragraph below.
* Added a context menu to Query Builder canvas.

Bug Fixes:
* Deleting a user would leave non-global privileges orphaned in the ‘mysql’ database. Now we use DELETE USER syntax if server supports.
* Also using EDIT USER dialogue to change host or user specifier for a user would not move non-global privileges. We have split the old ALTER USER dialogue into two: a EDIT USER and RENAME USER dialogue. The latter will use RENAME USER syntax if server supports.
* On Wine Data Sync could generate a malformed XML-string what would case Data Sync to abort.
* Fixed an issue where SSH-tunneling failed with public/private key authentication. Technically the fix is in the PLINK binary shipped with SQLyog.
* SJA failed to send notification mails if Yahoo SMTP servers were used. Note that the fix disables encryption option with Yahoo SMTP servers – but it won’t work anyway due to a non-standard SMTP implementation server-side.
* When importing data from a Universe ODBC-source string data could be truncated.
* The fix in 8.22 for the issue that horizontal scrollbar in GRID would sometime not appear was not complete. It could still happen.
* SQLyog will now trim trailing whitespaces in Connection Manager and Create object dialogs to avoid MySQL Errors..
* Opening a file from ‘recent files’ list could crash SQLyog if a Query Builder or Schema Designer tab was selected and the file specified was not a valid XML file for that tab. This bug was introduced in beta 1.
* When calling a Stored Procedure with more than one SELECT statement from ‘Notifications Services’ only one result set was sent by mail.
* The sja.log file had no line-breaks between what was recorded for two jobs.
* On multi-monitor system resizable dialogues could open on the wrong monitor. New implementation is like this: on multi-monitor systems main program dialogue and ‘first child dialogue’ (example: ALTER TABLE) will open where they were closed (if possible), second and higher child dialogues (example: table advanced properties) will always open on top of its ‘parent’ dialogue. Non-resizable dialogues (such as confirmation boxes) will always open on top of their ‘parent’.
* With multiple SSH-tunnelled connections open stopping and re-executing queries in multiple connections in a fast manner could crash SQLyog.
* If more than one comment occurred before a SELECT statement in the editor, the statement was not identified as a SELECT statement by the Query Profiler and the Query Profiler TAB would not display.
* We did not validate client-side if user checked atoincrement option for a bit column with Create/Alter table dialog.
* If an error occurred while renaming a trigger then trigger was lost as SQLyog was not recreating it back.
* Small GUI fixes.

Miscellaneous:
* The default LIMIT setting for DATA tab has been removed. The setting is not required since we introduced table-level persistence for number of rows displayed. The default for new tables that have not been opened before is 50 – but when user changes the value and next ‘refresh’es SQLyog will save the LIMIT for that particular table persistently across sessions. This in combination with page-wise display in RESULT tab results in a more uniform User Interface for DATA and RESULT tabs.

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

Comments(0)

Changes (as compared to 3.71) include:

Features:
* The number of builds for Linux has been increased to the double number of what it was before.  In addition to the builds based on glibc version 2.3 we now distribute builds based on glibc 2.5.  Also we add builds for use with even older glibc 2.3 based Linux that what we had before. There are now builds based on both glibc-2.3.2  and 2.3.4 (the one based on 2.3.4 is the one we had before). We had a few  reports of random crashes (typically occurring up to a few times per week) occurring on recent 64 bit CentOS servers and in one case also a RHEL5.  The glibc 2.5-based build fixes this. Although we only had such reports on 64 bit Linux of  ‘Red Hat Family’ we also included 64 bit tar.gz for all Linux platforms and 32 bit RPM builds.  The general advice on which build (glibc 2.3-based versus 2.5-based) should be used in every case would be that if glibc 2.5 or higher is available on the system you should use the 2.5-based build.  Or simply use the one based on 2.5 if it installs and starts on your system. Upgrading users that are in doubt can continue with 2.3.4-based builds if they have no stability issues.

Bug Fixes:
* When MONyog encountered an SSH error while trying to read a file using SFTP  it could crash. This has been fixed.
* Redundant “Server Restarted” alerts concerning monitored Linux systems could be sent by MONyog. Now MONyog will notify users only once when a system is restarted, and alert will be sent as soon as MONyog detects it.
* When restarting MONyog an error message could be written to the log indicating that an ALTER TABLE SQLite query failed to execute. Technically it was an issue with a Schema version table in the MONyog database.

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

Comments(0)

Changes (as compared to 3.7) include:

Features:
* Added a monitor for InnoDB deadlocks (as exposed by SHOW ENGINE INNODB STATUS -statement).
* In case of a program crash on Linux, MONyog will save a core dump like the Windows version already does.  The dump is saved in ../MONyog/bin folder.

Bug Fixes:
* EXPLAIN from Processlist page could fail with syntax error due to a missing SPACE character in the statement.

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

Comments(0)

This morning I checked planet.mysql.com and to my surprise I found that a topic from our (Webyog) Forums (http://www.webyog.com/forums/index.php?showtopic=5066) was syndicated to planet.mysql.com.  I am not able to understand how that could happen. To my best knowledge I never asked for it. However I do not mind personally if somebody else found a way to syndicate this particular post. It may be useful for somebody. But who owns the right to syndicate that Forums topic really? The user that originally posted in our Forums? Me? Or Santa Claus maybe? I would not do myself without the accept from the poster of the topic.

In our Blog (http://www.webyog.com/blog) we have an option to set a ‘mysql’ category for a post.  What posts appear marked with that category get syndicated. Until now nothing more and nothing less. This we manage very strictly. Only principal discussions related to MySQL and release announcements for major new releases (not betas, not small bugfix releases) get into the ‘mysql’ category.

But now somehow a Forums post got syndicated too.   Whether this is a deliberate action by somebody or some kind of systems error, I am not able to tell.  If such may happen due to some systems error or if anybody can syndicate anything there is a chance of copyright violation.

However the primary reason for this post is that I want to make it clear that we do not intend to spam planet.mysql with feeds from every post in our Forums! And we are not able to understand what happened this time.

Comments(8)

MONyog MySQL Monitor 3.7  Has Been Released.

From MONyog 3.7 we have introduced 3 editions of the commercial version of MONyog. When we had first released MONyog 2 years back, it was already an almost complete tool for monitoring MySQL servers based on what the MySQL server exposes on SHOW statements.  Since then we have added features that are not basic server monitoring features in the strict sense but additional or supplementing features.  Most important the Query Analyzer was added around one year ago.

Multi-user authentication is a long standing request from customers belonging to large organizations – or just having the need for monitoring lots of MySQL servers. There may be multiple server administrators. There may be development/test servers that the developers of that organization should be able to monitor, but is may also be unwanted to give them access to see details from servers having delicate information (customer data, payroll data etc.).  We have completely rewritten the MONyog authentication system.  It is now possible to create multiple user profiles and give access for a specific user to a subset of servers available only.  Additionally specific ‘admin’ functionalities (access to edit server settings, to KILL queries and to execute FLUSH STATUS) can be disabled for a user.

As MONyog is no longer just a tool that organizes what the server exposes on SHOW statements – but rather a ‘bundle’ of tools – we have realized that not all tools are useful to every MONyog customer. MONyog is no longer a “one-size-fits-all” application. MONyog caters to a very diverse range to customers. In some organizations MONyog may be used by a single person only, and in other organizations by dozens of people. Some users will not use the Query Analyzer at all (because they only run standard applications where they are not in control of schema and query design anyway). And so on.  The Ultimate edition is for those users in particular that have full control over their database and their applications and who need multiuser authentication.  The Enterprise edition provides the basic monitoring functionalities as well as the Query Analyzer – but not multi-user authentication.  The Professional edition is an entry-level version with the (original) basic monitoring functionalities. Refer to the comparison sheet for full details.

We thought it is now the right time to have multiple editions of MONyog. This also means that people can start with the lower edition and gradually move to a higher edition if the need arises. This will also reduce the overall complexity and total cost of ownership for several customers.

We have also migrated all existing MONyog customers to MONyog Ultimate and Ultimate upgrade prices are kept moderate.  So if you are already a MONyog customer your Total Cost of Ownership remains same while you continue to enjoy the powerful tools and features of Ultimate.

Release notes in traditional form can be viewed here.

Feel free to leave your feedback in the comments section.

Comments(3)

Changes (as compared to 8.2) include:

Features:
* Now SJA will also send mail alert if job aborted due to MySQL error. Before it was only internal SJA error.
* The local port used by SSH-tunneling will now be selected automatically. This will avoid conflicts in case multiple programs use SSH. Also with Data Sync from command-line/scheduler it was possible to use same port for both connections what would effectively sync a server with itself.
* Caption for ‘Parse’ button in Notification Services Wizard was changed to make it clear that it will actually execute the statement(s) entered. There is no way to let the server parse a statement except for executing it.
* Connection windows for SSH connections will now list SSH host details in the title bar.
* Tooltips for an icon will now list the keyboard shortcut performing same action.
* The option to display ‘all’ versus a ‘LIMIT’ed set of rows in DATA tab is now table-specific and saved across sessions (note that – similar to the ‘column width persistence’ feature – connection parameters are not using for identifying a table; only the database name and the table name are).
* Objects in an Object Browser node is now sorted case-insensitive.

Bug Fixes:
* Continuously clicking the ‘Calculate’ button in Schema Optimizer in a fast manner could crash SQLyog.
* The keyword.db file (used by auto-complete and syntax highlighting) is now read only. Various validators for Windows7-compatibility would report that SQLyog wrote to “Program Files” folder at runtime (what it did not).
* When copying to clipboard an out of memory error could occur also when there was enough memory.
* The table menu will now indicate what storage engine is currently used for the table.
* Autocomplete and syntax highlighting did not recognize keywords archive, blackhole, federated, example, maria, pbxt, federatedx, falcon and mrg_myisam.
* Notifications Services/’Send Query to Email address’ option did not send a mail if an error occurred. Now a mail listing the error will be sent.
* We did not validate client-side if user specified a default value for an auto-increment column (what is invalid with MySQL).
* In DATA and RESULT tab the context menu was only working from GRID-cells. Now it also does from GRID headers and ‘whitespace’ in the tabs.
* Updating a ’TIMESTAMP on update CURRENT_TIMESTAMP’ had no effect (the particular column was not listed in the UPDATE-statement sent by SQLyog). This was a necessary restriction before 8.13 but since we – from 8.13 – only list columns that have actually been edited by user, we can now lift this restriction.
* Import External Data – TRIGGERS could fail to update a SQL Server (n)varchar if it contained an empty string.
* If user had selected to save SSH-password locally and later changed the password, the new password was not saved – unless clicking ’save’ button in connection manager interface.
* When importing an external script with no explicit SET NAMES on top, SET NAMES latin1 was executed by SQLyog. Now we won’t do this – and server default charset will have effect for the import in such case.
* Autocomplete did not handle identifiers with the ‘_’ character correctly what could result in too many matches when matching the database with a pattern in editor containing such character.
* Other small GUI fixes.

Miscellaneous:
* This release ships with an updated tunneler file for HTTP-tunneling. In the old tunneler file functions were used that are depreciated in PHP 5.3x.
* The ‘Objects’ menu was renamed to ‘Others’.

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

Comments(0)

Happy new year!

Just before Christmas the number of downloads of MONyog (from distinct email addresses) crossed 100,000. Here is the situation as of now:

This is of course a nice Christmas present for us to have. But more important: it reflects that today – as opposite to the situation just a few years ago – that even average MySQL users have understood that tuning the server configuration as well as the schemas and the queries used by applications is essential.

The default settings for the MySQL server are not appropriate for a heavy-loaded server and even the standard configuration files (or configuration ‘templates’) shipped with the server will not have the specific settings required for optimal configuration in most situations. And even the best server configuration won’t help much if databases and queries are poorly designed. We benefit from the growing understanding of this but also believe we have contributed significantly to it by making MONyog available. Its agentless design and the total lack of dependencies on external programs (database, web server, scripting environments) makes MONyog the easiest deploy-able solution for MySQL monitoring. You are up and running in less than 5 minutes. Additionally it is a very rich application providing functionalities you do not find anywhere in any other integrated solution.

Recent additions to MONyog include (just mentioning the most important things added in last few weeks before Christmas):

• Exports of Query Analyzer output for import to spreadsheets and databases for further analysis.
• Extended alerting options: now alerts can be send as mails or SNMP traps (or both) and alerts can be sent for long-running queries as you define it.
• The MONyog API: An HTTP-based (and thus totally cross-platform) interface for controlling MONyog from shells as well as scripting and programming environments. Introduced in 3.65 just before Christmas, it is far from complete as of now, but it is extensible – and will be extended.

And MONyog development does not stop here. We develop it aggressively and have recently increased the MONyog developer team. Stay tuned!

Regards,
Team MONyog

Comments(4)

Times are a-changing, and the past couple of months have witnessed a flurry of activity on the cloud computing front; namely, SQL Azure and Amazon RDS. Touted as the harbingers of a new era — the era of Relational DBMS-as-a-Service (DBaaS) — these latest offerings pointedly reassert the fact that databases are now part of the utility model of cloud computing.

For those planning on an early adoption, even with just two significant products (no one seems to have noticed Joyent’s Accelerator for MySQL), it could get really difficult to choose. Here’s a list of 5 things that will help you make the right choice.

1. Targeted Customers: Microsoft’s target for SQL Azure (based on extensive research, I’m sure) is business applications running in the enterprise using databases of 5GB or less. Amazon RDS, comparatively, is more flexible and targets a larger segment of users. While with SQL Azure, you can have a database of up to 10GB, Amazon RDS allows storage of up to 1TB per database instance. Microsoft advises sharding your data in case your requirement exceeds the 10GB limit, which is not really a bad idea: Sharding your data across multiple servers will scale much better than having it all on one bloated server.

2. Support for the Cloud Platform: SQL Azure is “native” to the cloud platform. What does this mean? While MySQL (which is what Amazon RDS provisions) is cloud-capable (ie, can be run on a cloud system without issues), SQL Azure was designed, from scratch, specifically for it. This can only mean that SQL Azure is poised to utilize resources available in a cloud explicitly. Perhaps in the future Amazon might think of switching to Drizzle — a fork of MySQL with the added benefit of optimizations for the cloud environment and web services.

3. Deployment: This is where SQL Azure and Amazon RDS differ the most. While many other bloggers may lead you to believe otherwise, SQL Azure doesn’t have the concept of server/database “instances”. The “servers” that you create are more logical containers than anything else. These containers are provisioned for you exclusively, and will only host your databases. There is a one-to-many relationship between a physical node in the cloud and the servers users create — several servers created by different users may be hosted on the same hardware platform in a shared environment. That is the multi-tenanted architecture implemented by SQL Azure. However, Microsoft doesn’t plan on releasing more specifics about how servers are deployed. The biggest advantage of this model is that Microsoft is able to provide SQL Azure at very low rates. On the flip side, performance enthusiasts do not get the opportunity to tailor the system to their needs. For instance, you cannot change the cache size of your database. Moreover, having a 10GB maximum limit forces a design decision on applications that require large databases. (As previously mentioned, Microsoft advises sharding — partitioning — your data into multiple databases.)

So, how is Amazon RDS different? If you look closely enough, Amazon RDS also implements a multi-tenanted architecture (it’s highly improbable that they could afford to have separate hardware set up for each user!). But this model is implemented at a very different level than that of SQL Azure’s. Amazon RDS provisions a specialized EC2 instance to your AWS account. You can then create multiple, highly varied, instances of MySQL on that EC2 instance. Database instances can vary on the basis of storage (up to an astronomical 1TB) and compute resources (up to 26 ECUs and 68GB of RAM), and you have complete control of your DB parameters (which can be changed using the APIs exposed by Amazon RDS).

4. Compatibility with Existing Systems: For the time being at least, SQL Azure supports only a subset of the features available in SQL Server. On the other hand, Amazon RDS flaunts complete support for MySQL features minus replication. If you are a fan of MySQL, chances are that your applications will work seamlessly with Amazon RDS as well. For instance, in one of my previous posts, I had described how to set up SQLyog and MONyog for an Amazon RDS DB instance. SQL Azure features support for Transact-SQL, and existing libraries — ADO .NET, ODBC and PHP — for connection.

5. Cost/Features Ratio: With all its limitations as compared to Amazon RDS, SQL Azure is definitely a cheaper solution. A notable feature in SQL Azure is that databases are automatically replicated across multiple systems providing for read scale-outs as well as a transparent fail-over mechanism in case of hardware failure — all this while Amazon RDS has specifically disabled replication on its MySQL instances. Then again, SQL Azure doesn’t feature a parallel to the unique on-demand snapshot-based backup method offered by Amazon RDS. Data in SQL Azure is automatically backed up and restored when a disaster occurs. This is transparent to the user. Users will only experience the ‘high availability’ that this feature implies. In a nutshell, SQL Azure lets you choose from two pricing schemes:

• Web Edition: Up to 1GB of storage, $9.99/month
• Business Edition: Up to 10GB of storage, $99.99/month

Additional charges include data transfer per month.
Amazon RDS gives you more choice, albeit at a premium:

• Small DB Instance: 1.7 GB memory, 1 ECU (1 virtual core with 1 ECU), $0.11/hour
• Large DB Instance: 7.5 GB memory, 4 ECUs (2 virtual cores with 2 ECUs each), $0.44/hour
• Extra Large DB Instance: 15 GB of memory, 8 ECUs (4 virtual cores with 2 ECUs each), $0.88/hour
• Double Extra Large DB Instance: 34 GB of memory, 13 ECUs (4 virtual cores with 3.25 ECUs each), $1.55/hour
• Quadruple Extra Large DB Instance: 68 GB of memory, 26 ECUs (8 virtual cores with 3.25 ECUs each), $3.10/hour

Additionally, charges for database storage actually used, I/O and storage for backups apply.

One last thought… So, which is it: SQL Azure or Amazon RDS? In my opinion that would depend entirely on the type of technology you use. If you’re primarily a Microsoft shop, then SQL Azure will be a better choice, as the technology would be familiar — you’ll get Visual Studio integration, support for .NET applications, T-SQL, etc. On the other hand, if you’re a LAMP shop, then Amazon RDS is definitely the way to go.

Shifting to a more opinionated tone, I’d like to pose this question: What could be the primary motivation behind wanting to move one’s database to the cloud? The answer, undeniably, is scalability. As your business grows, so does your database (or so they say!). While on the surface Amazon RDS looks very glossy — they have oh-so-many features, and customizations, and options — under the hood, it boils down to one thing. Amazon RDS database instances have limited scaling capability: If you create a Double Extra Large DB Instance, and you need more compute resources (ie, CPU and memory), you’ll have to change the instance type to Quadruple Extra Large and restart your database for it to take effect. What’s more, if you’ve created a Quadruple Extra Large DB instance, and your DB instance is not actually using all of the resources available, you’ll still be paying through your nose for it! SQL Azure on the other hand allows unlimited scaling at no extra cost. All you pay for is the increased data transfer.

Conversely, SQL Azure allows only up to 10GB storage. How weird is that? My PC has a database of 14GB, which I only use for testing! If you want more storage, create a new database, shard your data across the two databases, and possibly pay double the price — all when you just needed a couple of GBs extra? Phew! I’m glad I won’t be needing to hire either Amazon’s or Microsoft’s services for a while now!

For more information on SQL Azure, visit http://www.microsoft.com/windowsazure/sqlazure/.
For more information on Amazon RDS, visit http://aws.amazon.com/rds/.

Comments(6)

Changes (as compared to 3.62) include:

Features:
* You can now specify a comma-separated list of users to be ignored/excluded by notify and/or kill actions for long-running queries in ’query sniffer’ interface.
* Added a ‘diagnostic info’ icon to servers in ‘list of servers’ page. Clicking this will generate a report in plain text with the most basic information about the server.
* Added an option to stop/start data collection for a server in ‘list of servers’ page (without opening the detailed pages for this server).
* Enabling/disabling data collection from and/or alerting about all servers can be done from tools .. preferences .. maintenance.
* Enabling/disabling data collection from and/or alerting about specific servers can be done by calling the MONyog URL with parameters. This can be scripted and scheduled using any standard method available with the OS. Please refer to documentation for details.
* Mail alerts will now have a direct link to open MONyog login page.
* Added an option to customize colors used in Dashboard.
* If global wait_timeout setting for a server is lower than the sample interval we will now increase session wait_timeout setting in order to avoid the MONyog.log to grow with a “MySQL server has gone away” message for each data retrieval.

Bug Fixes:
* Fixed some issues with validation of user input. For specific data invalid and unusable input could be saved by MONyog. This includes 1) invalid separator between email addresses 2) Entering a decimal where an integer is required.
* SMTP return codes were neither logged nor were specific messages displayed to the user based on them.
* In history/trends an empty graph would display if server details were wrong. Now proper javascript errors are displayed.
* In connection details page for a server the previous/next links would hide with specific menu items selected.
* In History/Trends, warning message (”No data found in this range, try changing history range!”) didn’t show up for the time-frame in which server data collection was disabled.
* If Adobe Flash was not installed, the message to  “install the latest Adobe Flash Player” was displayed more than once.
* Small GUI improvements and fixes.

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

Comments(0)

I had one of those situations today that I think every person working with IT experiences from time to time.  I had a problem that took 4 hours to resolve.  Once resolved I realized that doing the right things in the right order (and also memorizing a little better) could have saved me 3 hours and 55 minutes.

The problem was related to SQLyog HTTP-tunneling. When new PHP versions are released it is most often me that verifies that our HTTP tunneling is not broken.  Thus I have followed the PHP 5.3 release cycle from early betas to RC and GA and experienced that very early  PHP 5.3.0 beta  releases did not work with our HTTP-tunnel. However as both 5.3.0 RC and 5.3.0 GA worked fine (as every 5.2.x always did) I executed “SET panic = OFF” against my most important system (old but still a little functional!).

However the panic reoccurred when PHP 5.3.1 was released.  Nothing worked from PHP. I sat for a couple of  hours with a colleague. Small and very simple PHP test applications  did not work with PHP 5.3.1 either on my environment (but worked fine on my PHP 5.2.11 and 5.3.0 configurations). Not a single comma was added to the MySQL general log or error when trying to connect from PHP 5.3.1. The client application hang for considerable time and finally came out with an error that the URL to the PHP script could not be found. Even more frustrating: the test applications and SQLyog/HTTP-tunnel worked fine on another machine with a(should be) identical configuration in Webyog office as well. Needless to say any connection not using PHP also worked fine.

We are aware that some functions in PHP are depreciated in  5.3.x (and will be removed in PHP 6 according to plans).  This may cause problems with our current tunneler on some systems with PHP 5.3.1.  But we have the fix ready to be released with next SQLyog release (and anybody experiencing such problems can contact us for an updated tunneler).  But as 5.3.0 was not affected this was obviously not the problem occurring on my system. It was something else.

We agreed that I should try reinstalling MySQL and Apache from scratch on my system. However before doing so I ran the queries:

SELECT VERSION(); — returned ‘5.1.36-log’
SHOW ENGINES; — returned PBXT as one engine available in addition to the engines from MySQL … hhmmmm …
Now I got it! I remember now that this particular server on this particular system of mine was a forked build with the PBXT engine downloaded from Primebase website.  Installing the standard/official MySQL 5.1.41 solved the problem immediately. PHP 5.3.1 (and thus SQLyog/HTTP-tunnel) connect like a charm.

I am not able to tell what the problem with this server and PHP version is in technical terms.  And probably this server is also now historical so it is probably not very important either now.  But I think Primebase, the MariaDB people, the XAMPP distributors (and everybody building MySQL with PBXT) as well as the PHP developer team should know this issue and try to figure it out (as well as test with their recent builds and PHP 5.3.1), so that it will not happen again.  A forked build should not only work with the (command line) clients shipped with the server but the tools and connectors used by people already.

… (and besides the version string ‘5.1.36-log’ is definitely not good enough for a forked server build).

Comments(4)