Changes (as compared to 3.14) include:
Bug Fixes:
* More CPU optimizations with processlist-based sniffer.
* When installing Windows version a js32.dll -error could stop installation (after waiting a few seconds and clicking ‘retry’ it installed successfully).
* Some counters of YES|NO type had an icon for displaying graph what made no sense.
Downloads: http://webyog.com/en/downloads.php
Purchase: http://webyog.com/en/buy.php
Changes (as compared to 8.13) include:
Bug Fixes:
* When backing up a VIEW a temporary table was created on <source>. That could fail if user did not have TMP_TABLE privilege or if the table violated server or storage engine restrictions for tables (but note that we still write statements that create and later drop a ‘dummy’ table when restoring, as this is the only safe way to backup/restore VIEWS defined on VIEWS). We hope to be able to find a better solution soon, but the issue is a server issue that affects all clients - refer to http://bugs.mysql.com/?id=46779.
* When updating from GRID’s SQLyog sends a SHOW CREATE TABLE to ensure that table definition has not changed. But incomplete syntax was used (“SHOW CREATE TABLE `table`” – not “SHOW CREATE TABLE `database`.`table`”). With the new reconnect implementation in 8.13 that could raise the error ‘no database selected’ after a reconnect.
Downloads: http://webyog.com/en/downloads.php
Purchase: http://webyog.com/en/buy.php
Changes (as compared to 8.12) include:
Features:
* SQLyog can be started with a ‘-dir’ switch like “SQLyogENT -dir somefolder”. This -dir switch specifies where SQLyog will look for the sqlyog.ini file and where all writable files will be saved. This was mainly implemented for users that want to have all SQLyog-related files on a removable drive or some kind of encrypted storage. Note that if you use the setting in ‘preferences’ to store TAGS file some specific place the ‘preferences’ setting will still have effect, also if the -dir switch is used.
* Improved/rearranged the GRIDS in Data Sync and Import External Data wizards.
* SJA mail functionality now supports SSL/TLS encryption. This applies to SJA for Linux and SJA for Windows running on Windows, but not SJA for Windows running on Wine, as we did not find any way to access encryption functionality from Wine.
* ALTER VIEW will now format the SELECT-part of the VIEW definition.
* Now all batch jobs will not generate BULK INSERTS larger than 16MB (like already implemented in Import External Data in 8.11).
* In CREATE/ALTER TABLE the charset and collation columns can now be hidden for better overview (most users never use it).
* When updating from DATA or RESULT grid the UPDATE statement will now only list columns that were changed. That results in more readable statements and may also improve performance with ‘wide’ tables and tables with large BLOB/TEXT columns.
* As a consequence of the above the restriction, that a grid containing spatial or binary data could not be updated, has been lifted (but such columns themselves still cannot be updated from the grid).
* Added an option to perform backups in a single transaction (similar to ‘mysqldump’ “–single-transaction” option).
* The connection manager has been redesigned to allow for longer connection names. Also the ‘…’ button was renamed to ‘rename’ (what was what it always did).
* Added support for MySQL compressed protocol in both SQLyog GUI and SJA. Please see detailed note below.
* Added an option for user to specify the timeout setting for the session (note: it will work with MySQL 4.1 and up only as earlier versions do not support SESSION variables). Please see detailed note below.
* Now SQLyog logs to the sqlyog.err file if memory allocation fails with string manipulation (for example when handling blob/text data where a single value may be larger than available memory).
* Version parameter was added to SJA. You can now execute “sja –version” or “sja -v” and version will be returned. Before only the file size could be used to detect the SJA version.
* Now full GUI support for all charsets added to MySQL after 5.1. Everywhere SQLyog presents user for a list of available charsets and collations the server will be queried about this information. Before it was not like that everywhere!
* If the custom size for bulk insert in ‘preferences’ is larger than server default, then SQLyog will use the server default for generating BULK INSERT statements. Users overlooked/forgot that they had specified a setting. As a result backups that would not restore on same server could occur. Also now user specification is restricted to 5 digits (what means it will have to be less than 100 MB).
* The various options available for backups have been reorganized in GUI to make it more clear what options have effect on the source server while backup job is running and what options are options that are written to the file.
* A new query tab can now be opened by double-clicking in the unused space to the right of existing open tabs.
Bug Fixes:
* Edit menu showed F5 for both Refresh and Execute Query.
* Autocapitalisation settings had effect where they should not. It has now been disabled in MESSAGES tab and in the error dialogue.
* Non-column results (like functions, expressions etc.) were affected by column-width persistence feature what they should not (it had weird effects sometimes).
* Various places a horizontal scrollbar displayed where it was not required.
* Fixed wrong behavior with GRID scroll bar after resize.
* ALTER TABLE dialogue executed SHOW TABLE STATUS with no LIKE-clause. That could be slow with a large number of big InnoDB tables in a database.
* PROFILER tab sometimes did not show after executing multiple queries.
* After doing FILTER in DATA tab, LIMIT would be reset to previous value.
* A ‘duplicate key’ error would occur with batch jobs (including Data Sync) if an autoincrement column had a ‘0′ value. We now set ‘NO_AUTO_VALUE_ON_ZERO’ sql_mode for batch jobs.
* On Wine F8 keyboard shortcut was only functional after executing a query.
* When copy database/table from a MySQL server 5.1 or higher to a 3.x or 4.0 server timestamps with ON UPDATE-clause caused a syntax error as ON UPDATE is not valid on such target. There was no issue when source was 5.0 as we transform the CREATE statement. But the condition had a bug so it did not work with 5.1+ .
* It was not possible to enter an empty string in the GUI for ENUM/SET management.
* When queries were inserted from ‘edit .. paste SQL statements’ menu the tokenizer editor component could fail to identify exactly where a statement started and stopped. Reason was that the tokenizer expects Windows linebreaks (\r\n) but templates contained Unix linebreaks (\n).
* SQLyog could fail to save properly from RESULT tab if PK-column(s) were not displayed in GRID (an incorrect WHERE-clause was generated). This bug was introduced in 8.1.
* Data Sync could throw an incorrect ‘AUTO INCREMENT definition mismatch’ error for data types (like TIMESTAMP type) where auto-increment does not apply with specific schemas. Also this bug affected Schema Sync.
* Fixed a crash in Scheduled Backup.
* A scheduled SJA job raised an internal error code in the Windows scheduler. It had no effect on the job as such (queries were executed, mails were sent), but various monitoring tools for Windows servers would raise an alert.
* Emptying a database rendered Autocomplete non-functional for the session.
* Fixed an issue with Schema Sync if the same ’stored program’ was formatted differently on source and target. Target was not always synced properly and SS would detect differences forever.
* On Wine Data Sync could pop up a message that SJA had crashed. But actually it only crashed after user clicked OK in the dialogue.
* ‘reorder columns’ threw away ” (empty string) DEFAULTs for string columns.
* When data were changed in GRIDs and the GRID-curser was moved to another row of the GRID by right-clicking in a cell of another row of the GRID, no UPDATE statement was sent (left-click and arrow-down key worked as expected).
* With low wait_timeout setting on <target> it could happen that Data Sync took more time than this setting to prepare a BULK INSERT statement. Connection to <target> would be lost and sync not completed. We now SET wait_timeout = 28800 in Data Sync. Also ‘restore from SQL dump’ will now do the same.
* Mails sent by SJA could truncate a HTML tag for background color. ‘white’ would become ‘hite’. The display with specific email clients was unpredictable.
* When data sync used the option to generate a sync script the sja.log displayed ZERO’s for inserted, updated and deleted rows. Now the log will display what was written to the script instead.
* When a routine body contained empty lines, Schema Sync would sometimes not sync such empty lines properly. Schema Sync would then detect differences forever.
* In INFO tab/HTML-view empty lines in a routine body could be ‘stripped out’.
* ‘copy database’ failed to copy triggers when selecting only triggers for copy.
* In various error dialogues we will now truncate query strings to 2 KB. Before there was no limit.
* SSH-tunneling failed with the “FreeSSHD” SSH-implementaton for Windows.
Miscellaneous:
* SQLyog reconnects are now coded differently (now the MySQL API reconnect option is used – before it was our own code). The new code means that with SSH-tunnel it will now not be necessary to re-instantiate PLINK (the running PLINK instance will be used). As a consequence SQLyog will now not log to HISTORY when SQLyog reconnected in most situations. However a PLINK<->SSHD reconnect will still be logged always.
Additional comments:
* DO NOT take for granted that use of compressed protocol will always increase performance, because the truth is that most often it will make things slower. Use of compressed protocol will decrease the amount of data to be transferred over the network, but it will result in additional load on both the server and the client (due to compressing and uncompressing). You should never use the option when connecting to MySQL on local machine, on local network or over a fast Internet connection. With slower connections however using this option may improve overall performance. It is impossible to be more specific as most Internet connections have asymmetric properties that differ across Internet providers and telecom companies.
* The option to define timeout for the session (different from the global setting) is possible with MySQL servers from 4.1 and up. However most users will not need to care about it – not even if server (global) timeout setting is low. SQLyog will reconnect if connection was lost since last query was run. Most often user does not even notice. However we have reports of situations where the network takes very long time to process such reconnect requests. In this situation setting the timeout from the client will prevent the situation to occur. Also SSH-users connecting to SSH servers/daemons that are slow to establish connection and where MySQL has a low timeout setting can use this option with advantage.
SJA for Linux:
* As usual with a new SQLyog release also SJA for Linux was updated with the fixes and additions that apply.
* Important note: The C++ shared libary that SJA needs to run (libstdc++.so.5) is now linked dynamically (before it was statically). Please read this FAQ for details.
Downloads: http://webyog.com/en/downloads.php
Purchase: http://webyog.com/en/buy.php
Changes (as compared to 3.13) include:
Bug Fixes:
* Significant CPU optimization with processlist-based sniffer.
* Saving mail settings with Linux version could cause a program ‘hang’.
Downloads: http://webyog.com/en/downloads.php
Purchase: http://webyog.com/en/buy.php
Changes (as compared to first RC) include:
Bug Fixes:
* When data sync used the option to generate a sync script the sja.log displayed ZERO’s for inserted, updated and deleted rows. Now the log will display what was written to the script instead.
* When a routine body contained empty lines, Schema Sync would sometimes not sync such empty lines properly. Schema Sync would then detect differences forever.
* In INFO tab/HTML-view empty lines in a routine body could be ‘stripped out’.
* ‘copy database’ failed to copy triggers when selecting only triggers for copy.
Downloads: http://webyog.com/en/downloads.php
Purchase: http://webyog.com/en/buy.php
Most MySQL users have tried getting this rather cryptic error message: “MySQL server has gone away”. The MySQL documentation describes lots of possible reasons for this here: http://dev.mysql.com/doc/refman/5.1/en/gone-away.html
However this page is of little help for most users, I think. Dozens of reasons are listed, but except for the trivial ones (like physical connection was lost, the MySQL server or the machine where it runs has crashed etc.) there are a few reasons for this that are very common in our experience and a lot of those mentioned are not.
1)
But the documentation at
http://dev.mysql.com/doc/refman/5.1/en/error-messages-client.html
.. also lists another client error:
Error: 2020 (CR_NET_PACKET_TOO_LARGE) Message: Got packet bigger than ‘max_allowed_packet’ bytes
along with
Error: 2006 (CR_SERVER_GONE_ERROR): Message: MySQL server has gone away.
Actually I have not seen the ‘got packet bigger ..’ error myself for many years. Not since MySQL 3.23 or 4.0. I am uncertain if a recent server will sometimes still return ‘got packet bigger’ or not or if also this error message itself has ‘gone away’. If the ‘got packet bigger’ message is still relevant with recent servers it would be nice to have it specified under what conditions it occurs and when only ‘gone away’ will. If this error mesage is now ‘historical’ it should at least be removed from documentation or it should be mentioned that the error no. is reserved for this message – but not used anymore. But it would of course be much preferable to have the ‘got packet bigger’ error returned if that is the problem. It tells what the problem is – “MySQL server has gone away” does not tell anything specific. So ‘got packet bigger’ is a *much* better message than ‘gone away’. Also ‘got packet bigger’ is listed among client errors and not server errors what I would expect. So maybe some problem with my understanding of things here?
Does anybody have any idea about if and why ‘got packet bigger’ now effectively seems to have ‘gone away’ too?
And most important: why disconnect the client? There are reconnect options of course, but it does not really help here. After a reconnect and executing the same query things just repeat themselves.
2)
Basically I never understood why MySQL stick with the default 1M setting for [mysqld] when it is 16M for [mysqldump] in configuration ‘templates’ shipped with the MySQL server (I have tried to ‘hint’ them several times over the last 3-4 years). Obviously they realize that 1M is often too little for backup/restore since they use a larger setting for mysqldump. However users use all other sorts of tools for backup: other script-based tools running on the server, third-party (and MySQL) GUI clients, web-based tools (hosting control panels, phpMyAdmin), backup/restore routines shipping with or built-in applications etc. Often users do not have access to run mysqldump at all on hosted servers (at least not if they are shared servers). Further often Sysadmins are unwilling to change configuration settings and users are left with the option to generate SINGLE INSERTS – with horrible restore performance as a consequence – to ensure cross-server exports/imports (and still it fails with a well-grown MEDIUMBLOB). I deliberately use the term ‘exports/imports’ and not ‘backup/restore’ because it also applies to various tools that can connect to two or more servers at a time and copy data using various techniques without actually generating a file.
The max_allowed_packet problem as described here has been a big problem for us over time. I do not think MySQL fully realises the importance of the problem – mostly because our tools and the tools/clients shipped with the server respectively are used primarily by different segments of users (with some significant overlapping of course). We handle this problem now 100% in SQLyog (we generate the largest BULK INSERTS possible up to 16M everywhere when transferring data from one server to another with all the methods available) but we cannot prevent user - if he wants to use BULK INSERTS - to generate a SQL-DUMP on one server that will not import another because BULK INSERTS are too large. We will of course only be able to handle it if we are connected to both servers.
4)
And actually – and most basically – I also do not really understand why a max_allowed_packet setting is required at all – except that it makes sense of course that a server admin should be able to restrict not-well-behaving users in bombing the server with statements containing 1 GB large WHERE-clauses! But then we are not talking about 1M but rather something like 16-64-100M as a critical threshold, I think.
Also I am not sure if the reason is that the setting is used to allocate a fixed-size memory buffer for handling the query string or if it is related to handling network packages or whatever. I just wondered for quite some time if such restriction could not be avoided and whether this implementation is a deliberate choice for some reason or rather some consequence of coding techniques used currently. I would like to get rid of it!
Changes (as compared to 3.12) include:
Bug Fixes:
* Fixed a major memory leak issue in processlist based sniffer. Also some other small leaks were fixed.
* Using the option to ‘show only changed values’ in HISTORY/TRENDS would show an empty result for counters having non-integer values.
* On systems running Kaspersky security software ‘test connection’ could show an empty messagebox. Kapersky filtered. We have changed the text of the message so that it does not happen now.
Downloads: http://webyog.com/en/downloads.php
Purchase: http://webyog.com/en/buy.php
You are currently browsing the Webyog blog archives for August, 2009.
Comments(2)