[peterlaursen]

You are right about FLUSH GLOBAL STATUS. I should have checked docs (http://dev.mysql.com/doc/refman/5.5/en/flush.html) before writing.

I actually blogged about the issue myself long time ago here http://blog.webyog.com/2011/11/27/flush-status-surprise/. Since MySQL 5.0 there is no equivalent of what FLUSH STATUS did before 5.0. And that is what FLUSH GLOBAL STATUS should do IMO! But again: you are right: it is not there.

The culprit with MONyog is that FLUSH STATUs will reset the status variable 'uptime_since_flush_status' to “0” (docs: “Some global variables may be reset to zero as well”). And this is one of the ways we have to discard information collected by MONyog before some specific time (the other one is to define a 'base_time' setting in MONyog). FLUSH STATUS is irrevocable – MONyog's own 'base_time' is not.

We will check the options with RDS.

[peterlaursen]

You are right both about the terminology and that this can be done by a Stored Procedure call as you described it.

There is one (internal for MONyog) problem however. We detect RDS instances by parsing the hostname in Javascript and disable some options accordingly when saving server details. But we do not store information that “here we have an RDS instance”. So after saving the server details to the connection.data database in MONyog's database we don't know anymore that this is an RDS instance.

So to support this request we would need a field/column/flag in connection.data like “is_RDS 0|1” so that we can execute different KILL commands when a server is an RDS instance or not when user selects this option. We also need to check a few more details, such as privileges required to CALL this Procedure (is execute privilege to it enough and does a user have this privilege as default?).

We will reply later this week if we are able to include KILL option for RDS soon.

Also BTW: do you know if there is a similar option to FLUSH [GLOBAL] STATUS on an RDS instance?

[peterlaursen]

Also a user connected to MySQL on RDS is not MySQL root/superuser. And then she will only be able to kill his own threads from inside the MySQL connection.

But I think we have not checked details with RDS for more than a year. We will check next week if they have added some options since then.

[peterlaursen]

You cannot do that with MONyog.

RDS is a 'Relational Database Service' (only). It is not a virtualized OS and you dont have shell access. With RDS you can monitor MySQL (whatever can be done from a MySQL client) but not what requires a shell. Also MONyog cannot access the Amazon RDS API.

Besides you are using a confusing terminology IMO. You cannot have *AWS and RDS*. You have either *AWS or RDS*. They are two different services from Amaxon. AWS is a full-flegded (virtualized) OS with shell access and RDS is not. it is a 'Database Service' (only).

We have some blogs about same:

http://blog.webyog.c…eginners-guide/

http://blog.webyog.c…out-amazon-rds/

[peterlaursen]

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

Maybe they will approve it and maybe not. It does not make much difference for neither you nor us really!

[peterlaursen]

Issue confirmed. Very simple to verify actually. I consider it a bug in MySQL even though it may be documented like this!

SET NAMES 'utf8' COLLATE 'utf8_polish_ci';

SET NAMES 'utf8';

SHOW VARIABLES LIKE 'collation_connection'; — returns 'utf8_general_ci'

So what you do in you INIT_COMMAND setting gets overwritten. You can of course send the “SET NAMES 'utf8' COLLATE 'utf8_polish_ci';” statement from the editor for every new connection you create. This is the workaround for now. We will discuss what options we have here.

[peterlaursen]

If this is true

becouse after connection – sqlyog automatically send those commands to server:

(history)

/*[08:15:12][0 ms]*/ SET NAMES 'utf8';

.. and if it resets the collation to the default UTF8 collation we have a problem. We should probably query what the default collation is, if it is a utf8 collations SET it back after SET NAMES.

I am checking this,

(and you are right that you cannot compare or concatenate or whatever of the kind strings of different collations in MySQL)

[peterlaursen]

Do all “predefined connections” point to same server or provider? Maybe settings could have changed on the server or network without your knowledge? Such as a software upgrade of some kind there. Can you totally exclude this possibility?

Also maybe some 'security software' upgrade could have happened in the background on your system. Please try to turn off what you have temporarily. What do you have BTW?

Also please confirm that you have not upgraded SQLyog? If you have you may need to tell your firewall once more to allow access for SQLyog.exe and SJA.exe.

[peterlaursen]

Additinally it is not possible to distinguish a TIMESTAMP and DATETIME when using ODBC, as ODBC has only one data type for both. We map to TIMESTAMP as default (because we need to choose one of them), but user may need to remap.

[peterlaursen]

When you configure the SMTP server to use, there is an option to 'test'. This will send a test mail. You don't recieve this either? If not I think first of all you should check firewall settings for port 25 on both the mahcine where SQLyog/SJA is running and on the machine/network where the SMTP server is running. You may try temporarily to tun off what firewall and firewall-like programs you have installed.

Also: Can you use a traditional mail client (not webmail, gmail or whatever of the kind) but programs like Windows Mail or Outlook on that SMAPT server? There should not be any difference between sending a mail from Outlook etc. and from SJA. Settings details are exactly the same.

[peterlaursen]

This is a server error nad not related to SQLyog. Any other client would face the same problem with same query – if you google it you will find lots of reports of same error with 'mysqldump' for instance. To resolve this a lot of information about the environment (server version & configuraton, Operating System) may be needed. And it is outside the scope of our product support. The question fits better in the MySQL forums (but not much chance that you will really get help there unfortunately).

Let me explain the error message: The file '.retrosheetmetsevents#P#p18.MYD' is a MyISAM data file containing data for a table named `metsevent_with_some_special_character_at_the_end` in a database named `retrosheet`. Whne you select from the table the server would need resources to open the file. A resoruce may be memory (unlikely here) or a file descriptor/file handle for instance.

You may try to raise the open_file_limt setting in MySQQL configuration – refer http://dev.mysql.com/doc/refman/5.5/en/server-options.html#option_mysqld_open-files-limit – or simply try to restart the server to free ununsed/orphaned file handles/file descriptors.

I found a few links for you:

http://dev.mysql.com/doc/refman/5.5/en/server-options.html#option_mysqld_open-files-limit

Fix Out of Resource Problem with MySQL

[peterlaursen]

Both issues confirmed.

1) COLLATE clause not handled properly

