We had been talking about how MySQL authenticates users, and how if there are no ACL’s set for a given host, MySQL will reject connections from that host – even “telnet host 3306″ will be refused – and that’s when a clever audience member asked where in the handshake process encryption started. Is it before the username is sent? Before the password is sent? Does it encrypt all traffic, even the handshake traffic?

I think that’s an excellent question, and I know there’s a few sharp minds out there who probably know the answer….otherwise I will research the answer this weekend, when I’m back home in Boston.

* Effective MySQL User Group, as part of a tutorial for Percona Live: MySQL Conference and Expo , at the Professional IT Community Conference last week, and last night at the Central Virginia MySQL Meetup Group

Article source: http://www.sheeri.com/content/mysql-handshake-and-encryption

Now, answering such questions right off the bat may be a bit difficult if you do not have a clear plan as to how you want your database to be organized.  Sure, it is great to be very descriptive when creating columns and the like, but you do not want to do it in an excessive manner.  So, keeping this in mind, what do you do if you decide that you need to change the structure or certain characteristics of your tables in MySQL at a later date?  Do you have to create them all over again?  The answer, thankfully, is no.  Thanks to the ALTER TABLE statement, you can change a table’s structure in various ways. 

For instance, in the case of columns, you can add them, delete them, or even change their types.  Want to rename a column with a label that is more appropriate to your needs, you can do so with ALTER TABLE.  Other examples of things you can do with the ALTER TABLE statement include renaming tables, creating indexes, destroying indexes, and the list goes on.

As for the format of the ALTER TABLE statement, here it is in basic form:

ALTER TABLE table_name alter_specification1 [,alter_specification 2,…]

A closer look at this syntax reveals that we begin with the ALTER TABLE statement itself.  Next we list the name of the table whose structure or characteristics we want to change.  After the table name, comes the specific alterations that we want to perform.  To make life easier on you, MySQL allows you to execute multiple alterations at the same time.  Just remember to separate each by a comma in the syntax. 

You have many options when it comes to alter specifications, as mentioned earlier.  You can get the full list of these options by visiting the official MySQL website and viewing the ALTER TABLE section of its online manual.

Now that you have a basic overview of the ALTER TABLE statement and its importance, it is time to take a look at a few examples ALTER TABLE in action.  As is usually the case with tutorials, these are simple our own examples, so you can look them over to get an understanding of how they work and then apply them to your own tables.

Before we begin using ALTER TABLE, let’s create a sample table for the purposes of this tutorial.

CREATE  TABLE ‘assignments’ (
  ‘assignment_id’ INT NOT NULL ,
  ‘topic’ VARCHAR(45) NULL ,
  ‘start_date’ DATETIME NULL ,
  ‘end_date’ DATETIME NULL ,
  ‘notes’ VARCHAR(200) NULL ,
  PRIMARY KEY (‘assignment_id’) ,
  UNIQUE INDEX ‘assignment_id_UNIQUE’ (‘assignment_id’ ASC) );

This created a table named assignments that we will use for our upcoming examples.

How to Use the ALTER TABLE Statement to rename a table in MySQL

For our first example, we will focus on renaming a table in MySQL via the ALTER TABLE statement.  This is a task that you may need to accomplish for one reason or another when working in MySQL, so it is one worth learning.  Luckily, it is very simple in its format, which is the following:

ALTER TABLE ‘assignments’
RENAME TO  ‘duties’ ;

This changes the name of our assignments table to the name of duties.

How to Use the ALTER TABLE Statement to add a column to a table in MySQL

Since our table deals with assignments, or duties, as it is now called, let’s say we want to add a column that shows the progress of each of our duties.  Here is how we can do so:

ALTER TABLE duties ADD COLUMN ‘progress’ DECIMAL(2,1) NULL
AFTER ‘notes’ ;

This alters the duties table by adding the progress column after the notes column.

How to Use the ALTER TABLE Statement to delete or drop a column from a table in MySQL

What if we want to do the opposite of adding a column to our table, and want to delete or drop one that we really do not need?  Here is how:

ALTER TABLE duties
DROP COLUMN notes ;

This alters our duties table by dropping the notes column.

Conclusion

