Rather than killing the process, it would be safer if you did it within MySQL:
$ mysqladmin processlist -u root -p
Enter password:
+-----+------+-----------+-------------------+---------+------+-------+------------------+
| Id | User | Host | db | Command | Time | State | Info |
+-----+------+-----------+-------------------+---------+------+-------+------------------+
| 174 | root | localhost | example | Sleep | 297 | | |
| 407 | root | localhost | | Query | 0 | | show processlist |
+-----+------+-----------+-------------------+---------+------+-------+------------------+
The query with id 174 is the one blocking deletion of the 'example' database, so before you kill any processes first let MySQL try to terminate the query:
$ mysqladmin kill 174
Run the processlist
command above again to confirm that it was killed.
If this doesn't work, then you could perhaps look at killing the errant process, but before that you might try restarting the MySQL server.
You can also run commands like 'SHOW FULL PROCESSLIST' and 'KILL 174' in the MySQL shell, for example if you only have the MySQL client installed. The main point is to avoid killing the process using 'kill' in the shell unless absolutely necessary.
Generally speaking you can use either mysql
or mysqladmin
. You shouldn't need to be running commands like this that often though; once you start killing queries regularly something is definitely wrong and you'd be better off fixing that problem (killing the query process is just treating the symptom).
While @ohlin's answer has a decent workaround, it still requires setting up an entire MySQL instance with the undo logs configured the way you want. Then, you have to failover the application to the new MySQL Instance. That still introduces a few minutes of logical downtime from the perspective of the application because of changing the IP addresses in the code or changing DNS.
Your Original Question
Can I move the undo log outside of ibdata1 in MySQL 5.6 on an existing server?
The answer is definitely NO. Why ? Given the following diagram
Look at the following options for the location of the undo logs
OPTION #1 : Undo Logs Inside System Tablespace
By default, the undo logs reside in the system tablespace file known as ibdata1. Undo logs has been the cause of the greatest amount of uncontrolled growth in the face of many transactions (See my post How can Innodb ibdata1 file grows by 5X even with innodb_file_per_table set?)
To relocate ibdata1, you must configure innodb_data_home_dir and innodb_data_file_path. They are global variables, but they are not dynamic. Since a mysql restart would be required to change these settings, the undo logs buried inside ibdata1 cannot be moved for a live MySQL instance.
OPTION #2 : Undo Logs Outside System Tablespace
There are options to configure the undo logs on different disks:
- innodb_undo_logs : Although you can increase or decrease how many rollback segments are used within a transaction, the number of rollback segments physically present in the system never decreases. Thus you might start with a low value for this parameter and gradually increase it, to avoid allocating rollback segments that are not needed later (MySQL Documentation)
- innodb_undo_tablespaces
- innodb_undo_directory
Both innodb_undo_tablespaces and innodb_undo_directory are global variables, but they are not dynamic. Since a mysql restart would be required to change these settings, the undo logs outside ibdata1 cannot be moved for a live MySQL instance.
EPILOGUE
When I read this question, it reminded me of a blog from a FaceBook DB Engineer that configured InnoDB on different disks.
I referred to his blog in my post How do I determine how much data is being written per day through insert, update and delete operations?
Even with this idea, it requires configuring the undo logs in a different disk location from the very beginning. Doing this after mysql is running is simply not possible.
Best Answer
You need to mysqldump all the data (InnoDB and MyISAM) to a local text file and follow your steps.
I have discussed this topic before
Dec 06, 2012
: InnoDB insertion fasterAug 29, 2012
: Removing/overwriting sensitive data located in already deleted records in ibdata filesOct 29, 2010
: My Original Post in StackOverflowYou may be concerned about the amount of data to dump. If you have multiple database, perhaps doing a mysqldump of all that data into a single table may not be advisable.
You could perform a mysqldump for each database into separate files
Please read my other posts on how to do separate mysqldumps
Apr 17, 2011
: How can I optimize a mysqldump of a large database?Dec 07, 2013
: Is there a Successor or an Alternative to mk-parallel-dump?UPDATE 2014-04-10 11:21 EDT
Given these facts
Here are two courses of action
COURSE OF ACTION #1 : Dump Databases Separately
Here is a straightforward mysqldump approach to dump and restore
Dump Databases into Separate Files
Restore Databases (after making new ibdata1 and logfiles)
COURSE OF ACTION #2 : Dump Tables Separately
Here is code to dump all the tables 5 at a time
Restore Databases (after making new ibdata1 and logfiles)
CAVEAT
Make sure
DUMP_LOCATION
has enough space