2) If one and only oen table option is changed a comma may erroneously be added

This statement is OK: “ALTER TABLE `products_tags` ENGINE=MyISAM, DEFAULT CHARSET='latin1' ; “

This is not:” ALTER TABLE , DEFAULT CHARSET='latin1' ; “

(between table options a comma is valid. But before 1st table option it is not. This happens sometimes if there is only one option specified. We are analyzing the code now)

[peterlaursen]

Please tell: what is the 'wait_timeout' setting on this server (execute “SHOW GLOBAL VARIABLES LIKE 'wait_timeout';”), and what is the sample interval setting in MONyog.

MONyog uses persistent connection to MySQL but If sample interval is larger than 'wait_timeout' the server will disconnect MONyog after 'wait_timeout' idle seconds. MONyog will then reconnect automatically next time it queries the server.

'wait_timeout' has a default setting of 28800 (seconds = 8 hours) in MySQL, but this server may have set a lower value. Now say it is set to “120” (= 2 minutes) and sample interval in MONyog is 5 minutes, MONyog will be disconnected 2 minutes after it has retrieved data from the server last time. And each time the server increments aborted_connects.

[peterlaursen]

Well – the comma is not a bug (and I was wrong).

Please refer MySQL documentation:

http://dev.mysql.com…lter-table.html

table_options:

table_option ,] [i]table_option[/i …

The comma in square brackets (” [,] “) indicates that the comma is optional. And it works fine for us (no error) with both comma and without – and it does not matter if we execute from the editor or from the Schema Sync dialog (but we still don't have the COLLATE clause).

So what is the exact server version you are using (execute “SELECT VERSION();” to get full details)?

Also please doublecheck that the comma is the problem. Copy the statement from Schema Sync dialog to the editor and execute with and without comma.

[peterlaursen]

1) What about 'copy to other' option' setp 1) create the target database 2) from the table menu 'copu tables to other databse or host' and here select what object you wnat to copy.

2) “Replace Database”. MySQL tried to introduce a “rename database” command in early 5.1. It failed (wiht stored program in particular) and they removed it again. We will not attempt to implemet client-side what the server does not support. It will only lead to problems. What SQL commands should we execute BTW? Please understand that SQLyog can only do what can be specified in SQL.

Basically I think that what you are requesting is a 'macro recording' option in SQLyog (creating a series of commands/operations as a single operation). We dont have any such plans.

[Author]

Posts