This concludes our tutorial on the ALTER TABLE statement.  Earlier we mentioned the various tasks that could be executed via this statement to give you a glimpse into just how useful it can be when working in MySQL.  To put its usefulness into action, we showed you examples on how to use the ALTER TABLE statement to rename a table, add a column to a table, and delete a column from a table.  As you can see from our examples, using ALTER TABLE is quite simple, yet effective when you want to change the structure of your tables in MySQL.

There are obviously many more ways in which ALTER TABLE can be implemented, but hopefully the few examples in this tutorial served to give you a brief understanding of its functionality.  With that basic knowledge now in your possession, you can research other ways in which you can make the ALTER TABLE statement work for you.

Feel free to leave any comments you may have on this tutorial in the comment section, and be sure to visit us once again at Dev Shed for more MySQL tutorials in the future.

Please enable JavaScript to view the comments powered by Disqus.blog comments powered by Disqus

Article source: http://www.devshed.com/c/a/MySQL/MySQL-Overview-of-the-ALTER-TABLE-Statement-39933/

A new ‘Contributions’ tab has been added to the bugs.mysql.com user interface. This tab will allow users to have a defined space for their contributions. An Oracle Contributor Agreement (OCA) will still be required for all contributions. If needed, the OCA FAQ is posted here.

Please take advantage of this new feature when you help support and enhance MySQL !

Article source: http://sqlhjalp.blogspot.com/2012/05/bugmysqlcom-and-contributions.html

The SQL clauses that set the respective join type in a query are [INNER] JOIN and {LEFT | RIGHT} [OUTER] JOIN. As you can see the actual keywords INNER and OUTER are optional and can be omitted, however outer joins require specifying the direction – either left or right.

Examples of queries:
SELECT * FROM users JOIN files ON files.owner_id = users.id WHERE users.id = 1;
SELECT * FROM users LEFT JOIN files ON files.owner_id = users.id WHERE users.id = 1;

Inner join, outer join

The primary difference between the two basic types (each has several subtypes) is in making the decision whether joining of two rows was successful or not, which essentially determines whether the combined row can be returned or not.

Inner joins require that a row from the first table has a match in the second table based on the join conditions. In means that the first query from the example above will only return any rows if files table contains at least one record where owner_id is 1 (has to be equal to users.id by the join conditions and users.id is filtered in WHERE to accept only that one value). Otherwise it will return no rows at all, even if users contains a valid user record. Assuming there are two users, but only one has any files:

mysql SELECT * FROM users JOIN files ON files.owner_id = users.id WHERE users.id = 1;
+----+--------------+---------+----+----------+------------------+
| id | name         | enabled | id | owner_id | filename         |
+----+--------------+---------+----+----------+------------------+
|  1 | Albin Kolano |       1 |  1 |        1 | audit report.doc |
+----+--------------+---------+----+----------+------------------+
1 row in set (0.00 sec)

mysql SELECT * FROM users JOIN files ON files.owner_id = users.id WHERE users.id = 2;
Empty set (0.01 sec)

Outer joins, on the other hand, consider a join successful even if no records from the second table meet the join conditions (i.e. whether there are any matches or not). In such case outer join sets all values in the missing columns to NULL. The second query from the example will return rows whenever there are matches in users and regardless of the contents of files table.

mysql SELECT * FROM users LEFT JOIN files ON files.owner_id = users.id WHERE users.id = 1;
+----+--------------+---------+------+----------+------------------+
| id | name         | enabled | id   | owner_id | filename         |
+----+--------------+---------+------+----------+------------------+
|  1 | Albin Kolano |       1 |    1 |        1 | audit report.doc |
+----+--------------+---------+------+----------+------------------+
1 row in set (0.00 sec)

mysql SELECT * FROM users LEFT JOIN files ON files.owner_id = users.id WHERE users.id = 2;
+----+-------------------+---------+------+----------+----------+
| id | name              | enabled | id   | owner_id | filename |
+----+-------------------+---------+------+----------+----------+
|  2 | Nadzieja Surowiec |       1 | NULL |     NULL | NULL     |
+----+-------------------+---------+------+----------+----------+
1 row in set (0.00 sec)

Left join, right join

Unlike inner joins, outer joins require that the join direction is specified. Inner join is a symmetrical and bi-directional relationship, which means A JOIN B produces the same result as B JOIN A. That is not true for outer joins, because they accept when for a record in A there is no matching record in B and in such case the reverse operation is impossible (it would have to start with the non-existing record in B). This is the reason why setting the direction is necessary. A LEFT JOIN B finds matches for rows from table A in table B, while A RIGHT JOIN B finds matches for records from B in A.

