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)
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.
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.