In practice there is very little or even no real purpose for using RIGHT JOIN and in majority of cases everyone just sticks to using LEFT JOIN whenever they need outer join.

When does the join type matter?

Choosing the appropriate type depends on the logic you are trying to implement.

You have to use inner join when mandatory pieces of information are located in both tables and partial information is considered incomplete or even useless. The case of this could be listing user’s files based on the earlier example:

mysql SELECT *
    - FROM   users
    -        JOIN files
    -        ON     files.owner_id = users.id
    - WHERE  users.name = 'Nadzieja Surowiec'
    -        AND users.enabled = 1;
Empty set (0.00 sec)

The query finds the user’s record by in users table and verifies that they are allowed to use the service through the value of users.enabled column and then searches for their files in files table. If there are no matches in either table, the query does not return any result, which is the correct behavior. If outer join was used in this case, a useless partial result could be returned or even incorrect result:

mysql SELECT *
    - FROM   users
    -        LEFT JOIN files
    -        ON     files.owner_id = users.id
    - WHERE  users.name = 'Nadzieja Surowiec'
    -        AND users.enabled = 1;
+----+-------------------+---------+------+----------+----------+
| id | name              | enabled | id   | owner_id | filename |
+----+-------------------+---------+------+----------+----------+
|  2 | Nadzieja Surowiec |       1 | NULL |     NULL | NULL     |
+----+-------------------+---------+------+----------+----------+
1 row in set (0.00 sec)

mysql SELECT COUNT(1)
    - FROM   users
    -        LEFT JOIN files
    -        ON     files.owner_id = users.id
    - WHERE  users.name = 'Nadzieja Surowiec'
    -        AND users.enabled = 1;
+----------+
| COUNT(1) |
+----------+
|        1 |
+----------+
1 row in set (0.00 sec)

The application relying on such queries not only would not be able to make anything out of such file information where file data is all set to NULL values, but also it would have to include additional and in fact redundant logic to filter out such results. The row count in this case is correct, as the query returned a single row, but it does not represent how many files the user has, so it is not a valid information that the application could use.

Outer join must be used to perform a join with a table, which holds information that is only optional for the result.

In our example we are working with a query that lists user’s files and we already established that the join between users and files has to be inner join. But let’s give our users the opportunity to choose a custom icon for any file if they want to. The information could be kept in a separate table called file_icon.

Now, for each listed file we also want to see if user has set a custom icon for that file and return the icon name if they have set it. The icon information is entirely optional, so we want the query to return rows regardless of whether there is an entry for the given file in file_icon or not. Therefore we have to use outer join for this particular task.

mysql SELECT *
    - FROM   users
    -        JOIN files
    -        ON     files.owner_id = users.id
    -        LEFT JOIN file_icon
    -        ON     file_icon.file_id = files.id
    - WHERE  users.name = 'Albin Kolano'
    -        AND users.enabled = 1;
+----+--------------+---------+----+----------+------------------+---------+------------------+
| id | name         | enabled | id | owner_id | filename         | file_id | icon_image       |
+----+--------------+---------+----+----------+------------------+---------+------------------+
|  1 | Albin Kolano |       1 |  1 |        1 | audit report.doc |       1 | MS-Word-Icon.png |
|  1 | Albin Kolano |       1 |  2 |        1 | stats-201104.xls |    NULL | NULL             |
+----+--------------+---------+----+----------+------------------+---------+------------------+

The outer join allowed us to grab the complete list of user’s files and along with their icons if any were set. If we used inner join instead, the result would be missing the record of stats-201104.xls file.

To Be Continued

More on dealing with practical problems when designing join queries will be covered in a separate post.

Article source: http://www.dbasquare.com/2012/05/16/joins-inner-outer-left-right/

MySQL Workbench 5.2 GA

• Data Modeling

• Query

• Administration

Please get your copy from our Download site.

Sources and binary packages are available for several platforms, including Windows, Mac OS X and Linux.

http://dev.mysql.com/downloads/workbench/

Workbench Documentation can be found here.

http://dev.mysql.com/doc/workbench/en/index.html

Utilities Documentation can be found here.
http://dev.mysql.com/doc/workbench/en/mysql-utilities.html

In addition to the new Query/SQL Development and Administration
modules, version 5.2 features improved stability and performance –
especially in Windows, where OpenGL support has been enhanced and the UI
was optimized to offer better responsiveness.

This release also includes improvements to the scripting capabilities of the SQL Editor. You can read more about it in

http://wb.mysql.com/workbench/doc/

For a detailed list of resolved issues, see the change log.

If you need any additional info or help please get in touch with us.

Post in our forums or leave comments on our blog pages.

- The MySQL Workbench Team

Article source: https://blogs.oracle.com/mysqlworkbench/entry/mysql_workbench_5_2_40

How its done

The replication plugin has a neat feature called quality-of-service filter. If, for example, the quality of service you need from a MySQL Replication cluster is “read your writes”, you call mysqlnd_ms_set_qos($connection, MYSQLND_MS_QOS_CONSISTENCY_SESSION). This instructs the plugin to either use a master or a slave, that has replicated your writes already, for all further reads. The plugin takes care of picking an appropriate cluster node. Once you are done with “read your writes” you can relax the service quality to make node selection faster.

By default, MYSQLND_MS_QOS_CONSISTENCY_SESSION will enforce reading from the master. This is undesired as it increases the load on the master. However, before the introduction of global transaction identifiers, there was no safe way of knowing whether a slave had replicated a certain update already or not.

Using either the plugins GTID emulation or the MySQL 5.6 build-in GTID feature, one can reliably check the up-to-date status of a slave using a SQL SELECT statement. GTIDs are some kind of unique transaction sequence numbers. If you know the transaction sequence number of a write operation, you can check whether it has been replicated using a statement like, for example, SELECT GTID_SUBSET('gtid_of_write', @@GLOBAL.GTID_DONE) AS trx_id FROM DUAL. Please, check my previous posts for a more precise description of the GTID feature. This statement will check the replication status and return immediately.

SQL_THREAD_WAIT_AFTER_GTIDS(string gtids [, timeout])

Alternatively, a MySQL 5.6 user can issue SELECT SQL_THREAD_WAIT_AFTER_GTIDS('gtid_of_write') which will block until either the slave has replicated the write in question or the statement times out. This is great to throttle clients and prevent them to send new updates before the slaves have caught up. This is what some throttling is about. You can control which logic PECL/mysqlnd_ms shall use when searching for an up-to-date slave.

Strictly speaking, you could do it in 1.3 already, if using MySQL 5.6, which is not GA yet. GTIDs are opaque to the plugin. The configuration contains a SQL statement to fetch gtid_of_write and one to check if gtid_of_write has been replicated already. You have been free to either use SQL_THREAD_WAIT_AFTER_GTIDS or not for those config settings.

The new bit

New is a wait_for_gtid_timeout setting that can be used with the GTID emulation. If wait_for_gtid_timeout is set, the plugin will poll a slaves state for wait_for_gtid_timeout seconds regardless of the SQL statement configured. The plugin first runs the SQL statement to check if gtid_of_write has been replicated already. If not, it checks if there is time left for another poll attempt, sleeps for second and polls the status again.

All this is done transparently in the background. All the application does is formulate its quality of service needs.

Throttling makes synchronization costs visible

Throttling client requests should not be understood as a hack. MySQL Replication happens to be a lazy primary copy system. All updates must be performed on the primary (master). Synchronization of secondaries (slaves) is lazy. Update transactions are finished once the primary has finished them. An update transaction never waits for secondaries to catch up. This is an easy to implement, often fast and simple approach.

The drawbacks are temporarily stale data on the secondaries and limited gains in availability over a single server.

Clients get confirmation for update transactions as soon as they are finished on the primary. As soon as they are saved on just one server. There is no guarantee that the transaction ever makes it to a secondary. In the unlikely worst case, the primary crashes in an unrecoverable manner and transactions are lost before being replicated. Thus, little gain over a single server. If you don’t want that, you need eager synchronization. This is what MySQL Cluster offers, if you want it. For eager synchronization one needs to slow down updates and wait for one or all replicas to confirm the update. If updating one secondary is all you need, go for MySQL Semisynchronous Replication.

It may not be technically valid comparison, however, the slow down and wait reminds me of throttling. MySQL lets you choose whether you want to do the wait on demand and on the client side (MySQL Replication: lazy synchronization) or built-in to the distributed system (MySQL Cluster: eager synchronization). Putting all this in a matrix shows the wide range of database replication options that MySQL has to offer.

Happy hacking!

@Ulf_Wendel 

Veröffentlicht am

Tuesday, May 15th, 2012 at 2:11 pm in PlanetMySQL (english), PlanetPHP (english).
Ein RSS 2.0 feed ist verfügbar.

Es ist möglich eine Antwort zu verfassen oder den
Eintrag per Trackback zu verlinken.

Article source: http://blog.ulf-wendel.de/2012/some-throttling-for-peclmysqlnd_ms-14/

“The evolution of Sophos technology and the new ‘Complete Security Suites’ represent a clear and forward-looking vision to manage the advanced multi-vectored threats businesses face,� said Robert Newburn, head of Information Security and Managed Services, Trustmarque. “Security never stands still and neither does Sophos. Through significant in-house development and tactical acquisitions they have built a compelling set of integrated technologies simplifying security management, driving down administration costs and offering customers a mature set of proven tools to protect the endpoint, mobile devices and Gateway.�

The Complete Security Suites combine key functions like endpoint, data and web and email protection, along with mobile device management and protection for Microsoft Exchange and SharePoint. The new offerings give partners a competitive edge in the industry—one vendor, one license, ease of management and deployment. And the array of market-leading solutions creates even more secure environments for their clients at a greater value.

“As a managed service provider, we are our clients’ IT departments, so keeping management costs down is critical to our business,� said Marcus Bearden, vice president of technology, Carceron “The centralized management of Sophos’ Complete Security Suites will reduce our administrative costs, thus reducing costs for our customers—a true win-win. Additionally, they will allow us to offer our clients a better value than an a la carte model while satisfying all their security needs.�

The Complete Security Suites will also shorten the sales cycle for Sophos partners as clients no longer have to evaluate individual solutions in order to solve each security challenge. Instead, they are able to offer solutions that work together—across all points—from a trusted provider.

“Our clients face an ever-changing variety of new security challenges. Since IT managers are already tasked with accomplishing more while using less resources, we need to provide solutions that quickly address all the different aspects of IT security,� said Stephen Merritt, software partner manager, SHI International. “Evaluating multiple security solutions is time consuming for both us and our customers, so the ability to present a single, dynamic and scalable bundle that meets all a customer’s security needs helps keep their focus on other initiatives within an environment they are confident is secure.�

“We recognize that partners are operating in a competitive environment, so they need tools that will help them meet their clients’ demands for stronger security systems,â€� said John Shaw, vice president product management Sophos. “We have built this complete security system for IT because IT teams shouldn’t have to spend time determining which of their point security products is at fault every time they have a problem, only to find that the problem is that the point products don’t work together. With our suites, customers know it’s always Sophos securing them, and they can be confident that they will be backed by both our industry-leading support and our excellent partners.â€�

For additional information on the new Complete Security Suites, please visit: http://www.sophos.com/en-us/products/complete.aspx.

Article source: http://www.sophos.com/en-us/press-office/press-releases/2012/05/sophos-offers-partners-new-complete-security-suites-to-meet-clients-changing-needs.aspx

To help with these problems as well as provide a pastebin for MariaDB developers to share explains during development we created The MariaDB/MySQL Explain Analyzer. This tool:

1. Helps unmangle explains (both vertical and tabular format)
2. Displays explains in an easy-to-read format.
3. Highlights and provides explanations for some terms.
4. Links to KB articles for different optimization techniques.
5. (Optionally) Allows you to save the explain for sharing.

This is the first release so there are still improvements to make. If you have any suggestions, feature requests or bug reports please let us know.

For more information, please see this KB article.

Article source: http://blog.montyprogram.com/announcing-the-explain-analyzer/

Threads and connections

MySQL uses a separate thread for each client connection. A query sent to MySQL is handled by a thread that was previously associated with the connection over which the query arrived. Anyone with sufficient privileges can see the list of currently active threads, along with some additional details, by running SHOW PROCESSLIST command, which returns a table-like view where each connection becomes a separate row:

+-----------+-------------+-------------------+--------+-------------+----------+-------------+---------+
| Id        | User        | Host              | db     | Command     | Time     | State       | Info    |
+-----------+-------------+-------------------+--------+-------------+----------+-------------+---------+
| 827044892 | production  | 10.0.1.100:48596  | proddb | Sleep       |        1 |             |    NULL |
| 827044893 | production  | 10.0.1.100:39181  | proddb | Sleep       |        1 |             |    NULL |
| 827044894 | production  | 10.0.1.100:48598  | proddb | Sleep       |        1 |             |    NULL |
| 827044895 | production  | 10.0.1.100:39183  | proddb | Sleep       |        1 |             |    NULL |

More advanced techniques of dealing with this information are described in the posts titled “Anohter way to work with MySQL process list” and “How to selectively kill queries in MySQL?”.

Any running query or any existing connection from the list can be terminated by using KILL command.

What actually happens when you run KILL?

The command sytnax is KILL [QUERY | CONNECTION] thread_id, where thread_id is the value from the first column of the process list output. The optional argument determines whether only running query or should the entire session be terminated. It defaults to the latter, so specifying CONNECTION is not required.

Running the command doesn’t actually do anything except for setting a special flag inside the selected thread. Therefore the kill operation doesn’t happen synchronously with the corresponding request. In many cases it takes some time for a thread or a query to stop. The flag is checked at various stages of statement execution. When it happens exactly, or how frequently, depends on the work a thread is actually doing.

For example:

• During ALTER TABLE it is checked before each block of rows is read from the original table while MySQL is rewriting data into a new temporary table. In the process, the temporary table is deleted and the original structure remains unchanged.
• For UPDATE and DELETE there is also an additional check after each updated or deleted row. If a query managed to make any changes prior to noticing the request to terminate, they have to be rolled back. Note: if a table’s storage engine does not support transactions (e.g. MyISAM), the changes cannot be rolled back, so the operation will result in partial update!
• SELECT also checks it after reading a block of rows.

Of course, these were just basic examples and the behavior can be different in different situations. It is even possible that some queries will be unkillable in certain circumstances. A case of this happened once while reading from INFORMATION_SCHEMA.INNODB_BUFFER_POOL_PAGES_INDEX table. The database was having performance problems at the time and the query execution basically stopped on a lock somewhere deep inside InnoDB and it never got back to the point where the flag value could be checked again.

Threads stay in killed state for a long time. What does it mean?

Actually, there can be two different cases. If KILL thread_id was issued, there would be killed in the process list. KILL QUERY thread_id doesn’t kill a connection, but rather it only stops a running query within a connection, so in that case query end text may appear instead.

What if you see something like this?

+----+------+-----------+------+---------+------+----------+------------------------------------+
| Id | User | Host      | db   | Command | Time | State    | Info                               |
+----+------+-----------+------+---------+------+----------+------------------------------------+
| 10 | root | localhost | NULL | Query   |    0 | NULL     | show processlist                   |
| 14 | root | localhost | NULL | Killed  |   27 | Updating | update testdb.sometable set cc=sqrt(id) |
+----+------+-----------+------+---------+------+----------+------------------------------------+

It can either be an effect of a bug (e.g. Bug #52528), or more likely it means the database is performing some work internally to clean up after a task that was terminated.

There is of course no easy way to confirm if this is a bug. So in order to figure it out, you should rather look for evidence that it is not a bug. That what you see is just the effect of a standard operation, which MySQL has to perform to clean up after a query or a transaction.

Probably the most common reason for a thread to stay with either killed or query end for a longer period of time is waiting for a transaction rollback on InnoDB tables. This sometimes can take a lot of time to complete, especially when hundreds of thousands or millions of changes have to be removed.

How to verify that?

Check is the output of SHOW ENGINE INNODB STATUSG. It can simply print the information if there is a rollback currently in progress:

---TRANSACTION 0 10411, ACTIVE 28 sec, process no 15506, OS thread id 140732309711184 rollback
mysql tables in use 1, locked 1
ROLLING BACK 7585 lock struct(s), heap size 751600, undo log entries 798854
MySQL thread id 14, query id 206 localhost root end
update testdb.sometable set cc=sqrt(id)

The example shows how easily the information can be found. If a thread is marked with killed, or with query end, and the InnoDB engine status reports a rollback for the same thread, just wait until it ends.

What if it isn’t that?

It can be related to removing some temporary table from disk. An ALTER TABLE may need to discard a very large temporary table, while large file removal on some filesystems (e.g. ext3 or ext4) can be rather slow, so it may need a few seconds or sometimes even longer than that. A temporary table can also be created by any DML statement, but usually not nearly as big in size.

It should not usually be necessary as even in the most extreme cases deleting a file should not take more than ten or twenty seconds, but under heavy I/O load it could be much longer, so is there any way to see whether any temporary table were created or not?

In Percona Server or MariaDB you check the contents of INFORMATION_SCHEMA.GLOBAL_TEMPORARY_TABLE and INFORMATION_SCHEMA.TEMPORARY_TABLE. It will only work for manually established temporary tables with CREATE TEMPORARY TABLE statement, not for those created implicitly by MySQL to execute complex queries.

mysql select * from INFORMATION_SCHEMA.GLOBAL_TEMPORARY_TABLES;
+------------+--------------+------------+--------+-------------------+------------+----------------+-------------+--------------+-------------+-------------+
| SESSION_ID | TABLE_SCHEMA | TABLE_NAME | ENGINE | NAME              | TABLE_ROWS | AVG_ROW_LENGTH | DATA_LENGTH | INDEX_LENGTH | CREATE_TIME | UPDATE_TIME |
+------------+--------------+------------+--------+-------------------+------------+----------------+-------------+--------------+-------------+-------------+
|   28051622 | test         | tbl        | InnoDB | #sql8c3_1ac08a6_0 |       1265 |             51 |       65536 |            0 | NULL        | NULL        |
+------------+--------------+------------+--------+-------------------+------------+----------------+-------------+--------------+-------------+-------------+

SESSION_ID is the same as the thread identifier in the process list, so you can connect any killed threads to their temporary tables.

The other type of temporary tables cannot be easily traced. Sometimes it’s possible to spot the information in the SHOW PROCESSLIST output:

mysql show processlist;
+----------+------+-----------+------+---------+------+----------------------+---------------------------------------------------+
| Id       | User | Host      | db   | Command | Time | State                | Info                                              |
+----------+------+-----------+------+---------+------+----------------------+---------------------------------------------------+
| 1934     | root | localhost | test | Killed  |    4 | Copying to tmp table | INSERT INTO test.tbl SELECT * FROM test.testtable |
..

Sometimes you can check what temporary files the instance keeps open:

server ~ # lsof -c mysqld | grep #sql
mysqld  5626 mysql  138u   REG              253,1       1024 43843585  /vol/vol1/mysql/#sql_95fa_0.MYI
mysqld  5626 mysql  139u   REG              253,1  227262885 43843605  /vol/vol1/mysql/#sql_95fa_0.MYD

The colored value is the file’s size. These may help you to make an assumption that database could be removing a temporary table.

Conclusions

From time to time it may be normal to see a database thread that was killed, but didn’t die immediately, or a query that can’t seem to end. The real operation is not be performed synchronously with the kill command and afterwards MySQL may still need some time to clean things up properly.

No matter what the real cause is, it is impossible to get rid of such hanging threads without a database restart. They should, however, simply be allowed to go away on their own.

There is also no way of forcing a kill that would execute instantly like kill -9 pid in Unix systems.

Article source: http://www.dbasquare.com/2012/05/15/why-do-threads-sometimes-stay-in-killed-state-in-mysql/

List of changes:

• Fixes merged from upstream (Codership-mysql)
• Support for MyISAM, now changes to MyISAM tables are replicated to other nodes
• Improvements to XtraBackup SST methods, better error handling
• New SST wsrep_sst_method=skip, useful when you start all nodes from the same sources (i.e. backup)
• Ability to pass list of IP addresses for a new node, it will connect to the first available

Binaries are available from downloads area or from our repositories.

For this release we will provides binaries for Ubuntu 12.04, they are coming soon.

If you want to know more how to migrate to XtraDB Cluster, we will be giving a free webinar on June 6th.

This is an General Availability release. We did our best to eliminate bugs and problems during alpha and beta testing release, but this is a software, so bugs are expected. If you encounter them, please report to our bug tracking system.

Links:

• We provide tar.gz and RPM binaries for RedHat (CentOS, Oracle Linux) 5 and 6, and Debian packages.
  Downloads: http://www.percona.com/downloads/Percona-XtraDB-Cluster/
• Documentation
  Codership Wiki
• General Discussion group
• Launchpad project
• Bug reports

Article source: http://www.mysqlperformanceblog.com/2012/05/14/announcement-of-percona-xtradb-cluster-5-5-23/